From cmorve69 at yahoo.es Sat Aug 1 16:41:10 2009 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Sat, 1 Aug 2009 18:41:10 +0200 Subject: [Fedora-packaging] How Fedora is updated/built? Message-ID: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> Hi, I'm not a Fedora user, but looking at the repositories I saw that you update things like KDE in a regular basis. That's uncommon, distros as Ubuntu, Mandriva or openSUSE just release security updates and fixes for really important bugs (frightened about the possibility of upstream breaking ABI compatibility by error). At the same time I saw some packages not updated... so, which exactly is the Fedora updates policy? What I'm most interested in is knowing if a package built against a base (not updated) Fedora install is guaranteed to work with an updated Fedora system. And, when you release an update to the latest version of Amarok, is it built against the original distro/KDE or the updated one? If you release an update from KDE 4.2.2 to 4.2.3, a new Amarok package is also released (without changes, only rebuilt against the new KDE)? One cause I ask is because the openSUSE Build Service builds everything against the original, not updated, Fedora. Is this a problem? Thanks. From rdieter at math.unl.edu Sat Aug 1 16:56:00 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 01 Aug 2009 11:56:00 -0500 Subject: [Fedora-packaging] How Fedora is updated/built? In-Reply-To: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> References: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> Message-ID: <4A7473A0.6050903@math.unl.edu> On 08/01/2009 11:41 AM, Cristian Morales Vega wrote: > Hi, > > I'm not a Fedora user, but looking at the repositories I saw that you > update things like KDE in a regular basis. That's uncommon, distros as > Ubuntu, Mandriva or openSUSE just release security updates and fixes > for really important bugs (frightened about the possibility of > upstream breaking ABI compatibility by error). At the same time I saw > some packages not updated... so, which exactly is the Fedora updates > policy? It's generally left up to the discretion of the package maintainer(s), but see also: http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines > What I'm most interested in is knowing if a package built against a > base (not updated) Fedora install is guaranteed to work with an > updated Fedora system. And, when you release an update to the latest > version of Amarok, is it built against the original distro/KDE or the > updated one? If you release an update from KDE 4.2.2 to 4.2.3, a new > Amarok package is also released (without changes, only rebuilt against > the new KDE)? Fedora builds include (stable) updates as well (ie, it built against the latest). -- Rex From opensource at till.name Sun Aug 2 08:45:55 2009 From: opensource at till.name (Till Maas) Date: Sun, 02 Aug 2009 10:45:55 +0200 Subject: [Fedora-packaging] Python package naming, "py"-exception only for source tarballs? Message-ID: <20090802084555.GA8596@genius.kawo2.rwth-aachen.de> During the review[0] of pyhunspell[1] some confusion came up. The current python module guidelines contain the following: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29 | There is an exception to this rule. If the upstream source has "py" | (or "Py") in its name, you can use that name for the package. For the project "pyhunspell", the tarball is currently called "hunspell-0.1.tar.gz". Therefore this exception does not seem to apply. But the general naming guidelines allow to take the project name into consideration: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming | When naming a package, the name should match the upstream tarball or | project name from which this software came. Can the python exception please also allow to consider ther project name? Regards Till [0] https://bugzilla.redhat.com/show_bug.cgi?id=514509 [1] http://code.google.com/p/pyhunspell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Aug 2 13:54:40 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 02 Aug 2009 08:54:40 -0500 Subject: [Fedora-packaging] Re: Python package naming, "py"-exception only for source tarballs? References: <20090802084555.GA8596@genius.kawo2.rwth-aachen.de> Message-ID: Till Maas wrote: > Can the python exception please also allow to consider ther project > name? > [0] https://bugzilla.redhat.com/show_bug.cgi?id=514509 > [1] http://code.google.com/p/pyhunspell/ Seems clear to me that this is a worthy case for the py-exception. It's the project name that's important, not the tarball name, imo. That said, upstream having project name != tarball name seems more than a wee bit silly. -- Rex From rakesh.pandit at gmail.com Sun Aug 2 14:05:48 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sun, 2 Aug 2009 19:35:48 +0530 Subject: [Fedora-packaging] Re: Python package naming, "py"-exception only for source tarballs? In-Reply-To: References: <20090802084555.GA8596@genius.kawo2.rwth-aachen.de> Message-ID: 2009/8/2 Rex Dieter wrote: > Till Maas wrote: > >> Can the python exception please also allow to consider ther project >> name? >> [0] https://bugzilla.redhat.com/show_bug.cgi?id=514509 >> [1] http://code.google.com/p/pyhunspell/ > > Seems clear to me that this is a worthy case for the py-exception. ?It's the > project name that's important, not the tarball name, imo. > > That said, upstream having project name != tarball name seems more than a > wee bit silly. > As Rex suggested py-exception seems most apt, but a case worth for consideration for addition to guidelines so as to prevent future confusion. -- rakesh From nicolas.mailhot at laposte.net Sun Aug 2 15:47:56 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Aug 2009 17:47:56 +0200 Subject: [Fedora-packaging] Re: Python package naming, "py"-exception only for source tarballs? In-Reply-To: References: <20090802084555.GA8596@genius.kawo2.rwth-aachen.de> Message-ID: <1249228076.14310.8.camel@arekh.okg> Le dimanche 02 ao?t 2009 ? 08:54 -0500, Rex Dieter a ?crit : > Till Maas wrote: > > > Can the python exception please also allow to consider ther project > > name? > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=514509 > > [1] http://code.google.com/p/pyhunspell/ > > Seems clear to me that this is a worthy case for the py-exception. It's the > project name that's important, not the tarball name, imo. > > That said, upstream having project name != tarball name seems more than a > wee bit silly. It is very common. Project name == tarball name is really only used as a conventions in the C FLOSS community and a few sister ones. That's why the only rpm macro which is pretty much mandatory to learn for a packager is %setup. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From erikina at gmail.com Tue Aug 4 00:39:22 2009 From: erikina at gmail.com (Eric Springer) Date: Tue, 4 Aug 2009 10:39:22 +1000 Subject: [Fedora-packaging] How Fedora is updated/built? In-Reply-To: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> References: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> Message-ID: On Sun, Aug 2, 2009 at 2:41 AM, Cristian Morales Vega wrote: > > One cause I ask is because the openSUSE Build Service builds > everything against the original, not updated, Fedora. Is this a > problem? Yeah, it can be. I stopped using OBS for this reason From a.badger at gmail.com Tue Aug 4 02:54:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 03 Aug 2009 19:54:04 -0700 Subject: [Fedora-packaging] How Fedora is updated/built? In-Reply-To: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> References: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> Message-ID: <4A77A2CC.106@gmail.com> Note: This is probably more of a fedora-devel-list topic. No way for you to know that, just looking in from the outside, though :-) On 08/01/2009 09:41 AM, Cristian Morales Vega wrote: > Hi, > > I'm not a Fedora user, but looking at the repositories I saw that you > update things like KDE in a regular basis. That's uncommon, distros as > Ubuntu, Mandriva or openSUSE just release security updates and fixes > for really important bugs (frightened about the possibility of > upstream breaking ABI compatibility by error). At the same time I saw > some packages not updated... so, which exactly is the Fedora updates > policy? This is up to maintainer discretion. In some cases individual SIGs (Special Interest Groups) manage a specific set of dependent packages. (KDE is largely this way). > What I'm most interested in is knowing if a package built against a > base (not updated) Fedora install is guaranteed to work with an > updated Fedora system. No. It's generally frowned upon to make incompatible updates but it's not unheard of. Many maintainers prefer to go to the latest version rather than backporting security fixes which can break compatibility (mozilla/xulrunner/firefox is this way, for instance). > And, when you release an update to the latest > version of Amarok, is it built against the original distro/KDE or the > updated one? The updated one. > If you release an update from KDE 4.2.2 to 4.2.3, a new > Amarok package is also released (without changes, only rebuilt against > the new KDE)? > If the libraries are supposed to be compatible and there is not a new Amarok package we won't recompile Amarok. > One cause I ask is because the openSUSE Build Service builds > everything against the original, not updated, Fedora. Is this a > problem? > Yes. Depending on what libraries your package depends on, you could end up with a package that does not work on an updated Fedora. Within Fedora we have three repositories for any given release. The actual release repo has the packages that were available at the time of release with whatever QA and other testing that we did at that point. The official livecd's, install cds, spins, etc are composed from this tree. Then we have an update repo and an updates-testing repo. Updated packages and new packages generally go to updates-testing and then are pushed to updates after a few weeks. If you're building a third party package it would make the most sense from a Fedora user's point of view to act like you're part of the normal Fedora update stream -- thus your package should build against and run with the package set that's in the updates repository. However, it's harder for you to coordinate this than a package within Fedora as Fedora package maintainers can be proactive about checking which packages depend on theirs whenever they issue an incompatible update -- they can't be proactive about checking which third party packages their update will break. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From cmorve69 at yahoo.es Tue Aug 4 08:59:59 2009 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Tue, 4 Aug 2009 10:59:59 +0200 Subject: [Fedora-packaging] How Fedora is updated/built? In-Reply-To: <4A77A2CC.106@gmail.com> References: <8235e6f40908010941v78a6d0ddm78c42d456058b634@mail.gmail.com> <4A77A2CC.106@gmail.com> Message-ID: <8235e6f40908040159i11f2df8en5cf64f924ad6202a@mail.gmail.com> 2009/8/4 Toshio Kuratomi : > Note: This is probably more of a fedora-devel-list topic. ?No way for > you to know that, just looking in from the outside, though :-) I must admit I just did a quick look... it's my experience that you never get it right no matter how hard you try :-p > On 08/01/2009 09:41 AM, Cristian Morales Vega wrote: >> Hi, >> >> I'm not a Fedora user, but looking at the repositories I saw that you >> update things like KDE in a regular basis. That's uncommon, distros as >> Ubuntu, Mandriva or openSUSE just release security updates and fixes >> for really important bugs (frightened about the possibility of >> upstream breaking ABI compatibility by error). At the same time I saw >> some packages not updated... so, which exactly is the Fedora updates >> policy? > > This is up to maintainer discretion. ?In some cases individual SIGs > (Special Interest Groups) manage a specific set of dependent packages. > (KDE is largely this way). > >> What I'm most interested in is knowing if a package built against a >> base (not updated) Fedora install is guaranteed to work with an >> updated Fedora system. > > No. ?It's generally frowned upon to make incompatible updates but it's > not unheard of. ?Many maintainers prefer to go to the latest version > rather than backporting security fixes which can break compatibility > (mozilla/xulrunner/firefox is this way, for instance). > >> And, when you release an update to the latest >> version of Amarok, is it built against the original distro/KDE or the >> updated one? > > The updated one. > >> If you release an update from KDE 4.2.2 to 4.2.3, a new >> Amarok package is also released (without changes, only rebuilt against >> the new KDE)? >> > If the libraries are supposed to be compatible and there is not a new > Amarok package we won't recompile Amarok. > >> One cause I ask is because the openSUSE Build Service builds >> everything against the original, not updated, Fedora. Is this a >> problem? >> > Yes. ?Depending on what libraries your package depends on, you could end > up with a package that does not work on an updated Fedora. > > Within Fedora we have three repositories for any given release. ?The > actual release repo has the packages that were available at the time of > release with whatever QA and other testing that we did at that point. > The official livecd's, install cds, spins, etc are composed from this > tree. ?Then we have an update repo and an updates-testing repo. ?Updated > packages and new packages generally go to updates-testing and then are > pushed to updates after a few weeks. > > If you're building a third party package it would make the most sense > from a Fedora user's point of view to act like you're part of the normal > Fedora update stream -- thus your package should build against and run > with the package set that's in the updates repository. ?However, it's > harder for you to coordinate this than a package within Fedora as Fedora > package maintainers can be proactive about checking which packages > depend on theirs whenever they issue an incompatible update -- they > can't be proactive about checking which third party packages their > update will break. Thanks, that answers all my doubts. I have asked in the openSUSE Build Service about this, perhaps they can do something to improve the situation. From tcallawa at redhat.com Tue Aug 4 17:17:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 04 Aug 2009 13:17:04 -0400 Subject: [Fedora-packaging] Fedora Packaging Meeting : Wednesday August 5th, 2009 : Message-ID: <4A786D10.2090807@redhat.com> 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 From pertusus at free.fr Tue Aug 4 18:38:39 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 4 Aug 2009 20:38:39 +0200 Subject: [Fedora-packaging] Fedora Packaging Meeting : Wednesday August 5th, 2009 : In-Reply-To: <4A786D10.2090807@redhat.com> References: <4A786D10.2090807@redhat.com> Message-ID: <20090804183839.GA2858@free.fr> On Tue, Aug 04, 2009 at 01:17:04PM -0400, Tom spot Callaway wrote: > > Fortran: > https://fedoraproject.org/wiki/PackagingDrafts/Fortran I have 1 comment on that, I am not sure that using /usr/lib/gcc///finclude is right for %_fmoddir, maybe there should only be gfortran internal .mod, and if a versioned directory is used, instead use something along /usr/lib/gcc///modules/ -- Pat From jussilehtola at fedoraproject.org Tue Aug 4 18:49:52 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 04 Aug 2009 21:49:52 +0300 Subject: [Fedora-packaging] Fedora Packaging Meeting : Wednesday August 5th, 2009 : In-Reply-To: <20090804183839.GA2858@free.fr> References: <4A786D10.2090807@redhat.com> <20090804183839.GA2858@free.fr> Message-ID: <1249411792.2606.7.camel@localhost.localdomain> On Tue, 2009-08-04 at 20:38 +0200, Patrice Dumas wrote: > On Tue, Aug 04, 2009 at 01:17:04PM -0400, Tom spot Callaway wrote: > > > > Fortran: > > https://fedoraproject.org/wiki/PackagingDrafts/Fortran > > I have 1 comment on that, I am not sure that using > > /usr/lib/gcc///finclude > > is right for %_fmoddir, maybe there should only be gfortran internal > .mod, and if a versioned directory is used, instead use something along > > /usr/lib/gcc///modules/ As you can see, the only part where the value of %{_fmoddir} is mentioned is in http://www.fedoraproject.org/wiki/PackagingDrafts/Fortran#Required_changes I actually modified that point some time ago, since the current situation is still a bit unclear. The existing FortranModulesDir guideline uses %{_libdir}/gfortran/modules, but Jakub Jelinek was against it in https://bugzilla.redhat.com/show_bug.cgi?id=513985 and he suggested using that directory which is already used by gfortran (for instance the OpenMP modules are there). However, there's a severe problem with Jakub's suggestion, as the directory is not multiarch compatible, so going with the first option in http://www.fedoraproject.org/wiki/PackagingDrafts/Fortran#Required_changes is preferable. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mlichvar at redhat.com Wed Aug 5 15:07:18 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 5 Aug 2009 17:07:18 +0200 Subject: [Fedora-packaging] ldconfig -X in scriptlets? Message-ID: <20090805150718.GA22242@localhost> 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 From jussilehtola at fedoraproject.org Wed Aug 5 15:42:30 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 05 Aug 2009 18:42:30 +0300 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <20090805150718.GA22242@localhost> References: <20090805150718.GA22242@localhost> Message-ID: <1249486950.2612.10.camel@localhost.localdomain> On Wed, 2009-08-05 at 17:07 +0200, Miroslav Lichvar wrote: > 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. Umm, in %post the old package has already been removed, so there's only the new one available...? https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Ordering -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rdieter at math.unl.edu Wed Aug 5 15:45:20 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Aug 2009 10:45:20 -0500 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <20090805150718.GA22242@localhost> References: <20090805150718.GA22242@localhost> Message-ID: <4A79A910.2000208@math.unl.edu> On 08/05/2009 10:07 AM, Miroslav Lichvar wrote: > 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. Interesting, might this be related to the odd symlinks changing problem in qt as well? https://bugzilla.redhat.com/show_bug.cgi?id=510246 -- Rex From mclasen at redhat.com Wed Aug 5 15:52:29 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 05 Aug 2009 11:52:29 -0400 Subject: [Fedora-packaging] scrollkeeper templates Message-ID: <1249487550.1483.120.camel@planemask> We still have a template for running scrollkeeper-update in %post/% postun. But we are using rarian-compat for quite a while now, and scrollkeeper-update --help states: NOTE (2): This script doesn't do anything and is only provided for scrollkeeper compatibility I think it is time that we just drop those no-op scrollkeeper-update calls. Matthias From tcallawa at redhat.com Wed Aug 5 16:02:19 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 05 Aug 2009 12:02:19 -0400 Subject: [Fedora-packaging] scrollkeeper templates In-Reply-To: <1249487550.1483.120.camel@planemask> References: <1249487550.1483.120.camel@planemask> Message-ID: <4A79AD0B.5020305@redhat.com> On 08/05/2009 11:52 AM, Matthias Clasen wrote: > We still have a template for running scrollkeeper-update in %post/% > postun. But we are using rarian-compat for quite a while now, and > scrollkeeper-update --help states: > > NOTE (2): This script doesn't do anything and is > only provided for scrollkeeper compatibility > > I think it is time that we just drop those no-op scrollkeeper-update > calls. When did it become a noop in the Fedora releases? Is it still a noop in the RHEL versions? ~spot From mclasen at redhat.com Wed Aug 5 16:07:38 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 05 Aug 2009 12:07:38 -0400 Subject: [Fedora-packaging] scrollkeeper templates In-Reply-To: <4A79AD0B.5020305@redhat.com> References: <1249487550.1483.120.camel@planemask> <4A79AD0B.5020305@redhat.com> Message-ID: <1249488458.1483.121.camel@planemask> On Wed, 2009-08-05 at 12:02 -0400, Tom "spot" Callaway wrote: > On 08/05/2009 11:52 AM, Matthias Clasen wrote: > > We still have a template for running scrollkeeper-update in %post/% > > postun. But we are using rarian-compat for quite a while now, and > > scrollkeeper-update --help states: > > > > NOTE (2): This script doesn't do anything and is > > only provided for scrollkeeper compatibility > > > > I think it is time that we just drop those no-op scrollkeeper-update > > calls. > > When did it become a noop in the Fedora releases? Is it still a noop in > the RHEL versions? It became a no-op when scrollkeeper was obsoleted by rarian, which looks like it happened in F8. RHEL-5 still has scrollkeeper. From tcallawa at redhat.com Wed Aug 5 16:16:39 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 05 Aug 2009 12:16:39 -0400 Subject: [Fedora-packaging] Fedora Packaging Meeting : Wednesday August 5th, 2009 : In-Reply-To: <4A786D10.2090807@redhat.com> References: <4A786D10.2090807@redhat.com> Message-ID: <4A79B067.6050700@redhat.com> On 08/04/2009 01:17 PM, Tom "spot" Callaway wrote: > Please note: Our meeting time has changed to Wednesday at 1600 UTC. Due to a lack of quorum, we were unable to process any drafts at this meeting. We will attempt to meet again next week, Wednesday August 12, 2009 at 1600 UTC. ~spot From tcallawa at redhat.com Wed Aug 5 16:45:09 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 05 Aug 2009 12:45:09 -0400 Subject: [Fedora-packaging] scrollkeeper templates In-Reply-To: <1249488458.1483.121.camel@planemask> References: <1249487550.1483.120.camel@planemask> <4A79AD0B.5020305@redhat.com> <1249488458.1483.121.camel@planemask> Message-ID: <4A79B715.3030203@redhat.com> On 08/05/2009 12:07 PM, Matthias Clasen wrote: > On Wed, 2009-08-05 at 12:02 -0400, Tom "spot" Callaway wrote: >> On 08/05/2009 11:52 AM, Matthias Clasen wrote: >>> We still have a template for running scrollkeeper-update in %post/% >>> postun. But we are using rarian-compat for quite a while now, and >>> scrollkeeper-update --help states: >>> >>> NOTE (2): This script doesn't do anything and is >>> only provided for scrollkeeper compatibility >>> >>> I think it is time that we just drop those no-op scrollkeeper-update >>> calls. >> When did it become a noop in the Fedora releases? Is it still a noop in >> the RHEL versions? > > It became a no-op when scrollkeeper was obsoleted by rarian, which looks > like it happened in F8. RHEL-5 still has scrollkeeper. Okay, I've drafted up the change, we'll try to get this one knocked out at our next meeting: https://fedoraproject.org/wiki/PackagingDrafts/DropScrollkeeperUpdate Thanks for the heads-up, ~spot From jussilehtola at fedoraproject.org Wed Aug 5 18:01:09 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 05 Aug 2009 21:01:09 +0300 Subject: [Fedora-packaging] Java guidelines: ant specfile template bug Message-ID: <1249495269.3757.15.camel@localhost.localdomain> 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 at fedoraproject.org From overholt at redhat.com Wed Aug 5 18:44:40 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 5 Aug 2009 14:44:40 -0400 Subject: [Fedora-packaging] Java guidelines: ant specfile template bug In-Reply-To: <1249495269.3757.15.camel@localhost.localdomain> References: <1249495269.3757.15.camel@localhost.localdomain> Message-ID: <20090805184440.GB10197@redhat.com> * Jussi Lehtola [2009-08-05 14:01]: > 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? You'll have to go through the guidelines change process: http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Andrew From mlichvar at redhat.com Wed Aug 5 18:50:28 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 5 Aug 2009 20:50:28 +0200 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <4A79A910.2000208@math.unl.edu> References: <20090805150718.GA22242@localhost> <4A79A910.2000208@math.unl.edu> Message-ID: <20090805185028.GM12281@localhost> On Wed, Aug 05, 2009 at 10:45:20AM -0500, Rex Dieter wrote: > On 08/05/2009 10:07 AM, Miroslav Lichvar wrote: >> 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. > > Interesting, might this be related to the odd symlinks changing problem > in qt as well? > https://bugzilla.redhat.com/show_bug.cgi?id=510246 I think it is. And this one is even better as calling /sbin/ldconfig afterwards doesn't revert it. Before ldconfig call in qt %post: /usr/lib64/libQtCore.so -> libQtCore.so.4.5.0 /usr/lib64/libQtCore.so.4 -> libQtCore.so.4.5.2 /usr/lib64/libQtCore.so.4.5 -> libQtCore.so.4.5.2 /usr/lib64/libQtCore.so.4.5.0 /usr/lib64/libQtCore.so.4.5.2 /usr/lib64/libQtCore_debug.so -> libQtCore.so After: /usr/lib64/libQtCore.so -> libQtCore.so.4.5.0 /usr/lib64/libQtCore.so.4 -> libQtCore_debug.so /usr/lib64/libQtCore.so.4.5 -> libQtCore.so.4.5.2 /usr/lib64/libQtCore.so.4.5.0 /usr/lib64/libQtCore.so.4.5.2 /usr/lib64/libQtCore_debug.so -> libQtCore.so It seems that ldconfig is comparing everything (including symlinks) providing libQtCore.so.4 and libQtCore_debug.so comes out as last. It doesn't point to the same file as the original symlink, so it's changed. Using ldconfig -X should avoid it. -- Miroslav Lichvar From rdieter at math.unl.edu Wed Aug 5 19:22:58 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Aug 2009 14:22:58 -0500 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <20090805185028.GM12281@localhost> References: <20090805150718.GA22242@localhost> <4A79A910.2000208@math.unl.edu> <20090805185028.GM12281@localhost> Message-ID: <4A79DC12.9030509@math.unl.edu> On 08/05/2009 01:50 PM, Miroslav Lichvar wrote: > On Wed, Aug 05, 2009 at 10:45:20AM -0500, Rex Dieter wrote: >> On 08/05/2009 10:07 AM, Miroslav Lichvar wrote: >>> 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. >> >> Interesting, might this be related to the odd symlinks changing problem >> in qt as well? >> https://bugzilla.redhat.com/show_bug.cgi?id=510246 > > I think it is. And this one is even better as calling /sbin/ldconfig > afterwards doesn't revert it. > > Before ldconfig call in qt %post: > /usr/lib64/libQtCore.so -> libQtCore.so.4.5.0 > /usr/lib64/libQtCore.so.4 -> libQtCore.so.4.5.2 > /usr/lib64/libQtCore.so.4.5 -> libQtCore.so.4.5.2 > /usr/lib64/libQtCore.so.4.5.0 > /usr/lib64/libQtCore.so.4.5.2 > /usr/lib64/libQtCore_debug.so -> libQtCore.so > > After: > /usr/lib64/libQtCore.so -> libQtCore.so.4.5.0 > /usr/lib64/libQtCore.so.4 -> libQtCore_debug.so > /usr/lib64/libQtCore.so.4.5 -> libQtCore.so.4.5.2 > /usr/lib64/libQtCore.so.4.5.0 > /usr/lib64/libQtCore.so.4.5.2 > /usr/lib64/libQtCore_debug.so -> libQtCore.so > > It seems that ldconfig is comparing everything (including symlinks) > providing libQtCore.so.4 and libQtCore_debug.so comes out as last. It > doesn't point to the same file as the original symlink, so it's > changed. Using ldconfig -X should avoid it. OK, then, for the love of all that is holy, let's get -X using asap. Followup, why isn't -X the default behavior? -- Rex From xjakub at fi.muni.cz Wed Aug 5 22:14:09 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Thu, 06 Aug 2009 00:14:09 +0200 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <1249486950.2612.10.camel@localhost.localdomain> References: <20090805150718.GA22242@localhost> <1249486950.2612.10.camel@localhost.localdomain> Message-ID: <4A7A0431.1040109@fi.muni.cz> Dne 5.8.2009 17:42, Jussi Lehtola napsal(a): > Umm, in %post the old package has already been removed, so there's only > the new one available...? > > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Ordering No no, look again into the linked wiki page: first the new package is installed, then there is the %post call, then the old one gets removed. Cheers, Milos From jussilehtola at fedoraproject.org Thu Aug 6 05:36:41 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 06 Aug 2009 08:36:41 +0300 Subject: [Fedora-packaging] ldconfig -X in scriptlets? In-Reply-To: <4A7A0431.1040109@fi.muni.cz> References: <20090805150718.GA22242@localhost> <1249486950.2612.10.camel@localhost.localdomain> <4A7A0431.1040109@fi.muni.cz> Message-ID: <1249537001.2616.4.camel@localhost.localdomain> On Thu, 2009-08-06 at 00:14 +0200, Milos Jakubicek wrote: > Dne 5.8.2009 17:42, Jussi Lehtola napsal(a): > > > Umm, in %post the old package has already been removed, so there's only > > the new one available...? > > > > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Ordering > > No no, look again into the linked wiki page: first the new package is > installed, then there is the %post call, then the old one gets removed. Right, I must have been thinking about %postun. Now I see the problem. Thanks. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From Axel.Thimm at ATrpms.net Thu Aug 6 08:39:41 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 6 Aug 2009 11:39:41 +0300 Subject: [Fedora-packaging] Re: ldconfig -X in scriptlets? In-Reply-To: <20090805150718.GA22242@localhost> References: <20090805150718.GA22242@localhost> Message-ID: <20090806083941.GA18356@victor.nirvana> Hi, On Wed, Aug 05, 2009 at 05:07:18PM +0200, Miroslav Lichvar wrote: > 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. Or another package Requiring it in the same rpm transaction. > 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? What would create the symlinks, if ldconfig -X is used everywhere? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mlichvar at redhat.com Thu Aug 6 13:18:06 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 6 Aug 2009 15:18:06 +0200 Subject: [Fedora-packaging] Re: ldconfig -X in scriptlets? In-Reply-To: <20090806083941.GA18356@victor.nirvana> References: <20090805150718.GA22242@localhost> <20090806083941.GA18356@victor.nirvana> Message-ID: <20090806131806.GO12281@localhost> On Thu, Aug 06, 2009 at 11:39:41AM +0300, Axel Thimm wrote: > > 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? > > What would create the symlinks, if ldconfig -X is used everywhere? rpm should do that as symlinks are packaged. If applications suddenly fail to start we know there is a packaging bug. Ideally ldconfig wouldn't touch packaged libraries at all and just update ld.so.cache. Adding -X only to packages that need it won't help much though. I didn't realize that to avoid the unexpected symlink modifications all packages would have to use -X because in a transaction all %post scripts are executed before old files are removed. -- Miroslav Lichvar From rdieter at math.unl.edu Thu Aug 6 14:09:26 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 06 Aug 2009 09:09:26 -0500 Subject: [Fedora-packaging] mass-filed --excludedocs bugs Message-ID: <4A7AE416.5020403@math.unl.edu> 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 From tcallawa at redhat.com Thu Aug 6 14:13:25 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Aug 2009 10:13:25 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <4A7AE416.5020403@math.unl.edu> References: <4A7AE416.5020403@math.unl.edu> Message-ID: <4A7AE505.6040607@redhat.com> On 08/06/2009 10:09 AM, Rex Dieter wrote: > 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 ] && ... Well, if there is output that we wouldn't want suppressed, we could do the file check, but I'm wondering how much of a slow down it would be to check for that file several hundred times in a large transaction. ~spot From tgl at redhat.com Thu Aug 6 14:43:15 2009 From: tgl at redhat.com (Tom Lane) Date: Thu, 06 Aug 2009 10:43:15 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <4A7AE505.6040607@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> Message-ID: <3738.1249569795@sss.pgh.pa.us> "Tom \"spot\" Callaway" writes: > On 08/06/2009 10:09 AM, Rex Dieter wrote: >> It would seem an enterprising contributor has taken it upon themselves >> to mass-file bugs wrt installing packages using --excludedocs. Yeah, I got some of those too. >> Should the guideline be changed to suppress the erroneous output, or >> checks added (as suggested in the aforementioned bug), like >> [ -f %{_infodir}/pinentry.info ] && ... > Well, if there is output that we wouldn't want suppressed, we could do > the file check, but I'm wondering how much of a slow down it would be to > check for that file several hundred times in a large transaction. I definitely want to see the guidelines changed in one way or the other; we shouldn't have individual packagers making their own choices about it. Personally I think that 2>/dev/null is just too dangerous, and some sort of scripted check is the way to go. Is there any other way for a specfile to know whether it's been installed with excludedocs? I'm imagining %if !excludedocs .. run install-info .. %endif which hopefully would be cheap enough to answer spot's concern. regards, tom lane From Axel.Thimm at ATrpms.net Thu Aug 6 15:23:48 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 6 Aug 2009 18:23:48 +0300 Subject: [Fedora-packaging] Re: ldconfig -X in scriptlets? In-Reply-To: <20090806131806.GO12281@localhost> References: <20090805150718.GA22242@localhost> <20090806083941.GA18356@victor.nirvana> <20090806131806.GO12281@localhost> Message-ID: <20090806152348.GC27350@victor.nirvana> On Thu, Aug 06, 2009 at 03:18:06PM +0200, Miroslav Lichvar wrote: > On Thu, Aug 06, 2009 at 11:39:41AM +0300, Axel Thimm wrote: > > > 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? > > > > What would create the symlinks, if ldconfig -X is used everywhere? > > rpm should do that as symlinks are packaged. If applications suddenly fail > to start we know there is a packaging bug. Ideally ldconfig wouldn't > touch packaged libraries at all and just update ld.so.cache. Yes, that makes a lot of sense. But I guess there will be quite a few packages that will break, so maybe this is a feature for F13? > Adding -X only to packages that need it won't help much though. I > didn't realize that to avoid the unexpected symlink modifications all > packages would have to use -X because in a transaction all %post > scripts are executed before old files are removed. It would probably need to be mass-edited. Most ldconfig calls have a typical scheme as a shell replacement, so one could catch a lot automatically. At the very least it would allow to identify and bugzilla packages that have ldconfig uses in non-typical ways. I just wonder if there are implicit uses of ldconfig in other tools used during install time we might be missing. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 6 15:29:42 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 6 Aug 2009 18:29:42 +0300 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <4A7AE505.6040607@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> Message-ID: <20090806152942.GD27350@victor.nirvana> On Thu, Aug 06, 2009 at 10:13:25AM -0400, Tom spot Callaway wrote: > On 08/06/2009 10:09 AM, Rex Dieter wrote: >> 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 ] && ... > > Well, if there is output that we wouldn't want suppressed, we could do > the file check, but I'm wondering how much of a slow down it would be to > check for that file several hundred times in a large transaction. Isn't this file checked only once by the package that provides it? Also when it comes to info and tuning rpm to insanity one would even need to know whether it is pinentry.info or pinentry.info.gz (automatically gzipped by rpm during packaging up the file unless tuned not to). I think install-info happily takes pinentry.info as an argument and still operates on pinentry.info.gz, so the file check would need to check for both variants. E.g. I think it is better to ">/dev/null 2>&1 || :" in this case -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tcallawa at redhat.com Thu Aug 6 15:40:00 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Aug 2009 11:40:00 -0400 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <20090806152942.GD27350@victor.nirvana> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <20090806152942.GD27350@victor.nirvana> Message-ID: <4A7AF950.50708@redhat.com> On 08/06/2009 11:29 AM, Axel Thimm wrote: > E.g. I think it is better to ">/dev/null 2>&1 || :" in this case The more I think about this, the more I agree. I'm not sure we'd ever want to fail the build if the install-info command throws an error, so squelching any noise there seems like the logical solution. Anyone disagree? ~spot From tcallawa at redhat.com Thu Aug 6 15:42:18 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Aug 2009 11:42:18 -0400 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <4A7AF950.50708@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <20090806152942.GD27350@victor.nirvana> <4A7AF950.50708@redhat.com> Message-ID: <4A7AF9DA.6040802@redhat.com> On 08/06/2009 11:40 AM, Tom "spot" Callaway wrote: > On 08/06/2009 11:29 AM, Axel Thimm wrote: > >> E.g. I think it is better to ">/dev/null 2>&1 || :" in this case > > The more I think about this, the more I agree. I'm not sure we'd ever > want to fail the build if the install-info command throws an error, so > squelching any noise there seems like the logical solution. Or rather, I should have said "fail the install transaction". ~spot From ville.skytta at iki.fi Thu Aug 6 15:45:22 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Thu, 6 Aug 2009 18:45:22 +0300 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <3738.1249569795@sss.pgh.pa.us> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <3738.1249569795@sss.pgh.pa.us> Message-ID: <200908061845.26922.ville.skytta@iki.fi> On Thursday 06 August 2009, Tom Lane wrote: > Personally I think that 2>/dev/null is just too dangerous, and some sort > of scripted check is the way to go. Is there any other way for a > specfile to know whether it's been installed with excludedocs? > I'm imagining > %if !excludedocs > .. run install-info .. > %endif > which hopefully would be cheap enough to answer spot's concern. excludedocs isn't the only thing that should be addressed. There's also at least read-only (%_netsharedpath) /usr/share, and --excludepath. Personally, I'd prefer the status quo to be kept (or add 2>/dev/null if people insist) unless someone writes a script or a macro that takes care of all needed cases, it gets messy otherwise in a lot of specfiles. Or even better if there would be a way to accomplish this stuff some way automatically without having to do anything in scriptlets. From mtasaka at ioa.s.u-tokyo.ac.jp Thu Aug 6 15:50:12 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 07 Aug 2009 00:50:12 +0900 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <4A7AF950.50708@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <20090806152942.GD27350@victor.nirvana> <4A7AF950.50708@redhat.com> Message-ID: <4A7AFBB4.9070606@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote, at 08/07/2009 12:40 AM +9:00: > On 08/06/2009 11:29 AM, Axel Thimm wrote: > >> E.g. I think it is better to ">/dev/null 2>&1 || :" in this case > > The more I think about this, the more I agree. I'm not sure we'd ever > want to fail the build if the install-info command throws an error, so > squelching any noise there seems like the logical solution. > > Anyone disagree? > > ~spot There can be some cases in which info files themselves are broken (for example which occured on cloog-ppl package). I think throwing all messages into /dev/null is dangerous, this type of error must be caught properly. Regards, Mamoru From mclasen at redhat.com Thu Aug 6 15:55:43 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 06 Aug 2009 11:55:43 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <4A7AE416.5020403@math.unl.edu> References: <4A7AE416.5020403@math.unl.edu> Message-ID: <1249574143.1601.2.camel@planemask> Maybe it is time to reevaluate some of these very old, not fully supported, obscure install modifications like install_lang, netsharedpath, exclude-docs. Who is actually using these, and how ? Do we 'support' this kind of tweaked installation with any of our install media ? If we don't, why do we allow them to complicate packaging ? What is the cost that these marginal use cases add for our packagers ? Matthias From pertusus at free.fr Thu Aug 6 16:04:33 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 6 Aug 2009 18:04:33 +0200 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <4A7AF950.50708@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <20090806152942.GD27350@victor.nirvana> <4A7AF950.50708@redhat.com> Message-ID: <20090806160433.GB623@free.fr> On Thu, Aug 06, 2009 at 11:40:00AM -0400, Tom spot Callaway wrote: > On 08/06/2009 11:29 AM, Axel Thimm wrote: > > >E.g. I think it is better to ">/dev/null 2>&1 || :" in this case > > The more I think about this, the more I agree. I'm not sure we'd > ever want to fail the build if the install-info command throws an > error, so squelching any noise there seems like the logical > solution. I disagree, I think it is nice to have error messages when install-info fails during postscripts. -- Pat From tcallawa at redhat.com Thu Aug 6 16:12:37 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Aug 2009 12:12:37 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <1249574143.1601.2.camel@planemask> References: <4A7AE416.5020403@math.unl.edu> <1249574143.1601.2.camel@planemask> Message-ID: <4A7B00F5.1030506@redhat.com> On 08/06/2009 11:55 AM, Matthias Clasen wrote: > Maybe it is time to reevaluate some of these very old, not fully > supported, obscure install modifications like install_lang, > netsharedpath, exclude-docs. > > Who is actually using these, and how ? install_lang is useful (in theory) for locale specific spins. exclude-docs is useful for minimal spins, I know OLPC uses it, for example. ~spot From mclasen at redhat.com Thu Aug 6 16:24:46 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 06 Aug 2009 12:24:46 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <4A7B00F5.1030506@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <1249574143.1601.2.camel@planemask> <4A7B00F5.1030506@redhat.com> Message-ID: <1249575886.1601.4.camel@planemask> On Thu, 2009-08-06 at 12:12 -0400, Tom "spot" Callaway wrote: > > install_lang is useful (in theory) for locale specific spins. Any once you've installed those spins, how do you get the languages back ? My question was more aiming at practice, not theory. And at finding out why we carry around so many half-working things... From notting at redhat.com Thu Aug 6 16:51:03 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Aug 2009 12:51:03 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <200908061845.26922.ville.skytta@iki.fi> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <3738.1249569795@sss.pgh.pa.us> <200908061845.26922.ville.skytta@iki.fi> Message-ID: <20090806165103.GD11955@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > excludedocs isn't the only thing that should be addressed. There's also at > least read-only (%_netsharedpath) /usr/share, and --excludepath. If you change %_netsharedpath and/or --excludepath, you get to keep all the pieces, much like if you do forced relocation. Those aren't supportable, generally. Bill From a.badger at gmail.com Thu Aug 6 16:52:02 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 06 Aug 2009 09:52:02 -0700 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <1249574143.1601.2.camel@planemask> References: <4A7AE416.5020403@math.unl.edu> <1249574143.1601.2.camel@planemask> Message-ID: <4A7B0A32.9010107@gmail.com> On 08/06/2009 08:55 AM, Matthias Clasen wrote: > Maybe it is time to reevaluate some of these very old, not fully > supported, obscure install modifications like install_lang, > netsharedpath, exclude-docs. > > Who is actually using these, and how ? > I was using install_lang on all of my personal computers until recently. This was due to size constraints on laptop hard drives. Four years ago or so I was using install_lang and exclude-docs when building specific-purpose livemedia. We were using disk-on-modules and we were able to use Fedora as the basis with docs and lang files excluded. I know that enrico is a big user of netsharedpath but I'll let him speak up with his use cases. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Thu Aug 6 19:07:20 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 6 Aug 2009 22:07:20 +0300 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <20090806165103.GD11955@nostromo.devel.redhat.com> References: <4A7AE416.5020403@math.unl.edu> <200908061845.26922.ville.skytta@iki.fi> <20090806165103.GD11955@nostromo.devel.redhat.com> Message-ID: <200908062207.20563.ville.skytta@iki.fi> On Thursday 06 August 2009, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > excludedocs isn't the only thing that should be addressed. There's also > > at least read-only (%_netsharedpath) /usr/share, and --excludepath. > > If you change %_netsharedpath and/or --excludepath, you get to keep > all the pieces, much like if you do forced relocation. Those aren't > supportable, generally. I don't see why %_netsharedpath wouldn't be supportable, pretty much all it takes from the packager is to not expect that writes from scriptlets will always succeed (in the sense that the scriptlet won't end up terminating the transaction). I don't personally care about that or --excludepath much at all but others have repeatedly indicated they do at least about the former. I do however use excludedocs in various space constrained setups, and %install_langs in all my setups. From notting at redhat.com Thu Aug 6 19:55:57 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Aug 2009 15:55:57 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <200908062207.20563.ville.skytta@iki.fi> References: <4A7AE416.5020403@math.unl.edu> <200908061845.26922.ville.skytta@iki.fi> <20090806165103.GD11955@nostromo.devel.redhat.com> <200908062207.20563.ville.skytta@iki.fi> Message-ID: <20090806195556.GC15107@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > > > excludedocs isn't the only thing that should be addressed. There's also > > > at least read-only (%_netsharedpath) /usr/share, and --excludepath. > > > > If you change %_netsharedpath and/or --excludepath, you get to keep > > all the pieces, much like if you do forced relocation. Those aren't > > supportable, generally. > > I don't see why %_netsharedpath wouldn't be supportable, pretty much all it > takes from the packager is to not expect that writes from scriptlets will > always succeed (in the sense that the scriptlet won't end up terminating the > transaction). Because it allows you to set arbitrary paths that can't be known to the packager as writable, there's no sane way to write scriptlets. For --excludedocs, the packager knows ahead of time what parts of his package will be affected, and can write their scripts accordingly. For %_netsharedpath, it could be any portion of the package that could change to be unwritable out from under the package. If it's /usr/lib, should it be OK if ldconfig fails? If it's /etc/init.d, is it OK if chkconfig fails? You can't reliably package around arbitrary restrictions. Bill From phrkonaleash at gmail.com Fri Aug 7 02:30:47 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Thu, 06 Aug 2009 19:30:47 -0700 Subject: [Fedora-packaging] Packaging games? Message-ID: 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 at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From tcallawa at redhat.com Fri Aug 7 03:55:42 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Aug 2009 23:55:42 -0400 Subject: [Fedora-packaging] Packaging games? In-Reply-To: References: Message-ID: <4A7BA5BE.6090108@redhat.com> On 08/06/2009 10:30 PM, Ryan Rix wrote: > 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? https://fedoraproject.org/wiki/SIGs/Games/Packaging has a section that covers this. > 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... If you have a good reason to do so, just put a comment there in the spec file and do it. If a reviewer points it out, just explain why you did what you did. > 4) Are packaging guidelines for games spelt out anywhere? Just the URL I posted above. ~spot From phrkonaleash at gmail.com Fri Aug 7 04:03:04 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Thu, 06 Aug 2009 21:03:04 -0700 Subject: [Fedora-packaging] Re: Packaging games? References: <4A7BA5BE.6090108@redhat.com> Message-ID: Tom "spot" Callaway wrote: > On 08/06/2009 10:30 PM, Ryan Rix wrote: >> 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? > > https://fedoraproject.org/wiki/SIGs/Games/Packaging has a section that > covers this. Thanks, this is exactly waht I was looking for! > >> 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... > > If you have a good reason to do so, just put a comment there in the spec > file and do it. If a reviewer points it out, just explain why you did > what you did. > >> 4) Are packaging guidelines for games spelt out anywhere? > > Just the URL I posted above. > > ~spot -- Ryan Rix (623)-826-0051 Fortune: Culus: Building a five-meter-high replica of the Empire State Building with paperclips is impressive. Doing it blindfolded is eleet. http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From jussilehtola at fedoraproject.org Sat Aug 8 09:33:56 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 08 Aug 2009 12:33:56 +0300 Subject: [Fedora-packaging] Fedora Packaging Meeting : Wednesday August 5th, 2009 : In-Reply-To: <4A786D10.2090807@redhat.com> References: <4A786D10.2090807@redhat.com> Message-ID: <1249724036.2596.12.camel@localhost.localdomain> On Tue, 2009-08-04 at 13:17 -0400, Tom "spot" Callaway wrote: > filesystem subpackages: > https://fedoraproject.org/wiki/PackagingDrafts/CreatingFilesystemSubpackages I really think that the naming shouldn't be -filesystem, since it doesn't represent the role of the package. IMHO filesystem is OK for packages containing only directories (e.g. filesystem, kde4-filesystem, but if the package contains also files then it should be called -common. For comparison, at the moment I count 15 -filesystem packages in rawhide compared to 115 -common packages. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From ville.skytta at iki.fi Sun Aug 9 09:40:24 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 9 Aug 2009 12:40:24 +0300 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <20090806195556.GC15107@nostromo.devel.redhat.com> References: <4A7AE416.5020403@math.unl.edu> <200908062207.20563.ville.skytta@iki.fi> <20090806195556.GC15107@nostromo.devel.redhat.com> Message-ID: <200908091240.24725.ville.skytta@iki.fi> On Thursday 06 August 2009, Bill Nottingham wrote: > For %_netsharedpath, it could be any portion of the package that > could change to be unwritable out from under the package. If it's > /usr/lib, should it be OK if ldconfig fails? If it's /etc/init.d, > is it OK if chkconfig fails? All I'm saying is packagers should just not assume that scriptlets will always succeed and that'll provide the basic catch-all level of support for scenarios such as the above (which I think is enough), and many others such as things discussed in this thread. We already have that documented, see the scriptlet exit status discussion at https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax But as said, I'm not personally interested in %_netsharedpath except to some theoretical extent, so... meh. Aside, I do think it should be evaluated whether rpm's current default behavior regarding scriptlet exit statuses is really what we want, or if it should be flipped so that the effects on the transaction non-zero exit statuses currently have (which I believe is rarely if ever desirable) would need to be explicitly invoked in scriptlets some way. From jussilehtola at fedoraproject.org Sun Aug 9 09:51:29 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 09 Aug 2009 12:51:29 +0300 Subject: [Fedora-packaging] Java guidelines: ant specfile template bug In-Reply-To: <20090805184440.GB10197@redhat.com> References: <1249495269.3757.15.camel@localhost.localdomain> <20090805184440.GB10197@redhat.com> Message-ID: <1249811489.5453.1.camel@localhost.localdomain> On Wed, 2009-08-05 at 14:44 -0400, Andrew Overholt wrote: > * Jussi Lehtola [2009-08-05 14:01]: > > 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? > > You'll have to go through the guidelines change process: > > http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure > > Andrew Right, I have created https://fedoraproject.org/wiki/PackagingDrafts/JavaAntSampleSpec for discussion in the next FPC meeting. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pmatilai at laiskiainen.org Mon Aug 10 12:13:03 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 10 Aug 2009 15:13:03 +0300 (EEST) Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <3738.1249569795@sss.pgh.pa.us> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <3738.1249569795@sss.pgh.pa.us> Message-ID: On Thu, 6 Aug 2009, Tom Lane wrote: > "Tom \"spot\" Callaway" writes: >> On 08/06/2009 10:09 AM, Rex Dieter wrote: >>> It would seem an enterprising contributor has taken it upon themselves >>> to mass-file bugs wrt installing packages using --excludedocs. > > Yeah, I got some of those too. > >>> Should the guideline be changed to suppress the erroneous output, or >>> checks added (as suggested in the aforementioned bug), like >>> [ -f %{_infodir}/pinentry.info ] && ... > >> Well, if there is output that we wouldn't want suppressed, we could do >> the file check, but I'm wondering how much of a slow down it would be to >> check for that file several hundred times in a large transaction. > > I definitely want to see the guidelines changed in one way or the other; > we shouldn't have individual packagers making their own choices about it. > > Personally I think that 2>/dev/null is just too dangerous, and some sort > of scripted check is the way to go. Is there any other way for a > specfile to know whether it's been installed with excludedocs? > I'm imagining > %if !excludedocs > .. run install-info .. > %endif > which hopefully would be cheap enough to answer spot's concern. No, excludedocs and other similar mechanisms aren't exported to scriptlets. There are number of issues with the above %if .. %endif idea: - macros in scriptlets get expanded at build-, not install time - %if .. %endif style conditionals only exists in the spec parser - excludedocs & other similar are only relevant during install-, not at build-time Sure it'd be possible to export the information through environment variables, so the above snippet would become something like if [ -z "$RPM_EXCLUDE_DOCS" ]; then ... run install-info fi ...but that wouldn't do anything to help things like %_install_langs, %_netsharedpath, --excludepath etc. And really, the scriptlets are cluttered enough already without having all of them try to work with each and every obscure rpm switch and "feature." There's a big pile of related issues which want essentially event-driven (think of "/usr/share/foo got removed/installed/modified") actions. - Panu - From tgl at redhat.com Mon Aug 10 14:20:02 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 10 Aug 2009 10:20:02 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <3738.1249569795@sss.pgh.pa.us> Message-ID: <1414.1249914002@sss.pgh.pa.us> Panu Matilainen writes: > ...but that wouldn't do anything to help things like %_install_langs, > %_netsharedpath, --excludepath etc. And really, the scriptlets are > cluttered enough already without having all of them try to work with > each and every obscure rpm switch and "feature." Yeah. Are you in favor of just dropping --excludedocs and related features, then? To me, --excludedocs is worth keeping, but the rest are not. Personally I'd be happy if a macro were provided and packagers just had to write %install-info mypackage.info and then there's only one place we have to get it right. regards, tom lane From tcallawa at redhat.com Mon Aug 10 15:08:42 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 10 Aug 2009 11:08:42 -0400 Subject: [Fedora-packaging] mass-filed --excludedocs bugs In-Reply-To: <1414.1249914002@sss.pgh.pa.us> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <3738.1249569795@sss.pgh.pa.us> <1414.1249914002@sss.pgh.pa.us> Message-ID: <4A8037FA.1000001@redhat.com> On 08/10/2009 10:20 AM, Tom Lane wrote: > Panu Matilainen writes: >> ...but that wouldn't do anything to help things like %_install_langs, >> %_netsharedpath, --excludepath etc. And really, the scriptlets are >> cluttered enough already without having all of them try to work with >> each and every obscure rpm switch and "feature." > > Yeah. Are you in favor of just dropping --excludedocs and related > features, then? To me, --excludedocs is worth keeping, but the > rest are not. > > Personally I'd be happy if a macro were provided and packagers just > had to write > %install-info mypackage.info > and then there's only one place we have to get it right. We could probably make a scriptlet for it, the problem is that we have generally avoided making scriptlets like that for common cases because then the Fedora spec files become "Fedora-specific" spec files, much in the same way that OpenSUSE spec files have traditionally not worked anywhere else. Now, if upstream RPM felt that it was compelling enough to provide such a macro by default, we'd certainly leverage it in Fedora. ~spot From a.badger at gmail.com Mon Aug 10 16:24:44 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 10 Aug 2009 09:24:44 -0700 Subject: [Fedora-packaging] Django plugin naming Message-ID: <4A8049CC.1050000@gmail.com> 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.html 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From knolderpoor at gmail.com Tue Aug 11 08:04:17 2009 From: knolderpoor at gmail.com (Dean Mander) Date: Tue, 11 Aug 2009 10:04:17 +0200 Subject: [Fedora-packaging] getmail build failure on rawhide: No such file or directory Message-ID: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pingou at pingoured.fr Tue Aug 11 08:13:16 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Tue, 11 Aug 2009 10:13:16 +0200 Subject: [Fedora-packaging] getmail build failure on rawhide: No such file or directory In-Reply-To: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> References: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> Message-ID: <1249978396.5295.3.camel@pingouLab.pingoured.fr> On Tue, 2009-08-11 at 10:04 +0200, Dean Mander wrote: > 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? http://koji.fedoraproject.org/koji/getfile?taskID=1597191&name=build.log says: "error: File /builddir/build/SOURCES/getmail-4.11.0.tar.gz: No such file or directory" Check your sources file. Regards, Pierre From pingou at pingoured.fr Tue Aug 11 08:15:45 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Tue, 11 Aug 2009 10:15:45 +0200 Subject: [Fedora-packaging] getmail build failure on rawhide: No such file or directory In-Reply-To: <1249978396.5295.3.camel@pingouLab.pingoured.fr> References: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> <1249978396.5295.3.camel@pingouLab.pingoured.fr> Message-ID: <1249978545.5295.4.camel@pingouLab.pingoured.fr> On Tue, 2009-08-11 at 10:13 +0200, Pierre-Yves wrote: > On Tue, 2009-08-11 at 10:04 +0200, Dean Mander wrote: > > 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? > http://koji.fedoraproject.org/koji/getfile?taskID=1597191&name=build.log > says: > "error: File /builddir/build/SOURCES/getmail-4.11.0.tar.gz: No such file > or directory" > > Check your sources file. oups sorry I read your email to quickly (and the sources files look ok in the cvs) Pierre From mtasaka at ioa.s.u-tokyo.ac.jp Tue Aug 11 09:47:52 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 11 Aug 2009 18:47:52 +0900 Subject: [Fedora-packaging] getmail build failure on rawhide: No such file or directory In-Reply-To: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> References: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> Message-ID: <4A813E48.1020203@ioa.s.u-tokyo.ac.jp> Dean Mander wrote, at 08/11/2009 05:04 PM +9:00: > 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 > As fedora cvs says that the "sources" file under rpms/getmail/devel which has "getmail-4_11_0-1_fc12" tag contains "getmail-4.9.2.tar.gz" [1], I guess that after you uploaded getmail-4.11.0.tar.gz by "make new-sources", executing "make tag" _failed_. You can either - use force tagging (although I have heard that this is not recommended) - or just bump release number on the spec file and tag again [1] http://cvs.fedoraproject.org/viewvc/rpms/getmail/devel/sources?view=log Regards, Mamoru From knolderpoor at gmail.com Tue Aug 11 10:12:49 2009 From: knolderpoor at gmail.com (Dean Mander) Date: Tue, 11 Aug 2009 12:12:49 +0200 Subject: [Fedora-packaging] getmail build failure on rawhide: No such file or directory In-Reply-To: <4A813E48.1020203@ioa.s.u-tokyo.ac.jp> References: <36e17640908110104h7261b1d7l6a387db642e8584d@mail.gmail.com> <4A813E48.1020203@ioa.s.u-tokyo.ac.jp> Message-ID: <36e17640908110312n56dfc57bh4534f42258d408d6@mail.gmail.com> On Tue, Aug 11, 2009 at 11:47 AM, Mamoru Tasaka wrote: > Dean Mander wrote, at 08/11/2009 05:04 PM +9:00: > > 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 >> >> > As fedora cvs says that the "sources" file under rpms/getmail/devel > which has "getmail-4_11_0-1_fc12" tag contains "getmail-4.9.2.tar.gz" [1], > I guess that after you uploaded getmail-4.11.0.tar.gz by "make new-sources", > executing "make tag" _failed_. > > You can either > - use force tagging (although I have heard that this is not recommended) > - or just bump release number on the spec file and tag again > > [1] > http://cvs.fedoraproject.org/viewvc/rpms/getmail/devel/sources?view=log > > Regards, > Mamoru > > Bump release number worked. Thanks man!! Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Wed Aug 12 14:03:34 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Aug 2009 16:03:34 +0200 Subject: [Fedora-packaging] Re: mass-filed --excludedocs bugs In-Reply-To: <4A7AF950.50708@redhat.com> References: <4A7AE416.5020403@math.unl.edu> <4A7AE505.6040607@redhat.com> <20090806152942.GD27350@victor.nirvana> <4A7AF950.50708@redhat.com> Message-ID: <4A82CBB6.7060408@hhs.nl> On 08/06/2009 05:40 PM, Tom "spot" Callaway wrote: > On 08/06/2009 11:29 AM, Axel Thimm wrote: > >> E.g. I think it is better to ">/dev/null 2>&1 || :" in this case > > The more I think about this, the more I agree. I'm not sure we'd ever > want to fail the build if the install-info command throws an error, so > squelching any noise there seems like the logical solution. > > Anyone disagree? > Nope, atleast not me +1 for > /dev/null Regards, Hans From a.badger at gmail.com Wed Aug 12 20:12:27 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 12 Aug 2009 13:12:27 -0700 Subject: [Fedora-packaging] Re: Fwd: Django plugin naming In-Reply-To: <6600c1b10908101152k2489d6eax199f0d9a5dec5db8@mail.gmail.com> References: <4A8049CC.1050000@gmail.com> <6600c1b10908101055k42ec2dd9n22aa8e3453e016bc@mail.gmail.com> <6600c1b10908101100y5e0cf69fy1590387ff6ca7a58@mail.gmail.com> <20090810184303.GC14281@arc.rdu.redhat.com> <6600c1b10908101152k2489d6eax199f0d9a5dec5db8@mail.gmail.com> Message-ID: <4A83222B.5060707@gmail.com> 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 > >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pbrobinson at gmail.com Thu Aug 13 11:08:44 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 13 Aug 2009 12:08:44 +0100 Subject: [Fedora-packaging] Package rename procedure Message-ID: <5256d0b0908130408o21712179q30730d49dd714c6c@mail.gmail.com> 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.2Freplacing_existing_packages [2] https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages From jussilehtola at fedoraproject.org Thu Aug 13 11:48:21 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 13 Aug 2009 14:48:21 +0300 Subject: [Fedora-packaging] Package rename procedure In-Reply-To: <5256d0b0908130408o21712179q30730d49dd714c6c@mail.gmail.com> References: <5256d0b0908130408o21712179q30730d49dd714c6c@mail.gmail.com> Message-ID: <1250164101.26726.22.camel@politzer.theorphys.helsinki.fi> On Thu, 2009-08-13 at 12:08 +0100, Peter Robinson wrote: > 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. Plug in the necessary obsoletes and provides in the spec file and open up a new review request as "Rename Request: foo - App that does bar". Once it's been reviewed (the reviewer checks that the package is sane and that the obsoletes and provides are correct) and approved you can import and build the new package and mark the old package as dead. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jussilehtola at fedoraproject.org Fri Aug 14 19:53:52 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 14 Aug 2009 22:53:52 +0300 Subject: [Fedora-packaging] Minor correction to the approved MPI draft Message-ID: <1250279632.3068.7.camel@localhost.localdomain> 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.2009-08-14-17.01.log.html#l-81 17:20:21 #topic FPC Items 17:20:26 .fesco 241 17:20:29 MPI? 17:20:42 There was something on the page that was confusing to me, let me find it. 17:21:24 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 +1 here for MPI. It makes sense to me... 17:21:59 that seems to be as "library configuration in /etc/ld.so.conf.d MUST NOT be made" -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From a.badger at gmail.com Fri Aug 14 20:05:56 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 14 Aug 2009 13:05:56 -0700 Subject: [Fedora-packaging] Minor correction to the approved MPI draft In-Reply-To: <1250279632.3068.7.camel@localhost.localdomain> References: <1250279632.3068.7.camel@localhost.localdomain> Message-ID: <4A85C3A4.2070505@gmail.com> On 08/14/2009 12:53 PM, Jussi Lehtola wrote: > 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. > Thanks Jussi (both for the correction and mentioning it here). The meaning is the same so this should be fine. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Thu Aug 20 21:24:37 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 20 Aug 2009 16:24:37 -0500 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width Message-ID: After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage: https://fedoraproject.org/wiki/PackagingDrafts/Tabs - J< From tcallawa at redhat.com Thu Aug 20 21:34:21 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 20 Aug 2009 17:34:21 -0400 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: <4A8DC15D.6000007@redhat.com> On 08/20/2009 05:24 PM, Jason L Tibbitts III wrote: > After seeing an argument in a review over someone using a five-space tab > width (?!), I submit the following for flameage: > > https://fedoraproject.org/wiki/PackagingDrafts/Tabs Someone went to the trouble to set a custom tab width? Man, I can only imagine what that does to Python. ~spot From jkeating at redhat.com Thu Aug 20 22:02:24 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Aug 2009 15:02:24 -0700 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8DC15D.6000007@redhat.com> References: <4A8DC15D.6000007@redhat.com> Message-ID: <1250805744.3107.84.camel@localhost.localdomain> On Thu, 2009-08-20 at 17:34 -0400, Tom "spot" Callaway wrote: > > Someone went to the trouble to set a custom tab width? Man, I can only > imagine what that does to Python. Anybody using real tabs in python should be shot anyway. All sensible code I come across uses four spaces for indentation in python. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Fri Aug 21 00:21:11 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 20 Aug 2009 17:21:11 -0700 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: On Thu, Aug 20, 2009 at 2:24 PM, Jason L Tibbitts III wrote: > After seeing an argument in a review over someone using a five-space tab > width (?!), I submit the following for flameage: > > https://fedoraproject.org/wiki/PackagingDrafts/Tabs This sounds good to me. Redefining tab width is an extraordinary bad idea, and horrendous for software development. MAMEdevs[1] everywhere should listen up! ;-) [1] http://mamedev.org From skvidal at fedoraproject.org Fri Aug 21 05:20:08 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 21 Aug 2009 01:20:08 -0400 (EDT) Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: On Thu, 20 Aug 2009, Jason L Tibbitts III wrote: > After seeing an argument in a review over someone using a five-space tab > width (?!), I submit the following for flameage: > > https://fedoraproject.org/wiki/PackagingDrafts/Tabs > how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death. -sv From rc040203 at freenet.de Fri Aug 21 05:27:42 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 07:27:42 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: <4A8E304E.2000306@freenet.de> On 08/20/2009 11:24 PM, Jason L Tibbitts III wrote: > After seeing an argument in a review over someone using a five-space tab > width (?!), I submit the following for flameage: > > https://fedoraproject.org/wiki/PackagingDrafts/Tabs -1 Tabs only add marginal unreadablity to specs. They might not taste everybody, but that's all. From Axel.Thimm at ATrpms.net Fri Aug 21 06:52:02 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Aug 2009 09:52:02 +0300 Subject: [Fedora-packaging] Re: Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: <20090821065202.GA27378@victor.nirvana> On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote: > On Thu, 20 Aug 2009, Jason L Tibbitts III wrote: > >> After seeing an argument in a review over someone using a five-space tab >> width (?!), I submit the following for flameage: >> >> https://fedoraproject.org/wiki/PackagingDrafts/Tabs >> > > how about no tabs at all. With the exception of fortran and makefiles > let's hang tabs out to die a cold, unloved death. Yes, please! Especially half-mixed specfiles are fun. Isn't there an emacs/vim mode for specfiles that could be modified to automatically untabbify specfiles upon the next edit? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rc040203 at freenet.de Fri Aug 21 06:58:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 08:58:04 +0200 Subject: [Fedora-packaging] Re: Strawman: standardize 8-space tab width In-Reply-To: <20090821065202.GA27378@victor.nirvana> References: <20090821065202.GA27378@victor.nirvana> Message-ID: <4A8E457C.4060208@freenet.de> On 08/21/2009 08:52 AM, Axel Thimm wrote: > On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote: >> On Thu, 20 Aug 2009, Jason L Tibbitts III wrote: >> >>> After seeing an argument in a review over someone using a five-space tab >>> width (?!), I submit the following for flameage: >>> >>> https://fedoraproject.org/wiki/PackagingDrafts/Tabs >>> >> >> how about no tabs at all. With the exception of fortran and makefiles >> let's hang tabs out to die a cold, unloved death. > > Yes, please! Especially half-mixed specfiles are fun. Isn't there an > emacs/vim mode for specfiles that could be modified to automatically > untabbify specfiles upon the next edit? ... and tab sensitive portions of a spec (such as Makefile fragments) will be corrupted ... From Axel.Thimm at ATrpms.net Fri Aug 21 07:18:59 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Aug 2009 10:18:59 +0300 Subject: [Fedora-packaging] Re: Strawman: standardize 8-space tab width In-Reply-To: <4A8E457C.4060208@freenet.de> References: <20090821065202.GA27378@victor.nirvana> <4A8E457C.4060208@freenet.de> Message-ID: <20090821071859.GC27378@victor.nirvana> On Fri, Aug 21, 2009 at 08:58:04AM +0200, Ralf Corsepius wrote: > On 08/21/2009 08:52 AM, Axel Thimm wrote: >> On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote: >>> On Thu, 20 Aug 2009, Jason L Tibbitts III wrote: >>> >>>> After seeing an argument in a review over someone using a five-space tab >>>> width (?!), I submit the following for flameage: >>>> >>>> https://fedoraproject.org/wiki/PackagingDrafts/Tabs >>>> >>> >>> how about no tabs at all. With the exception of fortran and makefiles >>> let's hang tabs out to die a cold, unloved death. >> >> Yes, please! Especially half-mixed specfiles are fun. Isn't there an >> emacs/vim mode for specfiles that could be modified to automatically >> untabbify specfiles upon the next edit? > > ... and tab sensitive portions of a spec (such as Makefile fragments) > will be corrupted ... There are people embedding Makefile fragments into specfiles? How many specfiles are there this way and how many packagers do we have to brainwash to not do that? :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Aug 21 07:21:30 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Aug 2009 02:21:30 -0500 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8E304E.2000306@freenet.de> (Ralf Corsepius's message of "Fri\, 21 Aug 2009 07\:27\:42 +0200") References: <4A8E304E.2000306@freenet.de> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> Tabs only add marginal unreadablity to specs. Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width. - J< From rc040203 at freenet.de Fri Aug 21 08:41:40 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 10:41:40 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: <4A8E304E.2000306@freenet.de> Message-ID: <4A8E5DC4.9030904@freenet.de> On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: >>>>>> "RC" == Ralf Corsepius writes: > > RC> Tabs only add marginal unreadablity to specs. > > Just to be clear, the proposal wasn't to eliminate tabs from specs, > although that was proposed later in the thread. The proposal was to > standardize a reasonable tab width. Define reasonable tab with. I guess you mean 8, but, whether you like it or not, there is no "standardized tab width". Conversely, there are huge user groups, who "standardized" to other tab widths, e.g. * Some BSDs systematically use a tab width of 4 everywhere. * Some vi users typically user a tab width of 3 (I am not using vi, so no idea where this originates from). * Many users apply a tab width of 2. * There are editors, which seem to guess on "best tab expansions". ... To all these user groups, fixing rpm's tab width to 8 would seem "greasy kid-stuff" (sorry if this appears rude to you, but it's how I feel about people who are complaining about tab widths). Ralf From rc040203 at freenet.de Fri Aug 21 08:45:45 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 10:45:45 +0200 Subject: [Fedora-packaging] Re: Strawman: standardize 8-space tab width In-Reply-To: <20090821071859.GC27378@victor.nirvana> References: <20090821065202.GA27378@victor.nirvana> <4A8E457C.4060208@freenet.de> <20090821071859.GC27378@victor.nirvana> Message-ID: <4A8E5EB9.4050702@freenet.de> On 08/21/2009 09:18 AM, Axel Thimm wrote: > On Fri, Aug 21, 2009 at 08:58:04AM +0200, Ralf Corsepius wrote: >> On 08/21/2009 08:52 AM, Axel Thimm wrote: >>> On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote: >>>> On Thu, 20 Aug 2009, Jason L Tibbitts III wrote: >>>> >>>>> After seeing an argument in a review over someone using a five-space tab >>>>> width (?!), I submit the following for flameage: >>>>> >>>>> https://fedoraproject.org/wiki/PackagingDrafts/Tabs >>>>> >>>> >>>> how about no tabs at all. With the exception of fortran and makefiles >>>> let's hang tabs out to die a cold, unloved death. >>> >>> Yes, please! Especially half-mixed specfiles are fun. Isn't there an >>> emacs/vim mode for specfiles that could be modified to automatically >>> untabbify specfiles upon the next edit? >> >> ... and tab sensitive portions of a spec (such as Makefile fragments) >> will be corrupted ... > > There are people embedding Makefile fragments into specfiles? I don't have an example at hand. > How many > specfiles are there this way and how many packagers do we have to > brainwash to not do that? :) There is "brainwashed" in appending/cat'ing tab-sensitive Makefile-/Fortran/sh/text etc. fragments in rpm specs. From jussilehtola at fedoraproject.org Fri Aug 21 08:46:10 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 21 Aug 2009 11:46:10 +0300 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8E5DC4.9030904@freenet.de> References: <4A8E304E.2000306@freenet.de> <4A8E5DC4.9030904@freenet.de> Message-ID: <1250844370.2611.2.camel@localhost.localdomain> On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote: > On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: > > Just to be clear, the proposal wasn't to eliminate tabs from specs, > > although that was proposed later in the thread. The proposal was to > > standardize a reasonable tab width. > > Define reasonable tab with. > > I guess you mean 8, but, whether you like it or not, there is no > "standardized tab width". > > Conversely, there are huge user groups, who "standardized" to other tab > widths, e.g. > > * Some BSDs systematically use a tab width of 4 everywhere. > * Some vi users typically user a tab width of 3 (I am not using vi, so > no idea where this originates from). > * Many users apply a tab width of 2. > * There are editors, which seem to guess on "best tab expansions". > ... These projects have standardized their tab widths. Why shouldn't Fedora? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pingou at pingoured.fr Fri Aug 21 08:54:31 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Fri, 21 Aug 2009 10:54:31 +0200 Subject: [Fedora-packaging] Meeting minutes Message-ID: <1250844871.13375.27.camel@pingouLab.pingoured.fr> Hello, I have been looking for the minutes of the last meetings of the packaging comittee but I couldn't find them on the wiki [1] or on the fedora-packaging or fedora-devel mailing list. Are they available somewhere ? Did I look in the wrong place ? Thanks in advance, Best regards, Pierre [1] http://fedoraproject.org/wiki/Packaging:Minutes From rc040203 at freenet.de Fri Aug 21 08:55:00 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 10:55:00 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <1250844370.2611.2.camel@localhost.localdomain> References: <4A8E304E.2000306@freenet.de> <4A8E5DC4.9030904@freenet.de> <1250844370.2611.2.camel@localhost.localdomain> Message-ID: <4A8E60E4.5070101@freenet.de> On 08/21/2009 10:46 AM, Jussi Lehtola wrote: > On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote: >> On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: >>> Just to be clear, the proposal wasn't to eliminate tabs from specs, >>> although that was proposed later in the thread. The proposal was to >>> standardize a reasonable tab width. >> >> Define reasonable tab with. >> >> I guess you mean 8, but, whether you like it or not, there is no >> "standardized tab width". >> >> Conversely, there are huge user groups, who "standardized" to other tab >> widths, e.g. >> >> * Some BSDs systematically use a tab width of 4 everywhere. >> * Some vi users typically user a tab width of 3 (I am not using vi, so >> no idea where this originates from). >> * Many users apply a tab width of 2. >> * There are editors, which seem to guess on "best tab expansions". >> ... > > These projects have standardized their tab widths. Why shouldn't Fedora? Why should it? Because some editors are unable to grok tabs in usable ways and because some newbies are unable to cope with it? From mattias.ellert at fysast.uu.se Fri Aug 21 08:59:41 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Fri, 21 Aug 2009 10:59:41 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: References: Message-ID: <1250845181.3633.3.camel@ellert.tsl.uu.se> tor 2009-08-20 klockan 16:24 -0500 skrev Jason L Tibbitts III: > After seeing an argument in a review over someone using a five-space tab > width (?!), I submit the following for flameage: > > https://fedoraproject.org/wiki/PackagingDrafts/Tabs > > - J< Rpmlint's check for mixed tab/space indentation assumes a tab width of 8. Using something different is likely to either trigger false warnings or not catch all problems. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Aug 21 09:06:19 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 21 Aug 2009 12:06:19 +0300 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8E5DC4.9030904@freenet.de> References: <4A8E5DC4.9030904@freenet.de> Message-ID: <200908211206.23111.ville.skytta@iki.fi> On Friday 21 August 2009, Ralf Corsepius wrote: > On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: > >>>>>> "RC" == Ralf Corsepius writes: > > > > RC> Tabs only add marginal unreadablity to specs. > > > > Just to be clear, the proposal wasn't to eliminate tabs from specs, > > although that was proposed later in the thread. The proposal was to > > standardize a reasonable tab width. > > Define reasonable tab with. > > I guess you mean 8, but, whether you like it or not, there is no > "standardized tab width". > > Conversely, there are huge user groups, who "standardized" to other tab > widths, e.g. > > * Some BSDs systematically use a tab width of 4 everywhere. > * Some vi users typically user a tab width of 3 (I am not using vi, so > no idea where this originates from). > * Many users apply a tab width of 2. > * There are editors, which seem to guess on "best tab expansions". > ... You seem to be talking about indent steps instead of tab widths. They are different things. A lot of projects and people tweak their indent steps to their liking (such as in the examples above), but defining tab width is much less common and having it set to anything else than 8 is pretty much guaranteed to have bad effects somewhere. From Axel.Thimm at ATrpms.net Fri Aug 21 09:13:05 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Aug 2009 12:13:05 +0300 Subject: [Fedora-packaging] Re: Strawman: standardize 8-space tab width In-Reply-To: <4A8E60E4.5070101@freenet.de> References: <4A8E304E.2000306@freenet.de> <4A8E5DC4.9030904@freenet.de> <1250844370.2611.2.camel@localhost.localdomain> <4A8E60E4.5070101@freenet.de> Message-ID: <20090821091305.GA3983@victor.nirvana> On Fri, Aug 21, 2009 at 10:55:00AM +0200, Ralf Corsepius wrote: > On 08/21/2009 10:46 AM, Jussi Lehtola wrote: >> On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote: >>> On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: >>>> Just to be clear, the proposal wasn't to eliminate tabs from specs, >>>> although that was proposed later in the thread. The proposal was to >>>> standardize a reasonable tab width. >>> >>> Define reasonable tab with. >>> >>> I guess you mean 8, but, whether you like it or not, there is no >>> "standardized tab width". >>> >>> Conversely, there are huge user groups, who "standardized" to other tab >>> widths, e.g. >>> >>> * Some BSDs systematically use a tab width of 4 everywhere. >>> * Some vi users typically user a tab width of 3 (I am not using vi, so >>> no idea where this originates from). >>> * Many users apply a tab width of 2. >>> * There are editors, which seem to guess on "best tab expansions". >>> ... >> >> These projects have standardized their tab widths. Why shouldn't Fedora? > > Why should it? Because some editors are unable to grok tabs in usable > ways and because some newbies are unable to cope with it? So, if it is proven that there is no sane standardization for tab widths and users/editors are unable to cope with the various tab widths, Fedora shouldn't mandate a tab width etc. then that's more of an argment to make away with tabs for good. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rc040203 at freenet.de Fri Aug 21 09:39:23 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Aug 2009 11:39:23 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <200908211206.23111.ville.skytta@iki.fi> References: <4A8E5DC4.9030904@freenet.de> <200908211206.23111.ville.skytta@iki.fi> Message-ID: <4A8E6B4B.7020100@freenet.de> On 08/21/2009 11:06 AM, Ville Skytt? wrote: > On Friday 21 August 2009, Ralf Corsepius wrote: >> On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote: >>>>>>>> "RC" == Ralf Corsepius writes: >>> >>> RC> Tabs only add marginal unreadablity to specs. >>> >>> Just to be clear, the proposal wasn't to eliminate tabs from specs, >>> although that was proposed later in the thread. The proposal was to >>> standardize a reasonable tab width. >> >> Define reasonable tab with. >> >> I guess you mean 8, but, whether you like it or not, there is no >> "standardized tab width". >> >> Conversely, there are huge user groups, who "standardized" to other tab >> widths, e.g. >> >> * Some BSDs systematically use a tab width of 4 everywhere. >> * Some vi users typically user a tab width of 3 (I am not using vi, so >> no idea where this originates from). >> * Many users apply a tab width of 2. >> * There are editors, which seem to guess on "best tab expansions". >> ... > > You seem to be talking about indent steps instead of tab widths. They are > different things. A lot of projects and people tweak their indent steps to > their liking (such as in the examples above), but defining tab width is much > less common and having it set to anything else than 8 is pretty much > guaranteed to have bad effects somewhere. Well, I don't understand your point. I am actually talking about the number of characters, tabs are being expanded into when displaying files in editors and the like. To make them "look nice" and "as desired", "tabbed indentation" and "display tab expansion" have to match. Classical examples would be BSD sources. They typically are 4-char indented, using a tab for each "4 chars". Ralf From jdennis at redhat.com Fri Aug 21 12:46:09 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 21 Aug 2009 08:46:09 -0400 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <200908211206.23111.ville.skytta@iki.fi> References: <4A8E5DC4.9030904@freenet.de> <200908211206.23111.ville.skytta@iki.fi> Message-ID: <4A8E9711.1040108@redhat.com> On 08/21/2009 05:06 AM, Ville Skytt? wrote: > You seem to be talking about indent steps instead of tab widths. They are > different things. A lot of projects and people tweak their indent steps to > their liking (such as in the examples above), but defining tab width is much > less common and having it set to anything else than 8 is pretty much > guaranteed to have bad effects somewhere. I think you might be mistaken. There is a group of people who believe there is an ASCII character whose semantic is "indent step". If something should be indented 2 levels then there should be two "indent step" characters which proceed it. They also believe how wide each indent step is is a per user preference. They have co-opted the ASCII tab character for this purpose. Some editors accommodate this philosophy by allowing each user to set their own "tab width" which expands each indent step character into the proper number of spaces. The argument over whether to use tabs and what their width is has been a holy war for as long as I've programmed. The proponents of "tab as indent step" have one major usability issue against them, you can never just open a text file and have it be readable unless you reset the tab width appropriately for each file. This is an enormous pain in the butt which is why the other camp is adamant about using spaces which have no ambiguity and require no special handling. Think of it as a portability issue. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kevin at tummy.com Fri Aug 21 16:00:10 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 21 Aug 2009 10:00:10 -0600 Subject: [Fedora-packaging] Meeting minutes In-Reply-To: <1250844871.13375.27.camel@pingouLab.pingoured.fr> References: <1250844871.13375.27.camel@pingouLab.pingoured.fr> Message-ID: <20090821100010.59508cb3@ohm.scrye.com> On Fri, 21 Aug 2009 10:54:31 +0200 Pierre-Yves wrote: > Hello, > > I have been looking for the minutes of the last meetings of the > packaging comittee but I couldn't find them on the wiki [1] or on the > fedora-packaging or fedora-devel mailing list. > Are they available somewhere ? Did I look in the wrong place ? > > Thanks in advance, > > Best regards, > Pierre > > > > [1] http://fedoraproject.org/wiki/Packaging:Minutes The minutes should be in the meetbot space: http://meetbot.fedoraproject.org/fedora-meeting/ Just look on the day/time that the meeting took place. The last one was: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.html for example. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Aug 21 16:05:04 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Aug 2009 11:05:04 -0500 Subject: [Fedora-packaging] Meeting minutes In-Reply-To: <20090821100010.59508cb3@ohm.scrye.com> (Kevin Fenzi's message of "Fri, 21 Aug 2009 10:00:10 -0600") References: <1250844871.13375.27.camel@pingouLab.pingoured.fr> <20090821100010.59508cb3@ohm.scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: KF> The minutes should be in the meetbot space: I guess that's not sufficiently visible that we can get away without linking to them from the Packaging:Minutes page. I'll add some links. - J< From pingou at pingoured.fr Fri Aug 21 16:14:10 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Fri, 21 Aug 2009 18:14:10 +0200 Subject: [Fedora-packaging] Meeting minutes In-Reply-To: References: <1250844871.13375.27.camel@pingouLab.pingoured.fr> <20090821100010.59508cb3@ohm.scrye.com> Message-ID: <1250871250.13375.31.camel@pingouLab.pingoured.fr> On Fri, 2009-08-21 at 11:05 -0500, Jason L Tibbitts III wrote: > >>>>> "KF" == Kevin Fenzi writes: > > KF> The minutes should be in the meetbot space: > > I guess that's not sufficiently visible that we can get away without > linking to them from the Packaging:Minutes page. I'll add some links. > Maybe not adding the link to all the minutes but maybe something like: From the /date/ the minutes are stored there: This would at least help to find them :-) Thanks for the information, Best regards, Pierre From ultrafredde at gmail.com Mon Aug 24 19:35:46 2009 From: ultrafredde at gmail.com (Federico Hernandez) Date: Mon, 24 Aug 2009 21:35:46 +0200 Subject: [Fedora-packaging] F-11 to F-12 transition In-Reply-To: References: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> Message-ID: <690f5ac90908241235j13a91c32o65e23ee3d400be2d@mail.gmail.com> > F-11 branched some time ago, and the current "devel" branch goes to > rawhide. ?As the F-12 release date gets closer, you will first have > the option to request an F-12 branch (an announcement will be sent > when this happens) and then, a bit later, all packages will acquire an > F-12 branch (which will be accompanied by an announcement and some > downtime). ?This happens much later in the release cycle, though; > nothing will happen for a few months. Now as I see a f-12 branch in common/branches how do I request that one - the normal way via the package's bugzilla entry from the packaging request (which was this spring) or is there another way for requesting the new branch for the new release? /Federico From ville.skytta at iki.fi Wed Aug 26 15:58:29 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 26 Aug 2009 18:58:29 +0300 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8E9711.1040108@redhat.com> References: <200908211206.23111.ville.skytta@iki.fi> <4A8E9711.1040108@redhat.com> Message-ID: <200908261858.29408.ville.skytta@iki.fi> On Friday 21 August 2009, John Dennis wrote: > I think you might be mistaken. There is a group of people who believe > there is an ASCII character whose semantic is "indent step". If > something should be indented 2 levels then there should be two "indent > step" characters which proceed it. I'm not one of those people. From xjakub at fi.muni.cz Wed Aug 26 22:40:35 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Thu, 27 Aug 2009 00:40:35 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <1248611938.2615.19.camel@localhost.localdomain> References: <1248611938.2615.19.camel@localhost.localdomain> Message-ID: <4A95B9E3.2010407@fi.muni.cz> The drafts have been approved both by FPC and FESCo, could someone please proceed with the following changes on the wiki? I've also want through other drafts and listed some more such cases -- there will be for sure many more, that's just what I remembered...and I'm running short on memory:). (Quoting from https://fedoraproject.org/wiki/Category:Packaging_guidelines_drafts:) [TO BE MOVED] * An approved new guideline will be moved to Packaging: (renamed as needed) and the category changed to Category:Packaging guidelines PackagingDrafts/EnvironmentModules PackagingDrafts/MPI PackagingDrafts/Fortran (a link to the "Application Specific Guidelines" section on the main Guidelines page should be imo added too) [TO BE MERGED & ARCHIVED] * An approved modification will be merged into existing guidelines and the draft will be moved to Archive: and the category changed to Category:Archived packaging guideline drafts PackagingDrafts/global_preferred_over_define PackagingDrafts/PatchUpstreamStatus PackagingDrafts/Epoch PackagingDrafts/ExplicitRequires PackagingDrafts/Haskell (all of them have been already merged into the main guidelines, Haskell has another page linked from there, so just archive) + PackagingDrafts/FortranModulesDir PackagingDrafts/FortranLibraries (invalidated by PackagingDrafts/Fortran, archive) + PackagingDrafts/DropScrollkeeperUpdate PackagingDrafts/JavaAntSampleSpec ProposalUpdateRGuidelines (not merged yet! there are more changes that need to be done -- read the drafts) Thanks, Milos From xjakub at fi.muni.cz Wed Aug 26 23:19:27 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Thu, 27 Aug 2009 01:19:27 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <4A95B9E3.2010407@fi.muni.cz> References: <1248611938.2615.19.camel@localhost.localdomain> <4A95B9E3.2010407@fi.muni.cz> Message-ID: <4A95C2FF.3020807@fi.muni.cz> > PackagingDrafts/global_preferred_over_define > PackagingDrafts/PatchUpstreamStatus > PackagingDrafts/Epoch > PackagingDrafts/ExplicitRequires > PackagingDrafts/Haskell > (all of them have been already merged into the main guidelines, Haskell has another page linked from there, so just archive) + PackagingDrafts/Symlinks to this group -- Milos From ryan.b.lynch at gmail.com Thu Aug 27 22:23:41 2009 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Thu, 27 Aug 2009 18:23:41 -0400 Subject: [Fedora-packaging] Compat packages: Any best practices, rules, guidelines? Message-ID: <115906d10908271523va657872ge4fcd3cc7e1ae257@mail.gmail.com> I'm trying to re-package a piece of software for Fedora. The catch is that this software depends about 15-20 specific versions of external libraries that Fedora ships, but only in a newer version. In several cases, this conflict is a deal-breaker--i.e., other installed software relies on the official Fedora library package/version, so I can't just replace the official RPM outright with a site-specific version. I would like to stay as close as possible to Fedora's packaging best practices. Even if I don't submit the resulting packages to Fedora for review, it's important to get as close to the guidelines as possible. >From what I understand, the "right" way to package multiple parallel versions of one library is the 'compat-*' convention ( http://docs.fedoraproject.org/drafts/rpm-guide-en/ch18s02.html has an overview). I took a look at the specs and manifests for a couple of existing compat packages, and I think I understand the concept pretty well. I think I can adapt the existing spec files and follow the conventions. But I have a lot of questions, too, and I was hoping that anybody in the know could help me. * Is anything about the compat convention standardized, or a matter of policy? I saw that the FESCO discussed about the issue, a while back, but I feel like I may have missed something more recent. * I can understand why large numbers of compat packages are frowned upon, and 15+ compats to support one measly application seems excessive, even to me. Is this the kind of thing that would torpedo a package review, completely? Or is there room for discussion, given a commitment to improve the situation (i.e., update the application) in time? * What kinds of compat packages, and what specifically about them, are considered bad? I've noticed that some compats don't appear to be included in Fedora, like 'compat-python24'. It seems like a useful package, but I'm seeing it in RPM Fusion--why didn't it pass review? * In the future, what direction is Fedora taking the compat convention? What kinds of long-term issues should I worry about, if I want to get ahead of the curve? If anyone can point me to existing resources on the compat subject, I would appreciate the links, too. Ryan B. Lynch ryan.b.lynch at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Fri Aug 28 05:13:10 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 27 Aug 2009 22:13:10 -0700 Subject: [Fedora-packaging] Compat packages: Any best practices, rules, guidelines? In-Reply-To: <115906d10908271523va657872ge4fcd3cc7e1ae257@mail.gmail.com> References: <115906d10908271523va657872ge4fcd3cc7e1ae257@mail.gmail.com> Message-ID: <4A976766.1090709@gmail.com> On 08/27/2009 03:23 PM, Ryan Lynch wrote: > But I have a lot of questions, too, and I was hoping that anybody in the > know could help me. > > * Is anything about the compat convention standardized, or a matter of > policy? I saw that the FESCO discussed about the issue, a while back, but I > feel like I may have missed something more recent. > I don't believe so but if someone cares they can submit a draft. We could certainly stand to standardize the use of compat-libfoo-1.0.2 vs libfoo1-1.0.2 for instance. > * I can understand why large numbers of compat packages are frowned upon, > and 15+ compats to support one measly application seems excessive, even to > me. Is this the kind of thing that would torpedo a package review, > completely? Or is there room for discussion, given a commitment to improve > the situation (i.e., update the application) in time? > I would torpedo it. But we don't have specific guidelines that cover this. So at the moment it's a matter of expressing the relative merits: On the plus side: Another package that someone wants would be added to Fedora. On the debit side: Fedora is not a dumping ground for unmaintained or poorly designed software (From "Non-objectives" on: http://fedoraproject.org/wiki/Objectives) Often times, compat-libraries are no longer maintained upstream. This places more burden on the packager to fix bugs and security issues without the aid of upstream. Fedora is about moving forward. Porting code forward to new libraries is certainly in line with this goal. writing patches to old library versions is not so much. > * What kinds of compat packages, and what specifically about them, are > considered bad? I've noticed that some compats don't appear to be included > in Fedora, like 'compat-python24'. It seems like a useful package, but I'm > seeing it in RPM Fusion--why didn't it pass review? > There's actually two kinds of compat packages. We don't follow one naming convention 100% for them but it's convenient to pretend we do: * compat-foo is not for packages in Fedora. It is the shared libraries that are necessary for thirdparty packages to run with the old versions of the libraries. * fooX-X.Y.Z is a version of the foo library at SONAME version X. This includes headers and anything else needed to compile packages against the library. compat-python24 is actually an example of the latter despite the name. There's several reasons its not in Fedora: * The python maintainer was against it * It's no longer maintained upstream * Having the interpreter and stdlib is only a small part of the python ecosystem. We'd really want to have python modules as well. unless we did something like Debian has, we'd need to have separate packages for each version -- so python-setuptools and python24-setuptools, python-psycopg and python24-psycopg, etc. Some people argue that all compat-foo packages are bad -- they're made for code that can't be ported (or in some cases, merely recompiled) against newer versions of libraries. This usually means proprietary applications. However, locally created programs that are just not distributed without thought to proprietary vs open source also fall into this at times. fooX-X.Y.Z is harder to justify a ban on. There are drawbacks like maintaining two stacks of a thing, puzzling out whether bug reports really need to target the old version or the new version, whether upstream supports both versions, how much work it is to make the two versions parallel installable, etc. But at times having the parallel installable versions is a saving grace until upstreams and other distros mobilise to help with the job of porting from one version of a library to the next. > * In the future, what direction is Fedora taking the compat convention? > What kinds of long-term issues should I worry about, if I want to get ahead > of the curve? > To my knowledge, the general direction is to get rid of as many old libraries as possible. Instead, we work with upstreams to port code to newer versions of libraries. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From chkr at fedoraproject.org Fri Aug 28 13:07:51 2009 From: chkr at fedoraproject.org (Christian Krause) Date: Fri, 28 Aug 2009 15:07:51 +0200 Subject: [Fedora-packaging] Strawman: standardize 8-space tab width In-Reply-To: <4A8E60E4.5070101@freenet.de> References: <4A8E304E.2000306@freenet.de> <4A8E5DC4.9030904@freenet.de> <1250844370.2611.2.camel@localhost.localdomain> <4A8E60E4.5070101@freenet.de> Message-ID: <4A97D6A7.5070709@fedoraproject.org> Hello, Ralf Corsepius wrote: > On 08/21/2009 10:46 AM, Jussi Lehtola wrote: >> These projects have standardized their tab widths. Why shouldn't Fedora? > > Why should it? Because some editors are unable to grok tabs in usable > ways and because some newbies are unable to cope with it? I was the reviewers who complained about the usage of a non-standard tab width. Please let me explain my intention behind this: 1. Spec files are not to be meant to be read only by the original packager. The should be in a format that _any_ packager can easily read and understand them. This is a quite generic requirement to all kind of communication. ;-) The current FPG cover this by requiring the legibility of the spec file. IMHO this does not include only meaningful comments, indentations etc., but also the overall formatting when the file is viewed within an editor. 2. If the file was written with a specific (non-standard, please see below) tab width, it is quite hard to read. Sure, it is possible to change the tab width in the editor, but the question is: to what? So in order to display the spec file correctly it is necessary to guess the used tab width. I really consider this as not very practical. 3. It is correct that different projects use different tab widths. However, there are some widths which are more often used and so became more or less "standard". IMHO vi(m), (x)emacs and even the web browser uses 8 chars tab width per default. (During reviews I use quite often the browser just to have a first glance a the provided spec file...) I definitively second that proposal. Best regards, Christian From chkr at fedoraproject.org Fri Aug 28 13:12:03 2009 From: chkr at fedoraproject.org (Christian Krause) Date: Fri, 28 Aug 2009 15:12:03 +0200 Subject: [Fedora-packaging] directory ownership in f-spot package Message-ID: <4A97D7A3.2040009@fedoraproject.org> Hi, Trying to fulfill all requirements regarding the directory ownership described here http://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership has some implications for the f-spot package: Please consider the following: A package (here f-spot) provides a screensaver plugin for gnome-screensaver in /usr/libexec/gnome-screensaver/ . I see 3 possible solutions how to handle the directory ownership of /usr/libexec/gnome-screensaver (which is already owned by gnome-screensaver package): 1. The most trivial way would be to let f-spot depend on the gnome-screensaver, don't own /usr/libexec/gnome-screensaver and just put its executable there. The drawback is that it may not be wanted that the installation of a photo managing software requires the installation of a specific screensaver. 2. The f-spot package could make use of the exception and own /usr/libexec/gnome-screensaver/ as well. However, the functionality-wise f-spot's screensaver would still depend on gnome-screensaver. There would be also the minor problem that the package would claim to provide a functionality in various menus which would not be there if gnome-screensaver would not be installed. 3. I could move screensaver part of f-spot into a sub-package. Only the sub-package would then require gnome-screensaver. This would properly satisfy all packaging requirements, but the users who want this functionality must install the sub-package manually since they will loose this feature during the update from the complete package to the one which is split in two parts. >From a packaging point of view I tend to choose option 3 despite its drawbacks. Would this be a good way? Best regards, Christian From jonstanley at gmail.com Fri Aug 28 13:33:43 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 28 Aug 2009 09:33:43 -0400 Subject: [Fedora-packaging] directory ownership in f-spot package In-Reply-To: <4A97D7A3.2040009@fedoraproject.org> References: <4A97D7A3.2040009@fedoraproject.org> Message-ID: On Fri, Aug 28, 2009 at 9:12 AM, Christian Krause wrote: > > >From a packaging point of view I tend to choose option 3 despite its > drawbacks. > > Would this be a good way? As far as I'm aware, given those three options, the third one seems most sane to me. Perhaps throw something in a README.fedora with an explanation so that users who want the screensaver know why it's not there and how to get it? From paul at city-fan.org Fri Aug 28 13:35:52 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 28 Aug 2009 14:35:52 +0100 Subject: [Fedora-packaging] directory ownership in f-spot package In-Reply-To: <4A97D7A3.2040009@fedoraproject.org> References: <4A97D7A3.2040009@fedoraproject.org> Message-ID: <4A97DD38.2030408@city-fan.org> On 28/08/09 14:12, Christian Krause wrote: > Hi, > > Trying to fulfill all requirements regarding the directory ownership > described here > http://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership > has some implications for the f-spot package: > > > Please consider the following: > A package (here f-spot) provides a screensaver plugin for > gnome-screensaver in /usr/libexec/gnome-screensaver/ . > > I see 3 possible solutions how to handle the directory ownership of > /usr/libexec/gnome-screensaver (which is already owned by > gnome-screensaver package): > > > 1. The most trivial way would be to let f-spot depend on the > gnome-screensaver, don't own /usr/libexec/gnome-screensaver and just put > its executable there. > The drawback is that it may not be wanted that the installation of a > photo managing software requires the installation of a specific screensaver. > > > 2. The f-spot package could make use of the exception and own > /usr/libexec/gnome-screensaver/ as well. However, the functionality-wise > f-spot's screensaver would still depend on gnome-screensaver. There > would be also the minor problem that the package would claim to provide > a functionality in various menus which would not be there if > gnome-screensaver would not be installed. > > > 3. I could move screensaver part of f-spot into a sub-package. Only the > sub-package would then require gnome-screensaver. This would properly > satisfy all packaging requirements, but the users who want this > functionality must install the sub-package manually since they will > loose this feature during the update from the complete package to the > one which is split in two parts. > > >> From a packaging point of view I tend to choose option 3 despite its > drawbacks. > > Would this be a good way? Yes, and you could work around the drawback by making the screensaver subpackage obsolete versions of f-spot prior to the package split, so that people upgrading would get the screensaver bit by way of the obsolete and the main package by being pulled in as a dependency of the screensaver subpackage. Paul. From qdlacz at gmail.com Fri Aug 28 16:22:07 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Fri, 28 Aug 2009 18:22:07 +0200 Subject: [Fedora-packaging] how to force rpmbuild to use local libraries? Message-ID: <1251476527.2100.14.camel@fiodor> Hi, I'm using Fedora 11, so all software in repository are stable ones, but I'm developing a library using unstable versions of them (e.g. I have now glibmm24 2.20, and I need it in version 2.21.3). I have those unstable versions installed in my home directory (that is `~/usr/') and I'm testing my library on them by using parallel environment provided by `jhbuild shell'. I decided to build a package with rpmbuild, but it uses `/usr/' path for everything (pkg-config files and such) even if I execute it from my parallel environment, so building the package ends quickly with message of unmet dependencies or in configure stage, when I pass `--nodeps' option. My question is: is there a way to force rpmbuild to use libraries in my home directory instead of those in `/usr/'? Thanks for your help, Krzem. From tcallawa at redhat.com Fri Aug 28 18:18:26 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 28 Aug 2009 14:18:26 -0400 Subject: [Fedora-packaging] how to force rpmbuild to use local libraries? In-Reply-To: <1251476527.2100.14.camel@fiodor> References: <1251476527.2100.14.camel@fiodor> Message-ID: <4A981F72.5080009@redhat.com> On 08/28/2009 12:22 PM, Krzesimir Nowak wrote: > Hi, > > I'm using Fedora 11, so all software in repository are stable ones, but > I'm developing a library using unstable versions of them (e.g. I have > now glibmm24 2.20, and I need it in version 2.21.3). I have those > unstable versions installed in my home directory (that is `~/usr/') and > I'm testing my library on them by using parallel environment provided by > `jhbuild shell'. I decided to build a package with rpmbuild, but it uses > `/usr/' path for everything (pkg-config files and such) even if I > execute it from my parallel environment, so building the package ends > quickly with message of unmet dependencies or in configure stage, when I > pass `--nodeps' option. My question is: is there a way to force rpmbuild > to use libraries in my home directory instead of those in `/usr/'? Well, to be fair, rpmbuild isn't to blame here. The spec file probably has something like: %configure --with-foo --with-bar That simply invokes configure with a set of sane options (including pointing to the system library/binary paths). For example, on my rawhide x86_64 system, %configure evaluates to: CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ; ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=x86_64-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/var/lib \ --mandir=/usr/share/man \ --infodir=/usr/share/info Now, if your spec file used "./configure" instead of "%configure", you could hardcode any of those paths into the spec that you want. It wouldn't be portable though. Even if that package built, it would still depend on things not packaged up, and complain on installation. As a possible alternative, if you can make packages for the unstable library dependencies, then you can build this package in a chroot where the unstable libraries are installed. Or, if the libraries have unique sonames, you should be able to have them both installed in system locations and eliminate the need for the chroot. hth, ~spot From qdlacz at gmail.com Fri Aug 28 19:41:31 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Fri, 28 Aug 2009 21:41:31 +0200 Subject: [Fedora-packaging] how to force rpmbuild to use local libraries? In-Reply-To: <4A981F72.5080009@redhat.com> References: <1251476527.2100.14.camel@fiodor> <4A981F72.5080009@redhat.com> Message-ID: <1251488491.2100.51.camel@fiodor> On Fri, 2009-08-28 at 14:18 -0400, Tom "spot" Callaway wrote: > On 08/28/2009 12:22 PM, Krzesimir Nowak wrote: > > Hi, > > > > I'm using Fedora 11, so all software in repository are stable ones, but > > I'm developing a library using unstable versions of them (e.g. I have > > now glibmm24 2.20, and I need it in version 2.21.3). I have those > > unstable versions installed in my home directory (that is `~/usr/') and > > I'm testing my library on them by using parallel environment provided by > > `jhbuild shell'. I decided to build a package with rpmbuild, but it uses > > `/usr/' path for everything (pkg-config files and such) even if I > > execute it from my parallel environment, so building the package ends > > quickly with message of unmet dependencies or in configure stage, when I > > pass `--nodeps' option. My question is: is there a way to force rpmbuild > > to use libraries in my home directory instead of those in `/usr/'? > > Well, to be fair, rpmbuild isn't to blame here. The spec file probably > has something like: > > %configure --with-foo --with-bar > > That simply invokes configure with a set of sane options (including > pointing to the system library/binary paths). For example, on my rawhide > x86_64 system, %configure evaluates to: > > CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic}" ; export CFLAGS ; > CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic}" ; export CXXFLAGS ; > FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ; > ./configure --build=x86_64-unknown-linux-gnu > --host=x86_64-unknown-linux-gnu \ > --target=x86_64-redhat-linux-gnu \ > --program-prefix= \ > --prefix=/usr \ > --exec-prefix=/usr \ > --bindir=/usr/bin \ > --sbindir=/usr/sbin \ > --sysconfdir=/etc \ > --datadir=/usr/share \ > --includedir=/usr/include \ > --libdir=/usr/lib64 \ > --libexecdir=/usr/libexec \ > --localstatedir=/var \ > --sharedstatedir=/var/lib \ > --mandir=/usr/share/man \ > --infodir=/usr/share/info > > Now, if your spec file used "./configure" instead of "%configure", you > could hardcode any of those paths into the spec that you want. It > wouldn't be portable though. Even if that package built, it would still > depend on things not packaged up, and complain on installation. But using ./configure with manually set options still will use pkg-config files from /usr/lib/pkgconfig instead of ~/usr/lib/pkgconfig. So configure stage will fail. Of course, I could define PATH (and other) environment variable before running ./configure, but that is not what I want and that blasts any portability away. > > As a possible alternative, if you can make packages for the unstable > library dependencies, then you can build this package in a chroot where > the unstable libraries are installed. Or, if the libraries have unique > sonames, you should be able to have them both installed in system > locations and eliminate the need for the chroot. > It probably will be better if I just wait until newest versions of libraries are packaged to rawhide (e.g gtkmm24 in rawhide is 2.17.2 and upstream is 2.17.9). Then I'll try to install rawhide as a second OS (I already failed at that once) and build a package there. Thanks for response, Krzem From tcallawa at redhat.com Fri Aug 28 20:26:54 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 28 Aug 2009 16:26:54 -0400 Subject: [Fedora-packaging] how to force rpmbuild to use local libraries? In-Reply-To: <1251488491.2100.51.camel@fiodor> References: <1251476527.2100.14.camel@fiodor> <4A981F72.5080009@redhat.com> <1251488491.2100.51.camel@fiodor> Message-ID: <4A983D8E.5040808@redhat.com> On 08/28/2009 03:41 PM, Krzesimir Nowak wrote: > But using ./configure with manually set options still will use > pkg-config files from /usr/lib/pkgconfig instead of ~/usr/lib/pkgconfig. > So configure stage will fail. Of course, I could define PATH (and other) > environment variable before running ./configure, but that is not what I > want and that blasts any portability away. Yeah, but to be honest, not having the dependencies packaged means that you've already lost portability. :) ~spot From qdlacz at gmail.com Fri Aug 28 20:51:33 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Fri, 28 Aug 2009 22:51:33 +0200 Subject: [Fedora-packaging] how to force rpmbuild to use local libraries? In-Reply-To: <4A983D8E.5040808@redhat.com> References: <1251476527.2100.14.camel@fiodor> <4A981F72.5080009@redhat.com> <1251488491.2100.51.camel@fiodor> <4A983D8E.5040808@redhat.com> Message-ID: <1251492693.3689.3.camel@fiodor> On Fri, 2009-08-28 at 16:26 -0400, Tom "spot" Callaway wrote: > Yeah, but to be honest, not having the dependencies packaged means that > you've already lost portability. :) No, no. Dependencies are packaged, but they are too old, even in Rawhide. I'm wondering if filing a bug mentioning about availability of new unstable upstream releases is good idea. Krzem From aakolov at gmail.com Sat Aug 29 06:39:15 2009 From: aakolov at gmail.com (Andrey A.Kolov) Date: Sat, 29 Aug 2009 10:39:15 +0400 Subject: [Fedora-packaging] bringing back to life a package (drivel) Message-ID: <1251527955.8868.40.camel@FZ11MR-AK> Hi, I would like to pick up a drivel (blog tool) package. It is in the list of Retired packages since July 2008, as upstream was frozen at that time. Now it seems alive, new version was released in April 2009. I have contacted Paul W.Frields (who has maintained drivel in Fedora) some time ago and he was keen to offer me maintaining this package. I have checked on koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=1636387) and it seems that old source are good enough to work on F11. My idea is to bring old version to F11 now until I will finish accommodating new sources. However, if this approach is not in line with rules and policies I will be glad to follow your advises. In any case, I will need some coaching. Is it possible for someone to spend a little bit time with me on IRC (@fedora-devel, probably) to understand further steps and actions ? Thanking you in advance, Andrey From paul at all-the-johnsons.co.uk Sat Aug 29 07:50:41 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 29 Aug 2009 08:50:41 +0100 Subject: [Fedora-packaging] bringing back to life a package (drivel) In-Reply-To: <1251527955.8868.40.camel@FZ11MR-AK> References: <1251527955.8868.40.camel@FZ11MR-AK> Message-ID: <1251532241.1942.12.camel@PB3.linux> Hi, > I have checked on koji > (https://koji.fedoraproject.org/koji/taskinfo?taskID=1636387) and it > seems that old source are good enough to work on F11. My idea is to > bring old version to F11 now until I will finish accommodating new > sources. However, if this approach is not in line with rules and > policies I will be glad to follow your advises. You're better off using the old spec file (and possibly patches) and building the new sources rather than the approach you suggest. In all probability, you'll need to fix a pile of things, drop old patches, add new patches, test, test and test some more. > In any case, I will need some coaching. Is it possible for someone to > spend a little bit time with me on IRC (@fedora-devel, probably) to > understand further steps and actions ? Unfortunately, I can't get to IRC, but feel free to ask any questions :-) TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aakolov at gmail.com Sat Aug 29 19:05:36 2009 From: aakolov at gmail.com (Andrey A.Kolov) Date: Sat, 29 Aug 2009 23:05:36 +0400 Subject: [Fedora-packaging] bringing back to life a package (drivel) In-Reply-To: <1251532241.1942.12.camel@PB3.linux> References: <1251527955.8868.40.camel@FZ11MR-AK> <1251532241.1942.12.camel@PB3.linux> Message-ID: <1251572736.8868.118.camel@FZ11MR-AK> Hi, Paul, Thank you for your support. Generally, I have a lot of stupid rookie-type questions that probably are covered somewhere in documentation, but there are many things to learn and I do not know what to start with. I wonder if my questions need to be posted in mailing list. Shall we continue in public or it is OK for direct mails ? Regards, Andrey ? ???, 29/08/2009 ? 08:50 +0100, Paul ?????: > Hi, > > > I have checked on koji > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=1636387) and it > > seems that old source are good enough to work on F11. My idea is to > > bring old version to F11 now until I will finish accommodating new > > sources. However, if this approach is not in line with rules and > > policies I will be glad to follow your advises. > > You're better off using the old spec file (and possibly patches) and > building the new sources rather than the approach you suggest. In all > probability, you'll need to fix a pile of things, drop old patches, add > new patches, test, test and test some more. > > > In any case, I will need some coaching. Is it possible for someone to > > spend a little bit time with me on IRC (@fedora-devel, probably) to > > understand further steps and actions ? > > Unfortunately, I can't get to IRC, but feel free to ask any > questions :-) > > TTFN > > Paul > From rdieter at math.unl.edu Sat Aug 29 20:00:48 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 29 Aug 2009 15:00:48 -0500 Subject: [Fedora-packaging] Re: F-11 to F-12 transition References: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> <690f5ac90908241235j13a91c32o65e23ee3d400be2d@mail.gmail.com> Message-ID: Federico Hernandez wrote: > Now as I see a f-12 branch in common/branches how do I request that > one - the normal way via the package's bugzilla entry from the > packaging request (which was this spring) or is there another way for > requesting the new branch for the new release? For posterity: https://www.redhat.com/archives/fedora-devel-announce/2009- August/msg00010.html -- Rex From phrkonaleash at gmail.com Mon Aug 31 05:55:24 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Sun, 30 Aug 2009 22:55:24 -0700 Subject: [Fedora-packaging] Packaging a game, need help with setgid security Message-ID: Hello group, I have recently finished packaging the game IVAN (http://ivan.sf.net) for Fedora 11: Iter Vehemens ad Necum is a graphical roguelike game. It features advanced bodypart and material handling, multi-colored lighting and, above all, deep gameplay. Like many roguelikes, it has a shared high score file and Bones files that all users are meant to have their scores and final data written to. As a result, the game is forced to run setgid games so that it has the rights to write to /var/games/ivan/. While packaging this application, I got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and they both suggested I run this through Fedora Security SIG so that the game would properly demote itself to non-setgid when it doesn't need to. What is the proper channel to go about this? Should I just mail to the security list? Should I put this package up for review beforehand/in the meantime? Thanks and Best, Ryan Rix -- Ryan Rix (623)-826-0051 Fortune: I'm DESPONDENT ... I hope there's something DEEP-FRIED under this miniature DOMED STADIUM ... http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From musuruan at gmail.com Mon Aug 31 08:41:47 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Mon, 31 Aug 2009 10:41:47 +0200 Subject: [Fedora-packaging] Packaging a game, need help with setgid security In-Reply-To: References: Message-ID: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> On Mon, Aug 31, 2009 at 7:55 AM, Ryan Rix wrote: > Like many roguelikes, it has a shared high score file and Bones files that > all users are meant to have their scores and final data written to. As a > result, the game is forced to run setgid games so that it has the rights to > write to /var/games/ivan/. While packaging this application, I got a lot of > help from some of the Fedora-KDE guys (hi Kevin, Ben) and they both > suggested I run this through Fedora Security SIG so that the game would > properly demote itself to non-setgid when it doesn't need to. > > What is the proper channel to go about this? Should I just mail to the > security list? Should I put this package up for review beforehand/in the > meantime? The game must drop setuid as early as possible: http://fedoraproject.org/wiki/SIGs/Games/Packaging If you need help, consider writing to the fedora-games-list: http://www.redhat.com/mailman/listinfo/fedora-games-list Bye, Andrea. From a.badger at gmail.com Mon Aug 31 16:25:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 31 Aug 2009 09:25:18 -0700 Subject: [Fedora-packaging] bringing back to life a package (drivel) In-Reply-To: <1251572736.8868.118.camel@FZ11MR-AK> References: <1251527955.8868.40.camel@FZ11MR-AK> <1251532241.1942.12.camel@PB3.linux> <1251572736.8868.118.camel@FZ11MR-AK> Message-ID: <4A9BF96E.7010704@gmail.com> On 08/29/2009 12:05 PM, Andrey A.Kolov wrote: > Hi, Paul, > > Thank you for your support. Generally, I have a lot of stupid > rookie-type questions that probably are covered somewhere in > documentation, but there are many things to learn and I do not know what > to start with. > > I wonder if my questions need to be posted in mailing list. Shall we > continue in public or it is OK for direct mails ? > There are many people on #fedora-devel who would be willing to help you update the package and coach you through the process. I think the package has been retired for long enough that you'll need to do a new package review for it. That will be an opportunity to get some coaching on what happens to it as well. You probably want to read the wiki pages having to do with package reviews and try to apply them to the updated drivel. Then (either when stuck or wanting some feedback), you can ask on #fedora-devel for some help. Overview of the package review process: https://fedoraproject.org/wiki/Package_Review_Process Packaging Guidelines, all packages should comply with these requirements: https://fedoraproject.org/wiki/Packaging/Guidelines More of a summary format for the guidelines: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: