packaging May 2006

packaging@lists.fedoraproject.org

13 participants
8 discussions

--vendor fedora, rationale/motivation?
by Rex Dieter 29 Nov '06

29 Nov '06

Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue.

4 6

Accessibility packages (speech-dispatcher + speechd-up)
by Hynek Hanke 28 May '06

28 May '06

Hello, I'm a part of a group of developers of accessibility for blind and visually impaired. We are working under the project www.freebsoft.org and collaborating basically with all other projects in Free Software accessibility. We are seeking help with RPM packaging of several software components which are now widely used by the handicaped community. Basically, we have a package called Speech Dispatcher which provides access to sound synthesizers via a high-level socket interface SSIP (Speech Synthesis Interface Protocol). There are several tools (clients of speech-dispatcher) already developed and being used: speechd-el (accessibility to Emacs), speechd-up (interface for the Speakup screen reader to software synthesis), driver for Gnome Speech (Gnome accessibility technologies). Also, KDE is planning to migrate its speech services to Speech Dispatcher (via KTTSD) for the KDE4 release. Especially the combination speech-dispatcher/speechd-up/Speakup is used quite a lot by Fedora Core users. Today, Speakup together with Emacspeak are the most widely used accessibility tools for blind people on Free Software. This is the only combination which allows users to use Speakup with software speech synthesis (otherwise many users are using hardware devices too). Already there are available Speakup patched kernel packages for Fedora (Speakup, the console screen reader, works in the kernel). Many users have problems with compiling Speech Dispatcher and SpeechD-Up from source code, but even more with setting up the rc scripts and init.d startup (both packages are meant to be run as system services). I believe the task of creating the packages is not difficult for someone with knowledge of Fedora, our resources are however very limited in accessibility and we are not using Fedora on our machines, so we do not have the necessary experience here in Free-B-Soft. Is there please somebody who would be kind enough to help us and the users of our accessibility tools by creating and maintaining at least these two packages? I can provide all the support and guidance as a developer of these two packages. I'm sorry if this is not the right place to ask. In such case, please tell me where it would be more appropriate. More information about Speech Dispatcher http://www.freebsoft.org/speechd and SpeechD-Up http://www.freebsoft.org/speechd-up as well as other accessibility tools from Free-B-Soft http://www.freebsoft.org/projects More information about the SpeakUp screen reader http://www.linux-speakup.org/ Thank you, Hynek Hanke

1 0

teTeX is EOL
by Michael A. Peters 26 May '06

26 May '06

tetex has been EOL'd by upstream. I don't know what the Red Hat maintainer intends to do for FC6 - but clearly at some point the bit rot is going to demand moving to something else, probably texlive (which is what Debian is doing). I'm assuming this means a namespace change for tetex packages. I personally would suggest a namespace that is tex distribution neutral. The TDS is pretty much what all modern open source tex implementations follow and are going to follow, so it makes sense (to me anyway) to use a neutral namespace, like maybe texmf or something. thoughts?

4 3

Debuginfo packages
by Ville Skyttä 20 May '06

20 May '06

FYI, I wrote a packager info blurb about debuginfo packages, see http://fedoraproject.org/wiki/Packaging/Debuginfo Potential problem cases, see roughly < 10kB files at: http://mirrors.kernel.org/fedora/core/development/i386/debug/?C=S;O=A http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A (download.fedora.redhat.com's dir indexes aren't sortable) I've reported bugs against a bunch of Extras packages lately and some of have been already fixed. Sanity checking debuginfo packages would also be an useful addition to the packaging/reviewing guidelines IMO, so I added it to Packaging/GuidelinesTodo in Wiki. The next upstream version of rpmlint (> 0.76) will also have a check for empty debuginfo packages.

4 3

%doc and docdir conflicts
by Orion Poplawski 18 May '06

18 May '06

Where is the appropriate place to put documentation that a package will install during %install in the location specified by --docdir? I've tried using %{_docdir}/%{name}-%{version}, but the %doc macro will clean out that directory before copying over any files listed, wiping out anything installed during %install. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

2 1

Non standard locations for man pages
by Orion Poplawski 18 May '06

18 May '06

