packaging August 2009

packaging@lists.fedoraproject.org

42 participants
23 discussions

Minor correction to the approved MPI draft
by Susi Lehtola 14 Aug '09

14 Aug '09

Hi, I just corrected the wording on the MPI Guideline from "NO library configuration (in /etc/ld.so.conf.d) MUST be made" to "library configuration (in /etc/ld.so.conf.d) MUST NOT be made" which is clearer and has the same meaning (it was in the FESCo discussion [1]). I hope that this updated version can be moved to the Packaging Guidelines along with the other guidelines approved today. [1] http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2… 17:20:21 <jds2001> #topic FPC Items 17:20:26 <jds2001> .fesco 241 17:20:29 <jds2001> MPI? 17:20:42 <jds2001> There was something on the page that was confusing to me, let me find it. 17:21:24 <jds2001> ahh - Each MPI build of shared libraries SHOULD have a separate -libs subpackage for the libraries (e.g. foo-mpich2-libs). As in the case of MPI compilers, NO library configuration (in /etc/ld.so.conf.d) MUST be made. 17:21:25 <nirik> +1 here for MPI. It makes sense to me... 17:21:59 <jds2001> that seems to be as "library configuration in /etc/ld.so.conf.d MUST NOT be made" -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

Package rename procedure
by Peter Robinson 13 Aug '09

13 Aug '09

Hi All, I've been looking through the package guidelines for a admin procedure to rename packages and I've not managed to find anything concrete. I found the bit about provides/obsoletes in the spec itself [1] and I found the cvs admin procedure for changes to existing packages but I'm not sure that this relates to an actual rename. Is it as simple as just updating the review request like the other cvs changes for a package or is there a procedure that I've not managed to find in the wiki? I've also checked the drafts to see if there's anything upcoming but found nothing. Cheers, Peter [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplac… [2] https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package…

2 1

Re: Fwd: Django plugin naming
by Toshio Kuratomi 12 Aug '09

12 Aug '09

On 08/10/2009 11:52 AM, Diego Búrigo Zacarão wrote: > Steve, I'm forwarding it for Toshi and the Fedora Packing List as well. :) > > 2009/8/10 Steve 'Ashcrow' Milner <smilner(a)redhat.com> > >> On 10/08/09 15:00 -0300, Diego Búrigo Zacarão wrote: >>> >>> I guess python-$MODULENAME is a good idea for Django apps, once >>> $MODULENAME >>> don't suppress the 'django-' part. Otherwise it would be a problem, mainly >>> because >>> those apps/addons are named (usually) like django-$SOMETHING and >>> $SOMETHING >>> (also usually) is a very simple name, that would conflict with other >>> possibles python >>> apps with the same name. One example of it could be the app >>> 'django-openid'[1], >>> that would conflict with the 'python-openid' library. >>> >> >> Excellent point. It's too bad there isn't an official location for >> Django plugins like /path/to/python/sitelib/django/thirdparty/$NAME. >> Since there isn't one, I wouldn't think it's a good idea to use that >> ourselves else we would end up with projects that only worked on >> Fedora :-(. >> >> I don't know if that has been thought about or not, but maybe it would >> be a good thing to bring up to upstream. >> >> If it's doing to be like python-$MODULENAME (i.e. python-django-tagging), >>> it's Ok with me. >>> I just need someone helping me with it on those sub-packages, as I'm not a >>> packager in >>> reality (yet :)). >>> >> >> We shouldn't change the package name ... for instance, if the django >> application was called tagging and would normally be put into the >> python site-path as such I don't think it would be very smart of us to >> rename it to django_tagging without upstream making the same change. >> Again, we would run into code that only worked on Fedora. Calling the >> package python-django-tagging and NOT changing the actual module name >> would seem to be a good idea. >> +1 I talked with ivazquez yesterday on IRC (he's done quite a few of the plugin modules) and we arrived at this conclusion: Even though the packages live in site-packages and can be imported by python, unless they're being imported by django, django plugins don't do much of anything. Since the django package is named Django rather than python-django, it makes more sense to leave out hte python-* for now. Many of the upstream names are django-SOMETHING. Like django-tagging. So for us to call the package django-tagging is following what upstream is doing. A few packages (like "south" http://south.aeracode.org) don't have django in their upstream name. For these, we should prepend with the Django package name: Django-south since they are plugins to the Django package. Since most of the plugins use lowercase in their upstream name, it's a good idea to Provide: django-south as well. Sound reasonable? -Toshio

1 0

mass-filed --excludedocs bugs
by Rex Dieter 12 Aug '09

12 Aug '09

It would seem an enterprising contributor has taken it upon themselves to mass-file bugs wrt installing packages using --excludedocs. Problem being that many of these bugs are about scriptlet output, like, in https://bugzilla.redhat.com/show_bug.cgi?id=515925 install-info: No such file or directory for /usr/share/info/pinentry.info which follows our current guidlines, http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Texinfo and is not fatal to the transaction. Should the guideline be changed to suppress the erroneous output, or checks added (as suggested in the aforementioned bug), like [ -f %{_infodir}/pinentry.info ] && ... ?? -- Rex

12 20

getmail build failure on rawhide: No such file or directory
by Dean Mander 11 Aug '09

11 Aug '09

Hi, I'm having trouble getting my package built in rawhide. It compiles fine on F-10 and F-11, and previous versions compiled fine (at that point F-11 was still rawhide). Error in the build.log: error: File /builddir/build/SOURCES/getmail-4.11.0.tar.gz: No such file or directory However, I've added this file to cvs (as usual) using: make new-sources FILES="getmail-4.11.0.tar.gz" ; cvs commit -m "update to 4.11.0-2" ; make tag and than during make build I run into the error. Anyone an idea? Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=1597191 Specfile: http://fedorapeople.org/~knol/srpms/getmail/getmail.spec

3 4

Django plugin naming
by Toshio Kuratomi 10 Aug '09

10 Aug '09

Django is a python web framework. Currently it seems like the naming of django and its subpackages do not follow any of our naming guidelines. I'd like to clarify this and write down the proper format of the names for the future. So, in November 2006, the subject of what to call the Django package came up. I said that the name should be python-django but the package was entered into the repository as Django instead: https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00268.h… There are plugins to the Django package being reviewed and they're currently being approved as django-$PLUGINNAME. There's several factors that keep this format from meeting any of the current Guidelines: * grandfathered Django package name. - Due to this, it could be argued that addons to Django could be named Django-$PLUGINNAME rather than python-django-$PLUGINNAME. * lowercasing of the Django name. - lowercase matches better with the actual module name - lowercase is something we like in general as mixed case is something that has broken cornercases (for instance, package Foo and package foo, would conflict with each other in several of our tools) and confused users (Why doesn't "yum install django" work?) An additional factor that I need input from the Django (and Django plugin) maintainers to answer is how tied to Django the plugins are. I know there is a movement to make more things accessible outside of their parent frameworks (for instance, zope has been split into a huge number of smaller packages). If that's the case with the django plugins as well, they really should be named python-$MODULENAME rather than Django-$MODULENAME. Note that the TurboGears precedent that the Django maintainer used when packaging Django only follows the main package. TurboGears addons are named with the python- prefix. Here's the current plugins repoquery found for me: django-authopenid django-contact-form django-evolution django-notification django-pagination django-sct django-tagging -Toshio