In an effort to package up multiple MPI libraries (LAM-MPI, Open-MPI, and MPICH2), we're running into a number of issues with file conflicts. The current strategy is to move many things into /usr/share/%{name}. However, man pages put in /usr/share/%{name}/man are not compressed. Should I just file a bug against /usr/lib/rpm/brp-compress (rpm-build) to add that pattern? Current list is: for d in ./usr/man/man* ./usr/man/*/man* ./usr/info \ ./usr/share/man/man* ./usr/share/man/*/man* ./usr/share/info \ ./usr/kerberos/man ./usr/X11R6/man/man* ./usr/lib/perl5/man/man* \ ./usr/share/doc/*/man/man* ./usr/lib/*/man/man* Or should the man pages go elsewhere? Anything I should do in the meantime to compress the man pages manually if this is the right location until rpm-build is fixed? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

3 2

Re: xorg-x11- packaging prefix
by Axel Thimm 04 May '06

04 May '06

On Thu, May 04, 2006 at 06:50:21AM +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 04.05.2006, 02:52 +0200 schrieb Axel Thimm: > > On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote: > > > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian Høgsberg wrote: > > > > Axel Thimm wrote: > > > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > > > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > > > >>>Axel Thimm wrote: > > > > >>>>Should packages with source from outside of the xorg-x11 tree carry > > > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > > > >>>>often used "for <prefix>" or is it a cendor prefix, e.g. "by > > > > >>>><prefix>"? > > > > >>>> > > > > >>>>How would a 3rd party driver package be best named? > > > > >>>>xorg-x11-drv-<driver> or <3rd-party-vendor>-drv-<driver>? > > > > >>>> > > > > >>>I would say use > > > > >>> > > > > >>>xorg-x11-drv-<driver> > > > > >>> > > > > >>>the second one only confuses users. > > > > >>but xorg-x11 is the name of the upstream vendor, and probably > > > > >>trademarked or close to that. So I would suggest to not do that; even if > > > > >>it's not a legal trademark, it makes sure that users realize where it > > > > >>comes from (and thus where to report bugs ;) > > > > > > > > > >Which brings us back to the question, does the prefix really imply "by > > > > ><prefix>" or "for <prefix>". Usually in packaging practice > > > > >"<prefix>-foo" means foo built for <prefix>, e.g. the miriads of > > > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > > > > >other module- or plugin-type packages. > > > > >I don't mind either way, I just want to hear a clear statement from > > > > >the X11 packaging folks. Personally I tend to hear the sound of the > > > > >vendor in it, but I see many folks suggesting to use it as a domain > > > > >prefix. That's why I'm bringing it up. > > > > It's used in a 'by' sense, notice that we have other out of tree drivers > > > > in the distribution already: synaptics and linuxwacom. > > > OK, thanks, that was what I was looking for. So oot drivers have free > > > nomenclature (e.g. following the project's name), and when (if) they > > > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. > > > Maybe I should toss it to fedoraproject.org's wiki somehwere. > > I've added an entry to > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > > > "Addon Packages (x11 drivers)" > > No offense, but I removed it again. Changes to these kind of documents > are best (read "best" -- not "have to be") discussed with FESCo, on > fedora-packaging and/or with spot, the original author and maintainer of > this document and the Packaging Guidelines in general. No problem, discuss it in FESCo and then add it again. :) I've added fedora-packaging and spot in the Cc. > BTW: Shortly before FC5 was released there was a irc-discussion > regarding the package naming of the proprietary nvidia and fglrx > drivers. It was on #fedora-extras (spot was involved in that discussion, > too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg > drivers". And that's what livna did for FC5 then. > > We should probably discuss this during the next FESCo-Meeting with spot. We know that Fedora Extras and Fedora Core don't yet have identical packaging rules, but they are converging. Wrt new packaging rules one should discuss it with both sides, e.g. ask the x11 maintainers at FC who introduced that prefix what the purpose of the prefix is like done in this thread. Creating new divergent views isn't helpful, I'd say either convince FC's x11 folks to change their mind or follow along. -- Axel.Thimm at ATrpms.net

2 1

License Review
by Jesse Keating 01 May '06

01 May '06

IANAL, so I need somebody to help me review this license to see if we can include software licensed by this. I'm going to put up a package review request for metasploit version 2.5, as the 2.x tree is licensed with Perl Artistic/GPL, however the developmental branch, metasploit 3.0 is licensed with a new license to try and protect themselves from the difficulties recently experienced by nessus and snort. Can you look over http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alp… for The Metasploit Framework License v1.0 ? -- Jesse Keating Release Engineer: Fedora

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2006