1 0

Java guidelines: ant specfile template bug
by Susi Lehtola 09 Aug '09

09 Aug '09

Hi all, there's something wrong with find -name '*.jar' -o -name '*.class' -exec rm -f '{}' \; in http://fedoraproject.org/wiki/PackagingDrafts/Java#ant_2 since it doesn't remove .jar files. find $ -name '*.jar' -o -name '*.class' $ -exec rm -f '{}' \; removes them correctly. Could someone change the command to the working version? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 2

Fedora Packaging Meeting : Wednesday August 5th, 2009 :
by Tom Callaway 08 Aug '09

08 Aug '09

Please note: Our meeting time has changed to Wednesday at 1600 UTC. Here is our planned agenda for tomorrow's meeting: OSGi Packaging Guidelines : https://fedoraproject.org/wiki/PackagingDrafts/OSGiGuidelines filesystem subpackages: https://fedoraproject.org/wiki/PackagingDrafts/CreatingFilesystemSubpackages MPI packaging: https://fedoraproject.org/wiki/PackagingDrafts/MPI Environment Modules: https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules Fortran: https://fedoraproject.org/wiki/PackagingDrafts/Fortran Prohibit /usr/bin/env in shebang: https://fedoraproject.org/wiki/Script_Interpreters_(draft) Update R guidelines: https://fedoraproject.org/wiki/ProposalUpdateRGuidelines Thanks, ~spot

3 4

Packaging games?
by Ryan Rix 06 Aug '09

06 Aug '09

Hello all, I am attempting to package IVAN (http://ivan.sf.net) as my first contribution to Fedora outside of bug reports. With the help of the fedora- kde guys I mostly understand writing specs and the packaging process in general. I have just a few nagging questions that are keeping me from submitting this for review right now: 1) When packaging a game, is it safe to assume that the user who will be running this is a member of the games group? 2) If not, what is the best method of applying setgid to the /usr/bin/ivan in the spec file? 3) Is it acceptable by review standards to have a zero length file in the rpm, even if rpmlint moans about it? It's a high score file under /var/games that apparently cannot be created by the main executable. I tried patching the source to create the file automatically, but I couldn't figure out how; it's probably has something to do with permissions. The mode on the fopen call was already "wb" which 'should' work... 4) Are packaging guidelines for games spelt out anywhere? Thanks for your time, Ryan -- Ryan Rix (623)-826-0051 What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water. -- Matt Welsh http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash XMPP: phrkonaleash(a)gmail.com | MSN: phrkonaleash(a)yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh(a)irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels.

2 2

ldconfig -X in scriptlets?
by Miroslav Lichvar 06 Aug '09

06 Aug '09

Hi, I've recently come across an ldconfig issue when updating libraries. Apparently rpm doesn't always call ldconfig in %postun, I've filed bug #513224 for that. It doesn't seem to be a real bug though. The problem is that when ldconfig in %post is called, there are both old and new libraries on disk. If ldconfig thinks that the older library is newer (according to some internal sorting function) it will replace the packaged symlink with one that points to the other library. After the older library is removed, next ldconfig call will change the symlink back. But is this correct? If %post scriptlet had a code that used the library, it would actually used the older one. ldconfig has -X option which disables the symlink modifications, so I'd like to propose adding the option to recommended %post (and possibly also %postun) scriptlet to avoid such surprises. Comments? -- Miroslav Lichvar

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2009