From tibbs at math.uh.edu Wed Aug 1 17:19:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Aug 2007 12:19:02 -0500 Subject: [Fedora-packaging] scrollkeeper snippets Message-ID: Is there some reason the scrollkeeper examples in http://fedoraproject.org/wiki/Packaging/ScriptletSnippets don't redirect output to /dev/null? - J< From mtasaka at ioa.s.u-tokyo.ac.jp Wed Aug 1 17:24:05 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 02 Aug 2007 02:24:05 +0900 Subject: [Fedora-packaging] scrollkeeper snippets In-Reply-To: References: Message-ID: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> Jason L Tibbitts III wrote, at 08/02/2007 02:19 AM +9:00: > Is there some reason the scrollkeeper examples in > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets don't > redirect output to /dev/null? > I guess because man scrollkeeper-update says that messages are suppressed by "-q" option but for "the most serious warning and error messages"? Mamoru From mclasen at redhat.com Wed Aug 1 17:25:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 01 Aug 2007 13:25:34 -0400 Subject: [Fedora-packaging] scrollkeeper snippets In-Reply-To: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> References: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> Message-ID: <1185989134.3330.0.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-02 at 02:24 +0900, Mamoru Tasaka wrote: > Jason L Tibbitts III wrote, at 08/02/2007 02:19 AM +9:00: > > Is there some reason the scrollkeeper examples in > > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets don't > > redirect output to /dev/null? > > > > I guess because man scrollkeeper-update says that messages are > suppressed by "-q" option but for "the most serious warning and > error messages"? > Before you spend too much time worrying about scrollkeeper snipplets, you should be aware that we are about to obsolete scrollkeeper by a new system that does away with the need for such snipplets (rarian). From tibbs at math.uh.edu Wed Aug 1 17:36:39 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Aug 2007 12:36:39 -0500 Subject: [Fedora-packaging] scrollkeeper snippets In-Reply-To: <1185989134.3330.0.camel@dhcp83-186.boston.redhat.com> References: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> <1185989134.3330.0.camel@dhcp83-186.boston.redhat.com> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> Before you spend too much time worrying about scrollkeeper MC> snipplets, you should be aware that we are about to obsolete MC> scrollkeeper by a new system that does away with the need for such MC> snipplets (rarian). I guess you can ignore that portion of the zenity review I just did, then. - J< From Axel.Thimm at ATrpms.net Wed Aug 1 19:29:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 21:29:35 +0200 Subject: [Fedora-packaging] Re: scrollkeeper snippets In-Reply-To: References: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> <1185989134.3330.0.camel@dhcp83-186.boston.redhat.com> Message-ID: <20070801192935.GB2995@puariko.nirvana> On Wed, Aug 01, 2007 at 12:36:39PM -0500, Jason L Tibbitts III wrote: > >>>>> "MC" == Matthias Clasen writes: > > MC> Before you spend too much time worrying about scrollkeeper > MC> snipplets, you should be aware that we are about to obsolete > MC> scrollkeeper by a new system that does away with the need for such > MC> snipplets (rarian). > > I guess you can ignore that portion of the zenity review I just did, > then. It depends on when Matthias will deploy the new system. Matthias, is that a F8 item? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Wed Aug 1 19:30:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 01 Aug 2007 15:30:03 -0400 Subject: [Fedora-packaging] Re: scrollkeeper snippets In-Reply-To: <20070801192935.GB2995@puariko.nirvana> References: <46B0C1B5.1000705@ioa.s.u-tokyo.ac.jp> <1185989134.3330.0.camel@dhcp83-186.boston.redhat.com> <20070801192935.GB2995@puariko.nirvana> Message-ID: <1185996603.3330.19.camel@dhcp83-186.boston.redhat.com> On Wed, 2007-08-01 at 21:29 +0200, Axel Thimm wrote: > On Wed, Aug 01, 2007 at 12:36:39PM -0500, Jason L Tibbitts III wrote: > > >>>>> "MC" == Matthias Clasen writes: > > > > MC> Before you spend too much time worrying about scrollkeeper > > MC> snipplets, you should be aware that we are about to obsolete > > MC> scrollkeeper by a new system that does away with the need for such > > MC> snipplets (rarian). > > > > I guess you can ignore that portion of the zenity review I just did, > > then. > > It depends on when Matthias will deploy the new system. Matthias, is > that a F8 item? Yes, rarian will appear in rawhide in the next few days. From opensource at till.name Thu Aug 2 21:26:00 2007 From: opensource at till.name (Till Maas) Date: Thu, 2 Aug 2007 23:26:00 +0200 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r Message-ID: <200708022326.10721.opensource@till.name> Aloas, is it ok to use multiple changelog entries for one e-v-r? E.g.: %changelog * Thu Jun 15 2003 Joe Packager - 1.0-2 - Added LICENSE file (#43). * Wed Jun 14 2003 Joe Packager - 1.0-2 - Added README file (#42). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ville.skytta at iki.fi Thu Aug 2 21:30:52 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 3 Aug 2007 00:30:52 +0300 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r In-Reply-To: <200708022326.10721.opensource@till.name> References: <200708022326.10721.opensource@till.name> Message-ID: <200708030030.52749.ville.skytta@iki.fi> On Friday 03 August 2007, Till Maas wrote: > Aloas, > > is it ok to use multiple changelog entries for one e-v-r? > > E.g.: > > %changelog > * Thu Jun 15 2003 Joe Packager - 1.0-2 > - Added LICENSE file (#43). > > * Wed Jun 14 2003 Joe Packager - 1.0-2 > - Added README file (#42). I'm not sure what that would be useful for - people looking for changes between x.y-z and 1.0-2 would start to wonder what exactly did happen in 1.0-2 and whether one of the above is a copy-pasto and should be eg. 1.0-3 instead. Personally I just leave out the version from changes I make without building a package, and sometimes combine accumulated changes into one changelog entry when finally building them. From jkeating at redhat.com Thu Aug 2 21:30:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Aug 2007 17:30:35 -0400 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r In-Reply-To: <200708022326.10721.opensource@till.name> References: <200708022326.10721.opensource@till.name> Message-ID: <20070802173035.7bf75622@localhost.localdomain> On Thu, 2 Aug 2007 23:26:00 +0200 Till Maas wrote: > Aloas, > > is it ok to use multiple changelog entries for one e-v-r? > > E.g.: > > %changelog > * Thu Jun 15 2003 Joe Packager - 1.0-2 > - Added LICENSE file (#43). > > * Wed Jun 14 2003 Joe Packager - 1.0-2 > - Added README file (#42). Why not just lump them all into the latest date that you make changes? Often times I make a change, and if the build doesn't work or I don't get to it right away, then the next day I make another change, I just mark the date as that day and list both changes under that day/nvr. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Thu Aug 2 21:31:43 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 02 Aug 2007 17:31:43 -0400 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r In-Reply-To: <200708022326.10721.opensource@till.name> References: <200708022326.10721.opensource@till.name> Message-ID: <46B24D3F.9070203@redhat.com> Till Maas wrote: > Aloas, > > is it ok to use multiple changelog entries for one e-v-r? > > E.g.: > > %changelog > * Thu Jun 15 2003 Joe Packager - 1.0-2 > - Added LICENSE file (#43). > > * Wed Jun 14 2003 Joe Packager - 1.0-2 > - Added README file (#42). I'd say no. Just put both changes under one entry w/the most recent date. At least, that's what I do. I believe rpmlint may complain about the above case, and if not, it probably should, since its bogus to have two different builds w/the same evr. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Fri Aug 3 16:44:41 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Aug 2007 12:44:41 -0400 Subject: [Fedora-packaging] Package EOL procedure when merging two packages Message-ID: <20070803164441.GG29372@psilocybe.teonanacatl.org> Hola, I want to get a sanity check on something so I don't cause any dep problems. I'm planning to merge the python-gpod package into the main libgpod package (it was originally built separately due to requirements on Extras packages). This is planned for devel first, and then eventually F7. As I understand it, I should: a) add a dead.package file in the devel branch for python-gpod explaining that it's been merged with libgpod, and delete the other files from the branch. b) ask rel-eng to block the package from devel. I'm unsure about b. Can anyone help clarify this and let me know if I'm missing other steps? (The package isn't in comps and will remain in FC6 for sure, and F7 for a little while at least -- so steps 3 and 4 on PackageMaintainers/PackageEndOfLife aren't relevant.) Thanks, -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If quitters never win, and winners never quit, then who is the fool who said "Quit while you're ahead?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Aug 3 17:05:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 3 Aug 2007 17:05:03 +0000 (UTC) Subject: [Fedora-packaging] Re: Package EOL procedure when merging two packages References: <20070803164441.GG29372@psilocybe.teonanacatl.org> Message-ID: Todd Zullinger pobox.com> writes: > This is planned for devel first, and then eventually F7. As I > understand it, I should: > > a) add a dead.package file in the devel branch for python-gpod > explaining that it's been merged with libgpod, and delete the other > files from the branch. > > b) ask rel-eng to block the package from devel. That's what I did for redhat-artwork-kde. Kevin Kofler From jkeating at redhat.com Fri Aug 3 17:17:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Aug 2007 13:17:23 -0400 Subject: [Fedora-packaging] Package EOL procedure when merging two packages In-Reply-To: <20070803164441.GG29372@psilocybe.teonanacatl.org> References: <20070803164441.GG29372@psilocybe.teonanacatl.org> Message-ID: <20070803131723.4c2dbe3e@ender> On Fri, 3 Aug 2007 12:44:41 -0400 Todd Zullinger wrote: > b) ask rel-eng to block the package from devel. I suppose I should mark this as instead of 'devel' as 'any place the package is being removed from'. Typically we don't kill packages in released Fedoras, but for the obsoletes case we do, and thus we'd need to block it from F7 as well. > > I'm unsure about b. Can anyone help clarify this and let me know if > I'm missing other steps? (The package isn't in comps and will remain > in FC6 for sure, and F7 for a little while at least -- so steps 3 and > 4 on PackageMaintainers/PackageEndOfLife aren't relevant.) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Fri Aug 3 17:09:35 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Aug 2007 13:09:35 -0400 Subject: [Fedora-packaging] Package EOL procedure when merging two packages In-Reply-To: <20070803131723.4c2dbe3e@ender> References: <20070803164441.GG29372@psilocybe.teonanacatl.org> <20070803131723.4c2dbe3e@ender> Message-ID: <20070803170935.GB2564@psilocybe.teonanacatl.org> Jesse Keating wrote: > I suppose I should mark this as instead of 'devel' as 'any place the > package is being removed from'. Typically we don't kill packages in > released Fedoras, but for the obsoletes case we do, and thus we'd > need to block it from F7 as well. The wording on the wiki does seem clear: "Send mail to rel-eng at fedoraproject.org asking the package to be blocked from the appropriate collections in which it is retired." I used devel in my message since that's where it would be removed from first. I don't know if it'd be slightly clearer to say branches instead of collections. (And I take this as a yes that I'll need to follow that step. Thanks!) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Only government can take perfectly good paper, cover it with perfectly good ink and make the combination worthless. -- Milton Friedman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Aug 6 10:36:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 6 Aug 2007 13:36:49 +0300 Subject: [Fedora-packaging] Missing this (and maybe next) week's meeting Message-ID: <200708061336.49941.ville.skytta@iki.fi> Hi, I'm going to miss this week's FPC meeting, as well as possibly next week's one. From dlutter at redhat.com Mon Aug 6 16:18:42 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 06 Aug 2007 17:18:42 +0100 Subject: [Fedora-packaging] Missing this (and maybe next) week's meeting In-Reply-To: <200708061336.49941.ville.skytta@iki.fi> References: <200708061336.49941.ville.skytta@iki.fi> Message-ID: <1186417122.3985.3.camel@galia.watzmann.net> On Mon, 2007-08-06 at 13:36 +0300, Ville Skytt? wrote: > I'm going to miss this week's FPC meeting, as well as possibly next week's > one. I will have to miss the next two meetings, too. David From ville.skytta at iki.fi Mon Aug 6 20:05:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 6 Aug 2007 23:05:50 +0300 Subject: [Fedora-packaging] Licensing guidelines suggestions Message-ID: <200708062305.50583.ville.skytta@iki.fi> Hello, Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks): 1) The licensing pages strongly imply that OSI-approved licenses are ok. However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php 2) The Wiki pages refer to "files" and "content" without specifying whether those refer to files/content in the source rpm, the resulting binary rpms, or both. Example case: an upstream source tarball contains source files under let's say BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary built from all those would fall under GPLv2+. Specifying GPLv2+ as the License tag would be misrepresenting the copyrights of the files in the source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined work in the resulting binary. 3) Source licenses are not the only thing that affect the distributables' copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses). Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them. From tcallawa at redhat.com Mon Aug 6 20:48:07 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 06 Aug 2007 16:48:07 -0400 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <200708062305.50583.ville.skytta@iki.fi> References: <200708062305.50583.ville.skytta@iki.fi> Message-ID: <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> On Mon, 2007-08-06 at 23:05 +0300, Ville Skytt? wrote: > Hello, > > Here's a few notes/questions that IMO need to be addressed in the new > licensing guidelines in Wiki. IANAL, etc, but anyway, something for near > future FPC meetings (which I still probably won't be able to attend to for a > couple of weeks): > > 1) The licensing pages strongly imply that OSI-approved licenses are ok. > However for example the original Artistic license is OSI-approved but listed > in Wiki page as "bad". Something needs real fixing - "ask upstream to move > to a "good" Artistic license" is IMO just a band aid. > http://fedoraproject.org/wiki/Licensing > http://www.opensource.org/licenses/artistic-license.php I think we're going to need the Fedora Board to decide this. Its a little outside of our jurisdiction, unfortunately. > 2) The Wiki pages refer to "files" and "content" without specifying whether > those refer to files/content in the source rpm, the resulting binary rpms, or > both. > > Example case: an upstream source tarball contains source files under let's say > BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary > built from all those would fall under GPLv2+. Specifying GPLv2+ as the > License tag would be misrepresenting the copyrights of the files in the > source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and > LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined > work in the resulting binary. My interpretation is that the License: tag represents the license/copyright on the bits in the binary rpm. Again, keep in mind that the License: tag is not legally binding, so its more of a helpful tool for initial auditing, and not much more. > 3) Source licenses are not the only thing that affect the distributables' > copyrights. For example when something is built from let's say LGPLv2+ > sources but linked with a GPLv2+ library, the resulting binary will be > GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright > notices are changed to GPLv2+, but that can't be done for many *GPL > licenses). > > > Suggested combined fix for 2) and 3) above: change the licensing guidelines to > prominently note something like that the value of the License tag represents > the copyright/license info of binary packages only, and only when built in > the configuration specified by the Fedora build system, build > dependencies/conflicts in the specfile, and no non-Fedora software installed > that will affect the build in any way. Source rpms' copyrights are > determined by the sources and other content included in them. This seems fine to me. I'll work on drafting a change for vote. ~spot From ville.skytta at iki.fi Mon Aug 6 21:16:35 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 7 Aug 2007 00:16:35 +0300 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> Message-ID: <200708070016.36100.ville.skytta@iki.fi> On Monday 06 August 2007, Tom "spot" Callaway wrote: > On Mon, 2007-08-06 at 23:05 +0300, Ville Skytt? wrote: > > Hello, > > > > Here's a few notes/questions that IMO need to be addressed in the new > > licensing guidelines in Wiki. IANAL, etc, but anyway, something for near > > future FPC meetings (which I still probably won't be able to attend to > > for a couple of weeks): > > > > 1) The licensing pages strongly imply that OSI-approved licenses are ok. > > However for example the original Artistic license is OSI-approved but > > listed in Wiki page as "bad". Something needs real fixing - "ask > > upstream to move to a "good" Artistic license" is IMO just a band aid. > > http://fedoraproject.org/wiki/Licensing > > http://www.opensource.org/licenses/artistic-license.php > > I think we're going to need the Fedora Board to decide this. Its a > little outside of our jurisdiction, unfortunately. Ok, I'll forward the question to fab-list, hopefully they'll pick this up. [...] > > 3) Source licenses are not the only thing that affect the distributables' > > copyrights. For example when something is built from let's say LGPLv2+ > > sources but linked with a GPLv2+ library, the resulting binary will be > > GPLv2+, while the sources are still LGPLv2+ (unless their embedded > > copyright notices are changed to GPLv2+, but that can't be done for many > > *GPL licenses). (Meant to say "... but that can't be done for many non-*GPL licenses.") > > Suggested combined fix for 2) and 3) above: change the licensing > > guidelines to prominently note something like that the value of the > > License tag represents the copyright/license info of binary packages > > only, and only when built in the configuration specified by the Fedora > > build system, build > > dependencies/conflicts in the specfile, and no non-Fedora software > > installed that will affect the build in any way. Source rpms' copyrights > > are determined by the sources and other content included in them. > > This seems fine to me. I'll work on drafting a change for vote. Thanks. You can count me as +1 if the exact text to be voted on won't differ drastically from the above. From jonathan.underwood at gmail.com Mon Aug 6 22:28:38 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 6 Aug 2007 23:28:38 +0100 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" Message-ID: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> Hi, Jindrich Novy has been preparing texlive packages for F8 for a while now, and there are essentially 3 RPMs: telive (the binaries) texlive-texmf (the texmf tree) and texlive-texmf-errata The one I am concerned about is telive-texmf-errata. As Jindrich says "This is the errata package for the TeXLive 2007 formatting system. The purpose of this package is to support updates to huge texmf tree without a need to download all the texmf tree again, but to ship only the fixed parts. texlive-errata puts updated files into a seperate texmf tree which is searched prior to the main tree so there are no conflicts between texlive-errata and texlive-texmf packages." I think this is a totally different packaging paradigm - as far as I'm aware there's no precedent in Fedora for issuing errata packages rather than updated packages. A far better alternative IMO is to have finer grained subpackaging of the texlive texmf tree, such that updates don't replace the whole thing. That of course has other major advantages, such as allowing smaller tex installs. Also, to have *two* system managed texmf trees searched is a big change, and something else that system admins have to think about when they add their own local texmf trees. Put more bluntly, while I understand the convenience from a packagers point of view, this seems like a really ugly way to package. It feels a bit like the ever increasing number of hotfixes you get installed on an M$ system (although there would never be more than a single texmf-errata package installed at a time of course). I know Rex Dieter likes the errata package idea. I wonder what others think? Cheers, Jonathan From pertusus at free.fr Mon Aug 6 22:31:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 7 Aug 2007 00:31:55 +0200 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> Message-ID: <20070806223155.GB4653@free.fr> On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > Hi, > > I know Rex Dieter likes the errata package idea. I wonder what others think? I think that such decisions should be left to the packagers, as long as it is not obviously wrong. A bit like split choices. -- Pat From opensource at till.name Mon Aug 6 22:48:19 2007 From: opensource at till.name (Till Maas) Date: Tue, 07 Aug 2007 00:48:19 +0200 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r In-Reply-To: <20070802173035.7bf75622@localhost.localdomain> References: <200708022326.10721.opensource@till.name> <20070802173035.7bf75622@localhost.localdomain> Message-ID: <200708070048.20641.opensource@till.name> On Do August 2 2007, Jesse Keating wrote: > On Thu, 2 Aug 2007 23:26:00 +0200 > > Till Maas wrote: > > is it ok to use multiple changelog entries for one e-v-r? > > > > E.g.: > > > > %changelog > > * Thu Jun 15 2003 Joe Packager - 1.0-2 > > - Added LICENSE file (#43). > > > > * Wed Jun 14 2003 Joe Packager - 1.0-2 > > - Added README file (#42). > > Why not just lump them all into the latest date that you make changes? Because I did not find a vim plugin, that supports this, yet. > Often times I make a change, and if the build doesn't work or I don't > get to it right away, then the next day I make another change, I just > mark the date as that day and list both changes under that day/nvr. Do you do this manually? Regards, Till From jkeating at redhat.com Mon Aug 6 23:55:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 19:55:59 -0400 Subject: [Fedora-packaging] multiple changlog entries for one e-v-r In-Reply-To: <200708070048.20641.opensource@till.name> References: <200708022326.10721.opensource@till.name> <20070802173035.7bf75622@localhost.localdomain> <200708070048.20641.opensource@till.name> Message-ID: <20070806195559.7c391b0a@ender> On Tue, 07 Aug 2007 00:48:19 +0200 Till Maas wrote: > Do you do this manually? Yeah, call me old fashioned, I don't use any plugins or any special thing to manage my specs. Mostly because I haven't discovered them. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 7 00:54:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 20:54:45 -0400 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <20070806223155.GB4653@free.fr> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> Message-ID: <1186448085.3128.4.camel@localhost.localdomain> On Tue, 2007-08-07 at 00:31 +0200, Patrice Dumas wrote: > On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > > I know Rex Dieter likes the errata package idea. I wonder what others think? > > I think that such decisions should be left to the packagers, as long as > it is not obviously wrong. A bit like split choices. Hey, OOo dictionaries are big... let's make errata packages for them differently for updates. Maybe for the data for $game, too. ... I think that this is a pretty bad idea for us to follow down. Much like we package perl modules natively rather than telling people to use CPAN, we should be handling updates to packages natively rather than errata packages that stand along-side. If the argument is size and space, then help out with testing presto and getting the support into the buildsystem so that we can have it enabled by default and helping for *all* packages rather than just a select few that have built their own way of doing things Jeremy From pertusus at free.fr Tue Aug 7 01:01:29 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 7 Aug 2007 03:01:29 +0200 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <1186448085.3128.4.camel@localhost.localdomain> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> <1186448085.3128.4.camel@localhost.localdomain> Message-ID: <20070807010129.GC4653@free.fr> On Mon, Aug 06, 2007 at 08:54:45PM -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:31 +0200, Patrice Dumas wrote: > > On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > > > I know Rex Dieter likes the errata package idea. I wonder what others think? > > > > I think that such decisions should be left to the packagers, as long as > > it is not obviously wrong. A bit like split choices. > > Hey, OOo dictionaries are big... let's make errata packages for them > differently for updates. Maybe for the data for $game, too. If it makes sense for a specific package, yes. > ... > > I think that this is a pretty bad idea for us to follow down. Much like > we package perl modules natively rather than telling people to use CPAN, That's a different issue, still use rpm here. > we should be handling updates to packages natively rather than errata > packages that stand along-side. In genenal, yes, but leave it to packagers when they feel strongly about it. For texlive it may make sense. > If the argument is size and space, then > help out with testing presto and getting the support into the > buildsystem so that we can have it enabled by default and helping for > *all* packages rather than just a select few that have built their own > way of doing things I am not sure that using presto is the answer here. Doing a texlive errata package solves more than the space issue. Moreover at any point the errata may be integrated in the main rpm. I don't know texlive a lot, but, in the general case using a trick like an errata package may help updating only part of the package when upstream releases errata and keeps a monolithic package otherwise. -- Pat From mclasen at redhat.com Tue Aug 7 01:28:53 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 06 Aug 2007 21:28:53 -0400 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <1186448085.3128.4.camel@localhost.localdomain> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> <1186448085.3128.4.camel@localhost.localdomain> Message-ID: <1186450133.4373.5.camel@localhost.localdomain> On Mon, 2007-08-06 at 20:54 -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:31 +0200, Patrice Dumas wrote: > > On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > > > I know Rex Dieter likes the errata package idea. I wonder what others think? > > > > I think that such decisions should be left to the packagers, as long as > > it is not obviously wrong. A bit like split choices. > > Hey, OOo dictionaries are big... let's make errata packages for them > differently for updates. Maybe for the data for $game, too. > > ... > > I think that this is a pretty bad idea for us to follow down. Much like > we package perl modules natively rather than telling people to use CPAN, > we should be handling updates to packages natively rather than errata > packages that stand along-side. If the argument is size and space, then > help out with testing presto and getting the support into the > buildsystem so that we can have it enabled by default and helping for > *all* packages rather than just a select few that have built their own > way of doing thing Another alternative is to package the texmf tree more modular, which would not only help to reduce space consumption for updates, but also for the initial installation - not everybody who uses latex also has a burning need for context... From jnovy at redhat.com Tue Aug 7 07:51:12 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 7 Aug 2007 09:51:12 +0200 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <1186448085.3128.4.camel@localhost.localdomain> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> <1186448085.3128.4.camel@localhost.localdomain> Message-ID: <20070807075112.GC7363@dhcp-lab-186.brq.redhat.com> On Mon, Aug 06, 2007 at 08:54:45PM -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:31 +0200, Patrice Dumas wrote: > > On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > > > I know Rex Dieter likes the errata package idea. I wonder what others think? > > > > I think that such decisions should be left to the packagers, as long as > > it is not obviously wrong. A bit like split choices. > > Hey, OOo dictionaries are big... let's make errata packages for them > differently for updates. Maybe for the data for $game, too. > > ... > > I think that this is a pretty bad idea for us to follow down. Much like > we package perl modules natively rather than telling people to use CPAN, > we should be handling updates to packages natively rather than errata > packages that stand along-side. If the argument is size and space, then > help out with testing presto and getting the support into the > buildsystem so that we can have it enabled by default and helping for > *all* packages rather than just a select few that have built their own > way of doing things > You miss the point here. It's not about introducing a new packaging paradigm, that other packagers should adopt. It's solely for the texlive packaging purpose in the current state of texlive and the buildsystem. Presto is most likely useless here as many files in the noarch packages are configs/ghosted and are expected to be modified by the regular usage, so deltarpm wouldn't help here and it would download the full packages anyway in many cases. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Aug 7 08:02:36 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 7 Aug 2007 10:02:36 +0200 Subject: [Fedora-packaging] Texlive packaging and "Errata packages" In-Reply-To: <1186450133.4373.5.camel@localhost.localdomain> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> <1186448085.3128.4.camel@localhost.localdomain> <1186450133.4373.5.camel@localhost.localdomain> Message-ID: <20070807080236.GD7363@dhcp-lab-186.brq.redhat.com> On Mon, Aug 06, 2007 at 09:28:53PM -0400, Matthias Clasen wrote: > Another alternative is to package the texmf tree more modular, which > would not only help to reduce space consumption for updates, but also > for the initial installation - not everybody who uses latex also has > a burning need for context... +1 Further modularization seems to be the best way how to do this in the future. The current subpackage structure is designed for easy adoption by the packages dependent on tetex so that it's almost identical. The current strategy is to replace tetex with texlive in F8 in a way that a minimal overhead is needed from the other package maintainers, so that it can be done smoothly and quickly. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From Axel.Thimm at ATrpms.net Tue Aug 7 08:16:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Aug 2007 10:16:59 +0200 Subject: [Fedora-packaging] Re: Licensing guidelines suggestions In-Reply-To: <200708062305.50583.ville.skytta@iki.fi> References: <200708062305.50583.ville.skytta@iki.fi> Message-ID: <20070807081659.GA2285@puariko.nirvana> On Mon, Aug 06, 2007 at 11:05:50PM +0300, Ville Skytt? wrote: > 3) Source licenses are not the only thing that affect the distributables' > copyrights. For example when something is built from let's say LGPLv2+ > sources but linked with a GPLv2+ library, the resulting binary will be > GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright > notices are changed to GPLv2+, but that can't be done for many *GPL > licenses). > > > Suggested combined fix for 2) and 3) above: change the licensing guidelines to > prominently note something like that the value of the License tag represents > the copyright/license info of binary packages only, and only when built in > the configuration specified by the Fedora build system, build > dependencies/conflicts in the specfile, and no non-Fedora software installed > that will affect the build in any way. Source rpms' copyrights are > determined by the sources and other content included in them. Sometimes a src.rpm/specfile does not know what it will be built against, it doesn't even quite know whether it will be built against the glibc and whether that glibc is undert GPL2, 3, 1001 and so forth. Since we massage specfiles and not the environment we can't know what this package will binary-wise end up like. It might be that gnutls acts as a drop in replacement to openssl or libedit to readline (actually the latter almost does) atlas to lapack (but the licenses don't differ). Point is the build environment defines the final license and the same specfile/src.rpm could end up with different licenses for the binaries depending on which distribution and which age of it we're looking at. For example consider gnuplot BR'ing a readline librariy's headers w/o specifying GNU readline. If you use GNU readline the binary's license is "undistributable" (actually that's the kind of gnuplot we currently do ship ...), if you use libedit it's "distributable". So the License: tag needs to be closer to the sources than the binaries. We can't have both unles we would introduce something like a BinaryLicense: tag. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 7 08:22:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Aug 2007 10:22:36 +0200 Subject: [Fedora-packaging] Re: Texlive packaging and "Errata packages" In-Reply-To: <1186448085.3128.4.camel@localhost.localdomain> References: <645d17210708061528l7d457ffcu7e0642d1b118e8b2@mail.gmail.com> <20070806223155.GB4653@free.fr> <1186448085.3128.4.camel@localhost.localdomain> Message-ID: <20070807082236.GB2285@puariko.nirvana> On Mon, Aug 06, 2007 at 08:54:45PM -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:31 +0200, Patrice Dumas wrote: > > On Mon, Aug 06, 2007 at 11:28:38PM +0100, Jonathan Underwood wrote: > > > I know Rex Dieter likes the errata package idea. I wonder what others think? > > > > I think that such decisions should be left to the packagers, as long as > > it is not obviously wrong. A bit like split choices. > > Hey, OOo dictionaries are big... let's make errata packages for them > differently for updates. Oh yes, please, I have the feeling that all I'm updating lately are these dictionaries ;) I think for texmf the errata method is OK, after all it's one of the largest packages (maybe the largest after openoffice?), and it would allow the maintainer to be able to follow closer the texlive updates instead of holding back updates because updates punish more than they help. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Wed Aug 8 09:33:59 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 08 Aug 2007 10:33:59 +0100 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <200708070016.36100.ville.skytta@iki.fi> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> Message-ID: <46B98E07.9050107@city-fan.org> Ville Skytt? wrote: > On Monday 06 August 2007, Tom "spot" Callaway wrote: >> On Mon, 2007-08-06 at 23:05 +0300, Ville Skytt? wrote: >>> Hello, >>> >>> Here's a few notes/questions that IMO need to be addressed in the new >>> licensing guidelines in Wiki. IANAL, etc, but anyway, something for near >>> future FPC meetings (which I still probably won't be able to attend to >>> for a couple of weeks): >>> >>> 1) The licensing pages strongly imply that OSI-approved licenses are ok. >>> However for example the original Artistic license is OSI-approved but >>> listed in Wiki page as "bad". Something needs real fixing - "ask >>> upstream to move to a "good" Artistic license" is IMO just a band aid. >>> http://fedoraproject.org/wiki/Licensing >>> http://www.opensource.org/licenses/artistic-license.php >> I think we're going to need the Fedora Board to decide this. Its a >> little outside of our jurisdiction, unfortunately. > > Ok, I'll forward the question to fab-list, hopefully they'll pick this up. I'll be waiting for a resolution of this before updating most of my perl module packages - depending on the result, the "same as perl" licensed modules may be "GPL+" or "GPL+ or Artistic". I favour the latter personally as that's what the upstream authors intended. On a related issue, the short name "GPL+" is described as: A GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include. I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)? Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version? Paul. From tcallawa at redhat.com Wed Aug 8 13:48:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 08 Aug 2007 09:48:23 -0400 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <46B98E07.9050107@city-fan.org> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> Message-ID: <1186580903.3368.159.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote: > I presume, though it's not explicitly stated, that GPL+ can also be used > where the license is explicitly given as "GPL version 1 or later" (e.g. > for perl and all same-as-perl licensed modules)? Yes, this correct. > Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 > (not 2.1) or later" as well as for LGPL of unspecified version? Not quite: LGPL+ is only for unversioned LGPL (I've never seen this, but it's possible). LGPLv2+ is for LGPL 2/2.1 or later. ~spot From mclasen at redhat.com Wed Aug 8 13:51:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 08 Aug 2007 09:51:34 -0400 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <1186580903.3368.159.camel@dhcp67.install.boston.redhat.com> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> <1186580903.3368.159.camel@dhcp67.install.boston.redhat.com> Message-ID: <1186581094.3352.8.camel@localhost.localdomain> On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote: > On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote: > > > I presume, though it's not explicitly stated, that GPL+ can also be used > > where the license is explicitly given as "GPL version 1 or later" (e.g. > > for perl and all same-as-perl licensed modules)? > > Yes, this correct. > > > Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 > > (not 2.1) or later" as well as for LGPL of unspecified version? > > Not quite: > > LGPL+ is only for unversioned LGPL (I've never seen this, but it's > possible). > LGPLv2+ is for LGPL 2/2.1 or later. > Can you explain the difference, considering there is no version 1 of the LGPL ? From paul at city-fan.org Wed Aug 8 14:03:52 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 08 Aug 2007 15:03:52 +0100 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <1186581094.3352.8.camel@localhost.localdomain> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> <1186580903.3368.159.camel@dhcp67.install.boston.redhat.com> <1186581094.3352.8.camel@localhost.localdomain> Message-ID: <46B9CD48.30508@city-fan.org> Matthias Clasen wrote: > On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote: >> On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote: >> >>> I presume, though it's not explicitly stated, that GPL+ can also be used >>> where the license is explicitly given as "GPL version 1 or later" (e.g. >>> for perl and all same-as-perl licensed modules)? >> Yes, this correct. >> >>> Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 >>> (not 2.1) or later" as well as for LGPL of unspecified version? >> Not quite: >> >> LGPL+ is only for unversioned LGPL (I've never seen this, but it's >> possible). >> LGPLv2+ is for LGPL 2/2.1 or later. >> > > Can you explain the difference, considering there is no version 1 of the > LGPL ? Also considering that the "Full name" column of the licensing page on the wiki specifically refers to v2.1 onwards (and not v2 onwards) for the LGPL2 and LGPL2+ short names. Paul. From tcallawa at redhat.com Wed Aug 8 14:01:12 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 08 Aug 2007 10:01:12 -0400 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <1186581094.3352.8.camel@localhost.localdomain> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> <1186580903.3368.159.camel@dhcp67.install.boston.redhat.com> <1186581094.3352.8.camel@localhost.localdomain> Message-ID: <1186581672.3368.173.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-08-08 at 09:51 -0400, Matthias Clasen wrote: > On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote: > > On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote: > > > > > I presume, though it's not explicitly stated, that GPL+ can also be used > > > where the license is explicitly given as "GPL version 1 or later" (e.g. > > > for perl and all same-as-perl licensed modules)? > > > > Yes, this correct. > > > > > Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 > > > (not 2.1) or later" as well as for LGPL of unspecified version? > > > > Not quite: > > > > LGPL+ is only for unversioned LGPL (I've never seen this, but it's > > possible). > > LGPLv2+ is for LGPL 2/2.1 or later. > > > > Can you explain the difference, considering there is no version 1 of the > LGPL ? Eh, I suppose there is no difference. I'll nuke LGPL+ off the list. ~spot From jnovy at redhat.com Thu Aug 9 09:01:00 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 9 Aug 2007 11:01:00 +0200 Subject: [Fedora-packaging] New db4 update and package changes Message-ID: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> Hi folks, you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon. I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484). If you have any proposals/objections related to the update, please speak up. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From Axel.Thimm at ATrpms.net Thu Aug 9 12:27:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 14:27:49 +0200 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> Message-ID: <20070809122749.GA10454@puariko.nirvana> Hi, On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > you may have noticed Oracle released db-4.6.18 recently. The update is > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > db4 is ready to hit rawhide soon. > > I want to announce a change I made in the new db4, that may affect > you from the packaging POV if your package is dependent on db4. It is > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > to reduce dependency bloat (#220484). > > If you have any proposals/objections related to the update, please speak up. I can understand the splitting of the runtime bits, but why split the *-devel package? If we start splitting devel we would need guidelines as to how far to split: foo-cxx-devel, foo-f90-devel, foo-python-devel? Or foo-gtk-devel, foo-qt-devel, foo-cxx-qt-3-but-not-4-devel etc. foo-devel is currently sacred, even library packages w/o such a subpackage have to provide it so, the packagers of build-dependent packages can simply trust that BR: foo-devel will ensure the bits are there. Now they would have to check whether foo has foo-cxx-devel, too, and whether that goes unnoticed by their bar detection scripts (e.g. bar just simlently builds C bindings etc). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Aug 9 12:58:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 09 Aug 2007 08:58:43 -0400 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <20070809122749.GA10454@puariko.nirvana> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> Message-ID: <1186664323.5583.28.camel@localhost.localdomain> On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > Hi, > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > you may have noticed Oracle released db-4.6.18 recently. The update is > > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > > db4 is ready to hit rawhide soon. > > > > I want to announce a change I made in the new db4, that may affect > > you from the packaging POV if your package is dependent on db4. It is > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > to reduce dependency bloat (#220484). > > > > If you have any proposals/objections related to the update, please speak up. > > I can understand the splitting of the runtime bits, but why split the > *-devel package? +1. Splitting the -devel package is a rather significant alteration, for little benefit (and shouldn't increase dependency bloat). ~spot From pertusus at free.fr Sat Aug 11 08:11:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 11 Aug 2007 10:11:38 +0200 Subject: [Fedora-packaging] missing file in example in sourceUrl Message-ID: <20070811081138.GB2674@free.fr> Hello, Unless I am wrong, in https://fedoraproject.org/wiki/Packaging/SourceURL in the generate-tarball.sh code, there is a missing second arg for the second tar invocation, should certainly be tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION I cannot edit. -- Pat From tibbs at math.uh.edu Sat Aug 11 15:19:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Aug 2007 10:19:58 -0500 Subject: [Fedora-packaging] missing file in example in sourceUrl In-Reply-To: <20070811081138.GB2674@free.fr> References: <20070811081138.GB2674@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> there is a missing second arg for the second tar invocation, Fixed. - J< From nicolas.mailhot at laposte.net Sun Aug 12 17:11:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Aug 2007 19:11:41 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <20070727001600.GE9468@puariko.nirvana> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> <1185492843.19639.75.camel@localhost.localdomain> <20070727001600.GE9468@puariko.nirvana> Message-ID: <1186938701.5251.58.camel@rousalka.dyndns.org> Le vendredi 27 juillet 2007 ? 02:16 +0200, Axel Thimm a ?crit : > On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote: > > (And I nominate "+=" as the most logical and ugliest operator for the > > job :-) > > > A comparison operator (>=) would make more sense ? please -- 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 tcallawa at redhat.com Sun Aug 12 17:12:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 12 Aug 2007 13:12:50 -0400 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1186938701.5251.58.camel@rousalka.dyndns.org> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> <1185492843.19639.75.camel@localhost.localdomain> <20070727001600.GE9468@puariko.nirvana> <1186938701.5251.58.camel@rousalka.dyndns.org> Message-ID: <1186938771.4243.32.camel@new-host-2> On Sun, 2007-08-12 at 19:11 +0200, Nicolas Mailhot wrote: > Le vendredi 27 juillet 2007 ? 02:16 +0200, Axel Thimm a ?crit : > > On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote: > > > > (And I nominate "+=" as the most logical and ugliest operator for the > > > job :-) > > > > > > A comparison operator (>=) would make more sense > > ? please Given that we ended up dropping computer-logical operators for human-logical ones, this is not only semantics, but irrelevant semantics. :) ~spot From opensource at till.name Sun Aug 12 19:18:28 2007 From: opensource at till.name (Till Maas) Date: Sun, 12 Aug 2007 21:18:28 +0200 Subject: [Fedora-packaging] Packaging/Guidelines -> Tags: missing link to the new License Tag Guidelines Message-ID: <200708122118.35501.opensource@till.name> Hi, on http://fedoraproject.org/wiki/Packaging/Guidelines#head-c17fb8c1ce9be40da720a2b25d1e2a241062038f there is written: | The Copyright tag is deprecated. Use the License tag instead. Use standard | abbreviations and names, e.g. GPL, LGPL, BSD, Artistic. Contact the upstream | author if there is any doubt about what license the software is distributed | under. There should be a link to the License Tag Guidelines imho: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Sun Aug 12 19:25:14 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 12 Aug 2007 15:25:14 -0400 Subject: [Fedora-packaging] Packaging/Guidelines -> Tags: missing link to the new License Tag Guidelines In-Reply-To: <200708122118.35501.opensource@till.name> References: <200708122118.35501.opensource@till.name> Message-ID: <1186946714.4243.53.camel@new-host-2> On Sun, 2007-08-12 at 21:18 +0200, Till Maas wrote: > Hi, > > on > http://fedoraproject.org/wiki/Packaging/Guidelines#head-c17fb8c1ce9be40da720a2b25d1e2a241062038f > there is written: > > | The Copyright tag is deprecated. Use the License tag instead. Use standard > | abbreviations and names, e.g. GPL, LGPL, BSD, Artistic. Contact the upstream > | author if there is any doubt about what license the software is distributed > | under. > > There should be a link to the License Tag Guidelines imho: > http://fedoraproject.org/wiki/Packaging/LicensingGuidelines Good catch. I see that it has already been fixed. ~spot From tibbs at math.uh.edu Sun Aug 12 19:33:31 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Aug 2007 14:33:31 -0500 Subject: [Fedora-packaging] Packaging/Guidelines -> Tags: missing link to the new License Tag Guidelines In-Reply-To: <200708122118.35501.opensource@till.name> References: <200708122118.35501.opensource@till.name> Message-ID: I've changed the document to refer to the Packaging/LicensingGuidelines page. - J< From paul at city-fan.org Mon Aug 13 12:30:06 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Aug 2007 13:30:06 +0100 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <46B98E07.9050107@city-fan.org> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> Message-ID: <46C04ECE.7040209@city-fan.org> Paul Howarth wrote: > Ville Skytt? wrote: >> On Monday 06 August 2007, Tom "spot" Callaway wrote: >>> On Mon, 2007-08-06 at 23:05 +0300, Ville Skytt? wrote: >>>> Hello, >>>> >>>> Here's a few notes/questions that IMO need to be addressed in the new >>>> licensing guidelines in Wiki. IANAL, etc, but anyway, something for >>>> near >>>> future FPC meetings (which I still probably won't be able to attend to >>>> for a couple of weeks): >>>> >>>> 1) The licensing pages strongly imply that OSI-approved licenses are >>>> ok. >>>> However for example the original Artistic license is OSI-approved but >>>> listed in Wiki page as "bad". Something needs real fixing - "ask >>>> upstream to move to a "good" Artistic license" is IMO just a band aid. >>>> http://fedoraproject.org/wiki/Licensing >>>> http://www.opensource.org/licenses/artistic-license.php >>> I think we're going to need the Fedora Board to decide this. Its a >>> little outside of our jurisdiction, unfortunately. >> >> Ok, I'll forward the question to fab-list, hopefully they'll pick this >> up. > > I'll be waiting for a resolution of this before updating most of my perl > module packages - depending on the result, the "same as perl" licensed > modules may be "GPL+" or "GPL+ or Artistic". I favour the latter > personally as that's what the upstream authors intended. I've been working my way through my packages, updating the license fields as appropriate. I just came across perl-Tie-EncryptedHash, which is under the Artistic license (only). If this is not an acceptable license, the package will have to go, and so will perl-Crypt-RSA (which depends on it) and anything else that depends on that. Paul. From tcallawa at redhat.com Mon Aug 13 13:54:58 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 13 Aug 2007 09:54:58 -0400 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <46C04ECE.7040209@city-fan.org> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> <46C04ECE.7040209@city-fan.org> Message-ID: <1187013298.3325.7.camel@dhcp83-165.boston.redhat.com> On Mon, 2007-08-13 at 13:30 +0100, Paul Howarth wrote: > I've been working my way through my packages, updating the license > fields as appropriate. I just came across perl-Tie-EncryptedHash, which > is under the Artistic license (only). If this is not an acceptable > license, the package will have to go, and so will perl-Crypt-RSA (which > depends on it) and anything else that depends on that. Would you ask upstream if they'd be willing to relicense either under the same terms as perl or Artistic 2.0? Thanks, ~spot From paul at city-fan.org Mon Aug 13 14:32:38 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Aug 2007 15:32:38 +0100 Subject: [Fedora-packaging] Licensing guidelines suggestions In-Reply-To: <1187013298.3325.7.camel@dhcp83-165.boston.redhat.com> References: <200708062305.50583.ville.skytta@iki.fi> <1186433287.3839.47.camel@dhcp67.install.boston.redhat.com> <200708070016.36100.ville.skytta@iki.fi> <46B98E07.9050107@city-fan.org> <46C04ECE.7040209@city-fan.org> <1187013298.3325.7.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C06B86.5040007@city-fan.org> Tom "spot" Callaway wrote: > On Mon, 2007-08-13 at 13:30 +0100, Paul Howarth wrote: > >> I've been working my way through my packages, updating the license >> fields as appropriate. I just came across perl-Tie-EncryptedHash, which >> is under the Artistic license (only). If this is not an acceptable >> license, the package will have to go, and so will perl-Crypt-RSA (which >> depends on it) and anything else that depends on that. > > Would you ask upstream if they'd be willing to relicense either under > the same terms as perl or Artistic 2.0? Done. http://rt.cpan.org/Public/Bug/Display.html?id=28813 Paul. From rc040203 at freenet.de Tue Aug 14 15:57:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Aug 2007 17:57:34 +0200 Subject: [Fedora-packaging] Missing today's meeting Message-ID: <1187107054.14035.181.camel@mccallum.corsepiu.local> Hi, due to sudden unplanned commitments, I'll not be able to attend today's FPC meeting. Ralf From a.badger at gmail.com Tue Aug 14 16:49:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 14 Aug 2007 09:49:50 -0700 Subject: [Fedora-packaging] Missing the meeting today Message-ID: Sorry for the last minuteness of this, My sister's stuck at the airport so I'll be missing the meeting. -Toshio From jonathan.underwood at gmail.com Wed Aug 15 15:55:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 15 Aug 2007 16:55:28 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1184936519.4026.80.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> Message-ID: <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> Hi, Chip has now fixed the Emacs packages in a way that is consistent with Xemacs packaging (thanks chip!) and so I have finished the draft (X)Emacs add-on packging guideline draft here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns Comment/edits very welcome. Hopefully this can go to the committee before too long. Jonathan. From jonathan.underwood at gmail.com Wed Aug 15 16:02:57 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 15 Aug 2007 17:02:57 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> Message-ID: <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> On 15/08/07, Jonathan Underwood wrote: > Hi, > > Chip has now fixed the Emacs packages in a way that is consistent with > Xemacs packaging (thanks chip!) and so I have finished the draft > (X)Emacs add-on packging guideline draft here: > > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > Comment/edits very welcome. Hopefully this can go to the committee > before too long. I just went to update this page accordingly: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo but find that it is immutable. Perhaps someone could update it for me - the status column reading "Waiting on Bugzillas" for the EmacsAddOns page should now read "ASAP" or similar. J. From rdieter at math.unl.edu Wed Aug 15 16:10:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 15 Aug 2007 11:10:14 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> Message-ID: <46C32566.3060802@math.unl.edu> Jonathan Underwood wrote: > I just went to update this page accordingly: > > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > > but find that it is immutable. Perhaps someone could update it for me > - the status column reading "Waiting on Bugzillas" for the EmacsAddOns > page should now read "ASAP" or similar. ASAP it is, fixed. -- Rex From jonathan.underwood at gmail.com Wed Aug 15 16:12:52 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 15 Aug 2007 17:12:52 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <46C32566.3060802@math.unl.edu> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> <46C32566.3060802@math.unl.edu> Message-ID: <645d17210708150912t74fe7e34w5885ac4a2101be0f@mail.gmail.com> On 15/08/07, Rex Dieter wrote: > Jonathan Underwood wrote: > > > I just went to update this page accordingly: > > > > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > > > > but find that it is immutable. Perhaps someone could update it for me > > - the status column reading "Waiting on Bugzillas" for the EmacsAddOns > > page should now read "ASAP" or similar. > > ASAP it is, fixed. Thanks. From tcallawa at redhat.com Wed Aug 15 16:11:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Aug 2007 12:11:34 -0400 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> Message-ID: <1187194294.3439.33.camel@dhcp83-165.boston.redhat.com> On Wed, 2007-08-15 at 17:02 +0100, Jonathan Underwood wrote: > On 15/08/07, Jonathan Underwood wrote: > > Hi, > > > > Chip has now fixed the Emacs packages in a way that is consistent with > > Xemacs packaging (thanks chip!) and so I have finished the draft > > (X)Emacs add-on packging guideline draft here: > > > > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > > > Comment/edits very welcome. Hopefully this can go to the committee > > before too long. > > I just went to update this page accordingly: > > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > > but find that it is immutable. Perhaps someone could update it for me > - the status column reading "Waiting on Bugzillas" for the EmacsAddOns > page should now read "ASAP" or similar. FYI: That table gets sucked in from: PackagingDrafts/DraftsTodo, which anyone can edit. ~spot From jonathan.underwood at gmail.com Wed Aug 15 16:19:43 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 15 Aug 2007 17:19:43 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1187194294.3439.33.camel@dhcp83-165.boston.redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> <1184936519.4026.80.camel@localhost.localdomain> <645d17210708150855o359390ddra6f3cd2cd8c23145@mail.gmail.com> <645d17210708150902l6f42ffedp77b457cc3fbda5e@mail.gmail.com> <1187194294.3439.33.camel@dhcp83-165.boston.redhat.com> Message-ID: <645d17210708150919s72bb5fd6y2ec5b3ea39dc7000@mail.gmail.com> On 15/08/07, Tom spot Callaway wrote: > FYI: That table gets sucked in from: PackagingDrafts/DraftsTodo, which > anyone can edit. Aha, thanks. From mclasen at redhat.com Fri Aug 17 17:16:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 13:16:57 -0400 Subject: [Fedora-packaging] review guidelines vs packaging guidelines Message-ID: <1187371017.1161.7.camel@localhost.localdomain> The review guidelines have this: - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. The packaging guidelines say: The rule of thumb is that your package should own all of the directories it creates except those owned by packages which your package depends on. However, there are exceptions to this. If the directory hierarchy your package is located in may change due to updates of packages you depend on, then you need to take care to own those pieces of the hierarchy. [...] Another exception for directory ownership in packages is when there is no clear dependency hierarchy. I think the shortened version in the review guidelines is misleading and causes us to err on the side of adding unwanted dependencies just for directory ownership reasons. Can we have it changed to mention the furhter exceptions that are discussed in the packaging guidelines ? From petersen at redhat.com Mon Aug 20 02:32:17 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 20 Aug 2007 12:32:17 +1000 Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> References: <46A7F596.7020101@redhat.com> <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> Message-ID: <46C8FD31.5060702@redhat.com> Nicolas Mailhot ????????: > Le Jeu 26 juillet 2007 15:57, Rex Dieter a ?crit : >> Jens Petersen wrote: > >>> I'll [wait] for responses before changing it to: >>> %{_bindir}/fc-cache %{_datadir}/fonts >> do it. Maybe even go one step further, and either say change to >> %{_bindir}/fc-cache Yes, actually it seems this is probably better and the right thing to do. > However, I'm not sure if pointing fc-cache just at this dir is worth > it. Asking it to refresh everything is safer. It seems better since clock skew created say during firstboot can cause "fc-cache %{_datadir}/fonts" not to update newly installed fonts if the timestamp of %{_datadir}/fonts is ahead of the just installed fonts directory. This can actually easily be reproduced. So I would like to second changing the %post scriptlet to pointing to the actual font directory. I am not sure yet if %postun should be changed too? The alternative would be always to use "fc-cache -f" but that is rather a heavy operation. Jens -- Jens Petersen Internationalization Team Red Hat From petersen at redhat.com Mon Aug 20 07:44:46 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 20 Aug 2007 17:44:46 +1000 Subject: [Fedora-packaging] Re: fc-cache In-Reply-To: <46C8FD31.5060702@redhat.com> References: <46A7F596.7020101@redhat.com> <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> <46C8FD31.5060702@redhat.com> Message-ID: <46C9466E.8070407@redhat.com> Jens Petersen wrote: >> Le Jeu 26 juillet 2007 15:57, Rex Dieter a ?crit : >>> Maybe even go one step further, and either say change to >>> %{_bindir}/fc-cache > > Yes, actually it seems this is probably better and the right thing to do. Errm sorry, it seems more testing is needed actually, since this also seems to have some problems, or the behaviour of fc-cache is a little unexpected? > clock skew created say during firstboot can cause > "fc-cache %{_datadir}/fonts" not to update newly installed fonts if the > timestamp of %{_datadir}/fonts is ahead of the just installed fonts > directory. This can actually easily be reproduced. This is definitely still a real problem though that needs to be fixed: either in the font install scriptlets or fontconfig. Jens From skasal at redhat.com Tue Aug 21 09:19:01 2007 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 21 Aug 2007 11:19:01 +0200 Subject: [Fedora-packaging] Are circular dependencies ok? Message-ID: <20070821091901.GA21257@camelia.ucw.cz.> Hello, in perl, circular dependencies are heavily used. First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem, rpm{,-libs} and python{,-libs} are doing the same. Let's put this aside. Second, package "perl-devel" requires packages: perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple all these packages require perl-devel, most of them by a direct requirement, only perl-CPAN by requiring perl-ExtUtils-Embed. I believe this is correct: - the modules have to have separate rpm, to match the real situation: they use a separate versioning scheme, for example. - perl-devel has to require them; these modules are required by scripts packed in perl-devel But this seems to bring problems, see the comments in https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7 Is this just a bug in yum, or is there a problem on my side? Thanks, Stepan Kasal From ville.skytta at iki.fi Tue Aug 21 10:14:37 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 21 Aug 2007 13:14:37 +0300 Subject: [Fedora-packaging] Are circular dependencies ok? In-Reply-To: <20070821091901.GA21257@camelia.ucw.cz.> References: <20070821091901.GA21257@camelia.ucw.cz.> Message-ID: <200708211314.43738.ville.skytta@iki.fi> On Tuesday 21 August 2007, Stepan Kasal wrote: > Hello, > in perl, circular dependencies are heavily used. [...] > But this seems to bring problems, see the comments in > https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7 > > Is this just a bug in yum, or is there a problem on my side? I would argue it is a bug in yum indeed - it says "foo is not available" for various foos that clearly actually _are_ available. But IIRC similar cases (monolithic package split to several subpackages) have been successfully worked around in the past by adding "Obsoletes: $monolithic_package < $first_nonmonolithic_package_evr" to all those new subpackages. Based on the perl package changelog, I suppose for this case it could be something like "Obsoletes: perl-devel < 4:5.8.8-20" for subpackages that perl-devel used to pull in but no longer does. Having said that, in case you're planning to push the all-the-way split perl package to F-7 as an update: FWIW in my opinion it is a pretty intrusive one to be pushed at this point. I think not even all packages in Rawhide have been verified to build and work properly with the split done all the way and transition-time dependencies dropped. From skasal at redhat.com Tue Aug 21 10:35:16 2007 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 21 Aug 2007 12:35:16 +0200 Subject: [Fedora-packaging] Are circular dependencies ok? In-Reply-To: <200708211314.43738.ville.skytta@iki.fi> References: <20070821091901.GA21257@camelia.ucw.cz.> <200708211314.43738.ville.skytta@iki.fi> Message-ID: <20070821103514.GA22656@camelia.ucw.cz.> Hello, On Tue, Aug 21, 2007 at 01:14:37PM +0300, Ville Skytt? wrote: > Having said that, in case you're planning to push the all-the-way split perl > package to F-7 as an update: FWIW in my opinion it is a pretty intrusive one > to be pushed at this point. The "all-the-way split perl package" was part of the original Fedora 7 release. The updates for F-7 contain only small changes. I guess that the yum bug might have been triggered by perl rpms even if they were identical to the previous release. Let's see if -23.fc7 gets any complaints. In any case, I'm going to push the package to updates after a week in testing or so, unless a bug is discovered in it. Have a nice day, Stepan Kasal From ville.skytta at iki.fi Tue Aug 21 11:22:52 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 21 Aug 2007 14:22:52 +0300 Subject: [Fedora-packaging] Are circular dependencies ok? In-Reply-To: <20070821103514.GA22656@camelia.ucw.cz.> References: <20070821091901.GA21257@camelia.ucw.cz.> <200708211314.43738.ville.skytta@iki.fi> <20070821103514.GA22656@camelia.ucw.cz.> Message-ID: <200708211422.53394.ville.skytta@iki.fi> On Tuesday 21 August 2007, Stepan Kasal wrote: > Hello, > > On Tue, Aug 21, 2007 at 01:14:37PM +0300, Ville Skytt? wrote: > > Having said that, in case you're planning to push the all-the-way split > > perl package to F-7 as an update: FWIW in my opinion it is a pretty > > intrusive one to be pushed at this point. > > The "all-the-way split perl package" was part of the original Fedora 7 > release. That's not what I mean by "all-the-way split". perl-devel in F7 has these artificial/transitional dependencies which have been removed in Rawhide (which is what I mean by all-the-way): Requires: perl(CPAN), perl(ExtUtils::Embed), perl(ExtUtils::MakeMaker) Requires: perl(Test::Harness), perl(Test::Simple) But I see that -23 in F-7 still has these, so looks like the update isn't what I thought it'd be and so my FWIW opinion above can be ignored. From skasal at redhat.com Tue Aug 21 11:41:58 2007 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 21 Aug 2007 13:41:58 +0200 Subject: [Fedora-packaging] Are circular dependencies ok? In-Reply-To: <200708211422.53394.ville.skytta@iki.fi> References: <20070821091901.GA21257@camelia.ucw.cz.> <200708211314.43738.ville.skytta@iki.fi> <20070821103514.GA22656@camelia.ucw.cz.> <200708211422.53394.ville.skytta@iki.fi> Message-ID: <20070821114158.GA23029@camelia.ucw.cz.> Hi, On Tue, Aug 21, 2007 at 02:22:52PM +0300, Ville Skytt? wrote: > That's not what I mean by "all-the-way split". perl-devel in F7 has these > artificial/transitional dependencies which have been removed in Rawhide > (which is what I mean by all-the-way): > > Requires: perl(CPAN), perl(ExtUtils::Embed), perl(ExtUtils::MakeMaker) > Requires: perl(Test::Harness), perl(Test::Simple) oh, thanks for the clarification. And thanks for the hint, too. I was thinking about those requires today. But after your warning, I'll remember not to remove them. BTW: perl(ExtUtils::Embed) and perl(ExtUtils::MakeMaker) are generated anyway, because of the scripts in perl-devel, so the artificial part is: Requires: perl(CPAN), perl(Test::Harness), perl(Test::Simple) Stepan From rdieter at math.unl.edu Tue Aug 21 19:13:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Aug 2007 14:13:55 -0500 Subject: [Fedora-packaging] Re: Are circular dependencies ok? In-Reply-To: <20070821091901.GA21257@camelia.ucw.cz.> References: <20070821091901.GA21257@camelia.ucw.cz.> Message-ID: <46CB3973.4070109@math.unl.edu> Stepan Kasal wrote: > in perl, circular dependencies are heavily used. > > First, "perl" and "perl-libs" require each other; this is a usual > solution of the multilib problem I've never understand why one would ever split packages, but them depend on each other. What's the point? What advantage does that have over simply having the contents of both (sub)packages in a single package? -- Rex From skasal at redhat.com Tue Aug 21 19:29:15 2007 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 21 Aug 2007 21:29:15 +0200 Subject: [Fedora-packaging] Re: Are circular dependencies ok? In-Reply-To: <46CB3973.4070109@math.unl.edu> References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> Message-ID: <20070821192915.GA5246@camelia.ucw.cz.> Hello, On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote: > Stepan Kasal wrote: > > First, "perl" and "perl-libs" require each other; this is a usual > > solution of the multilib problem > > I've never understand why one would ever split packages, but them depend > on each other. What's the point? What advantage does that have over > simply having the contents of both (sub)packages in a single package? > with foo and foo-libs, foo-libs can be declared multilib. So it is possible that on x86_64 both foo-libs.i386 and foo-libs.x86_64 are installed. If both formed one package "foo" and the usage of the libraries in both 32bit and 64bit variant were required, then the package foo would have to be declared as multilib. The files which are outside {/usr,}/lib{,64} may cause a collision. For ELF files, rpm selects one of the two, but all other collisions have to be resolved: every generated file has to be snitized, so that it is identical for both architectures. That might be very tedious, and thus the split. Hope this explains it, Stepan Kasal From rdieter at math.unl.edu Tue Aug 21 19:33:53 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Aug 2007 14:33:53 -0500 Subject: [Fedora-packaging] Re: Are circular dependencies ok? In-Reply-To: <20070821192915.GA5246@camelia.ucw.cz.> References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> Message-ID: <46CB3E21.2040902@math.unl.edu> Stepan Kasal wrote: > Hello, > > On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote: > >> Stepan Kasal wrote: >> >>> First, "perl" and "perl-libs" require each other; this is a usual >>> solution of the multilib problem >>> >> >> I've never understand why one would ever split packages, but them depend >> on each other. What's the point? What advantage does that have over >> simply having the contents of both (sub)packages in a single package? >> >> > > with foo and foo-libs, foo-libs can be declared multilib. > So it is possible that on x86_64 both foo-libs.i386 and > foo-libs.x86_64 are installed. > > If both formed one package "foo" and the usage of the libraries in > both 32bit and 64bit variant were required, then the package foo > would have to be declared as multilib. > Um, but if -libs Requires: foo , wouldn't that pull foo into the multilib mix too, no? Am I missing something? -- Rex -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Tue Aug 21 20:05:56 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 21 Aug 2007 21:05:56 +0100 Subject: [Fedora-packaging] Re: Are circular dependencies ok? In-Reply-To: <46CB3E21.2040902@math.unl.edu> References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> <46CB3E21.2040902@math.unl.edu> Message-ID: <20070821210556.3f3da4e5@metropolis.intra.city-fan.org> On Tue, 21 Aug 2007 14:33:53 -0500 Rex Dieter wrote: > Stepan Kasal wrote: > > Hello, > > > > On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote: > > > >> Stepan Kasal wrote: > >> > >>> First, "perl" and "perl-libs" require each other; this is a usual > >>> solution of the multilib problem > >>> > >> > >> I've never understand why one would ever split packages, but them > >> depend on each other. What's the point? What advantage does that > >> have over simply having the contents of both (sub)packages in a > >> single package? > >> > > > > with foo and foo-libs, foo-libs can be declared multilib. > > So it is possible that on x86_64 both foo-libs.i386 and > > foo-libs.x86_64 are installed. > > > > If both formed one package "foo" and the usage of the libraries in > > both 32bit and 64bit variant were required, then the package foo > > would have to be declared as multilib. > > > Um, but if -libs Requires: foo , wouldn't that pull foo into the > multilib mix too, no? Am I missing something? foo-libs.i386 and foo-libs.x86_64 can both depend on foo.x86_64, can't they? Paul. From jkeating at redhat.com Tue Aug 21 20:27:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Aug 2007 16:27:44 -0400 Subject: [Fedora-packaging] Re: Are circular dependencies ok? In-Reply-To: <46CB3E21.2040902@math.unl.edu> References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> <46CB3E21.2040902@math.unl.edu> Message-ID: <20070821162744.7f96123c@mentok.boston.redhat.com> On Tue, 21 Aug 2007 14:33:53 -0500 Rex Dieter wrote: > Um, but if -libs Requires: foo , wouldn't that pull foo into the > multilib mix too, no? Am I missing something? No, as "foo" is arch independent. The idea here is that foo-devel has a .so symlink that points to an arch specific library. If that library is in a -libs package then only the -libs package from the secondary arch is brought in, and the Requires foo is satisfied by the single arch foo. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Aug 22 03:43:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Aug 2007 22:43:55 -0500 Subject: [Fedora-packaging] Re: Re: Are circular dependencies ok? References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> <46CB3E21.2040902@math.unl.edu> <20070821162744.7f96123c@mentok.boston.redhat.com> Message-ID: Jesse Keating wrote: > On Tue, 21 Aug 2007 14:33:53 -0500 > Rex Dieter wrote: > >> Um, but if -libs Requires: foo , wouldn't that pull foo into the >> multilib mix too, no? Am I missing something? > > No, as "foo" is arch independent. The idea here is that foo-devel has > a .so symlink that points to an arch specific library. So a -devel's Requires: %{name} ... is treated differently (is arch specific) than a -libs's Requires: %{name} ... (which isn't?) or is there some implicit requires in -devel's lib*.so symlink (which doesn't show in 'rpm --requires' or 'rpm --provides')? -- Rex From jkeating at redhat.com Wed Aug 22 11:36:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 07:36:47 -0400 Subject: [Fedora-packaging] Re: Re: Are circular dependencies ok? In-Reply-To: References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> <46CB3E21.2040902@math.unl.edu> <20070821162744.7f96123c@mentok.boston.redhat.com> Message-ID: <20070822073647.23601bc4@ender> On Tue, 21 Aug 2007 22:43:55 -0500 Rex Dieter wrote: > So a -devel's > Requires: %{name} ... > is treated differently (is arch specific) than a -libs's > Requires: %{name} ... > (which isn't?) > > or is there some implicit requires in -devel's lib*.so symlink (which > doesn't show in 'rpm --requires' or 'rpm --provides')? It's a require that is generated at build time by following where the .so symlink points to and requiring that library file. $ rpm -qp --requires /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm warning: /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1 $ rpm -qp --requires /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm warning: /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1()(64bit) See how one is the non arch specific liblockdev.so.1 and the other is arch specific? ockdev.so.1' and the only thing that provides that is the i386 build. Likewise the only thing providing the liblockdev.so.1()(64bit) is the x86_64 build of it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Aug 22 11:45:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Aug 2007 06:45:05 -0500 Subject: [Fedora-packaging] Re: Re: Re: Are circular dependencies ok? References: <20070821091901.GA21257@camelia.ucw.cz.> <46CB3973.4070109@math.unl.edu> <20070821192915.GA5246@camelia.ucw.cz.> <46CB3E21.2040902@math.unl.edu> <20070821162744.7f96123c@mentok.boston.redhat.com> <20070822073647.23601bc4@ender> Message-ID: Jesse Keating wrote: >> or is there some implicit requires in -devel's lib*.so symlink (which >> doesn't show in 'rpm --requires' or 'rpm --provides')? > > It's a require that is generated at build time by following where > the .so symlink points to and requiring that library file. > > $ rpm -qp > --requires > /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm > warning: > /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm: > Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1 > > $ rpm -qp > --requires /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm > warning: /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm: Header > V3 DSA signature: NOKEY, key ID 4f2a6fd2 > liblockdev.so.1()(64bit) > > > See how one is the non arch specific liblockdev.so.1 and the other is > arch specific? ockdev.so.1' and the only thing that provides that is > the i386 build. Likewise the only thing providing the > liblockdev.so.1()(64bit) is the x86_64 build of it. Thanks Jessie, I think I've got my brain wrapped around this now. -- Rex From nicolas.mailhot at laposte.net Thu Aug 23 09:11:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 11:11:44 +0200 (CEST) Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: <46C8FD31.5060702@redhat.com> References: <46A7F596.7020101@redhat.com> <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> <46C8FD31.5060702@redhat.com> Message-ID: <43436.192.54.193.51.1187860304.squirrel@rousalka.dyndns.org> Le Lun 20 ao?t 2007 04:32, Jens Petersen a ?crit : > Nicolas Mailhot ????????: >> Le Jeu 26 juillet 2007 15:57, Rex Dieter a ?crit : >>> Jens Petersen wrote: >> >>>> I'll [wait] for responses before changing it to: >>>> %{_bindir}/fc-cache %{_datadir}/fonts >>> do it. Maybe even go one step further, and either say change to >>> %{_bindir}/fc-cache > > Yes, actually it seems this is probably better and the right thing to > do. I've changed dejavu-full to this since it actually simplified the specfile So we'll see if users report problems. However before it makes it in the guidelines I'd like someone to check if it does the right thing when font_dir_actually_used_in_this_pkg is changed from release to release. If it can break it will break there. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Aug 23 09:38:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 11:38:04 +0200 (CEST) Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <1187371017.1161.7.camel@localhost.localdomain> References: <1187371017.1161.7.camel@localhost.localdomain> Message-ID: <13761.192.54.193.51.1187861884.squirrel@rousalka.dyndns.org> Le Ven 17 ao?t 2007 19:16, Matthias Clasen a ?crit : > The review guidelines have this: > > - MUST: A package must own all directories that it creates. If it does > not create a directory that it uses, then it should require a package > which does create that directory. The exception to this are > directories > listed explicitly in the Filesystem Hierarchy Standard > (http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to > assume > that those directories exist. > > I think the shortened version in the review guidelines is misleading > and > causes us to err on the side of adding unwanted dependencies just for > directory ownership reasons. Can we have it changed to mention the > furhter exceptions that are discussed in the packaging guidelines ? IMHO the packaging guidelines are too lax. The harder stance in review guidelines helped clean up a lot of historical directory ownership mess no one was looking at. In particular I object to : > Another exception for directory ownership in packages is when there is > no clear dependency hierarchy. In that case directories should be created by generic packages like filesystem (not necessarily the filesystem package itseld). There's just no excuse for installing objects with no identified security policy on user systems. -- Nicolas Mailhot From pertusus at free.fr Thu Aug 23 09:52:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Aug 2007 11:52:45 +0200 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <13761.192.54.193.51.1187861884.squirrel@rousalka.dyndns.org> References: <1187371017.1161.7.camel@localhost.localdomain> <13761.192.54.193.51.1187861884.squirrel@rousalka.dyndns.org> Message-ID: <20070823095245.GB2447@free.fr> On Thu, Aug 23, 2007 at 11:38:04AM +0200, Nicolas Mailhot wrote: > > IMHO the packaging guidelines are too lax. The harder stance in review > guidelines helped clean up a lot of historical directory ownership > mess no one was looking at. > > In particular I object to : > > > Another exception for directory ownership in packages is when there is > > no clear dependency hierarchy. > > In that case directories should be created by generic packages like > filesystem (not necessarily the filesystem package itseld). There's > just no excuse for installing objects with no identified security > policy on user systems. It is not always worth creating a filesystem package for these cases. Simply having more than one package own the directory is simpler, and although not perfect, acceptable. It doesn't mean that things shouldn't be fixed when they need to, but in some simple case it isn't needed to be so strict. -- Pat From nicolas.mailhot at laposte.net Thu Aug 23 10:49:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 12:49:01 +0200 (CEST) Subject: [Fedora-packaging] review guidelines vs packaging guidelines Message-ID: <32793.192.54.193.51.1187866141.squirrel@rousalka.dyndns.org> Le Jeu 23 ao?t 2007 11:52, Patrice Dumas a ?crit : > It is not always worth creating a filesystem package for these cases. > Simply having more than one package own the directory is simpler, and > although not perfect, acceptable. When two packages share a directory sure it's not worth creating a separate package just for this directory. What I was suggesting was more like the games SIG collecting all the stray directories in a filesystem-games package, same for the perl SIG, etc Certainly there is a level at which you can create useful filesystem packages without falling in the whole-repository or single-directory package traps. That being said multiple ownership is compliant with the strict guidelines version, what I object to is no ownership as suggested by the lax variant. Regards, -- Nicolas Mailhot From pertusus at free.fr Thu Aug 23 10:58:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Aug 2007 12:58:36 +0200 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <32793.192.54.193.51.1187866141.squirrel@rousalka.dyndns.org> References: <32793.192.54.193.51.1187866141.squirrel@rousalka.dyndns.org> Message-ID: <20070823105836.GC2447@free.fr> On Thu, Aug 23, 2007 at 12:49:01PM +0200, Nicolas Mailhot wrote: > > When two packages share a directory sure it's not worth creating a > separate package just for this directory. What I was suggesting was > more like the games SIG collecting all the stray directories in a > filesystem-games package, same for the perl SIG, etc Certainly there > is a level at which you can create useful filesystem packages without > falling in the whole-repository or single-directory package traps. Agreed. > That being said multiple ownership is compliant with the strict > guidelines version, what I object to is no ownership as suggested by > the lax variant. Ok, I didn't understood it that way. But it isn't true, the guidelines are setup such that having no ownership of a directory is impossible. "The rule of thumb is that your package should own all of the directories it creates except those owned by packages which your package depends on. However, there are exceptions to this. If the directory hierarchy your package is located in may change due to updates of packages you depend on, then you need to take care to own those pieces of the hierarchy." "Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory." -- Pat From nicolas.mailhot at laposte.net Thu Aug 23 11:14:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 13:14:45 +0200 (CEST) Subject: [Fedora-packaging] review guidelines vs packaging guidelines Message-ID: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> Le Jeu 23 ao?t 2007 12:58, Patrice Dumas a ?crit : > Ok, I didn't understood it that way. But it isn't true, the guidelines > are setup such that having no ownership of a directory is impossible. I'm not so sure. The lax guidelines are more ambiguous, at no time do they clearly say "every directory must be owned" (with single or multiple owners). They say "the rule of thumb is everything must be owned but there are exceptions". And then proceed with some examples where every directory is accounted for without explicitely stating this is a hard rule. I don't think the OP would have been so happy with the lax version if he had understood them to enforce this rule. IMHO since the documented "exceptions" are clearly targetted at perl modules, it would be better to create a perl-filesystem package and forget about all the complex A/B convolutions in the guidelines. But that's for the perl SIG to discuss. -- Nicolas Mailhot From rdieter at math.unl.edu Thu Aug 23 12:06:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 23 Aug 2007 07:06:23 -0500 Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: <43436.192.54.193.51.1187860304.squirrel@rousalka.dyndns.org> References: <46A7F596.7020101@redhat.com> <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> <46C8FD31.5060702@redhat.com> <43436.192.54.193.51.1187860304.squirrel@rousalka.dyndns.org> Message-ID: <46CD783F.8050908@math.unl.edu> Nicolas Mailhot wrote: > I've changed dejavu-full to this since it actually simplified the > specfile So we'll see if users report problems. > > However before it makes it in the guidelines I'd like someone to check > if it does the right thing when font_dir_actually_used_in_this_pkg is > changed from release to release. If it can break it will break there. In cases where the fontdir changes, that can get tricky. To handle that, %postun, at least, should probably just use a call to 'fc-cache' *without* the font_dir_... -- Rex From pertusus at free.fr Thu Aug 23 13:34:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Aug 2007 15:34:52 +0200 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> References: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> Message-ID: <20070823133452.GE2447@free.fr> On Thu, Aug 23, 2007 at 01:14:45PM +0200, Nicolas Mailhot wrote: > > Le Jeu 23 ao?t 2007 12:58, Patrice Dumas a ?crit : > > > Ok, I didn't understood it that way. But it isn't true, the guidelines > > are setup such that having no ownership of a directory is impossible. > > I'm not so sure. The lax guidelines are more ambiguous, at no time do > they clearly say "every directory must be owned" (with single or > multiple owners). They say "the rule of thumb is everything must be Indeed. It would be much more clearer if there was, in addition to all the explanations, a simple sentence saying, maybe as a conclusion of all the examples: "In any case there should never be any unowned directory appearing after a package uninstall." -- Pat From nicolas.mailhot at laposte.net Thu Aug 23 13:43:05 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 15:43:05 +0200 (CEST) Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <20070823133452.GE2447@free.fr> References: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> <20070823133452.GE2447@free.fr> Message-ID: <48952.192.54.193.51.1187876585.squirrel@rousalka.dyndns.org> Le Jeu 23 ao?t 2007 15:34, Patrice Dumas a ?crit : > On Thu, Aug 23, 2007 at 01:14:45PM +0200, Nicolas Mailhot wrote: >> >> Le Jeu 23 ao?t 2007 12:58, Patrice Dumas a ?crit : >> >> > Ok, I didn't understood it that way. But it isn't true, the >> guidelines >> > are setup such that having no ownership of a directory is >> impossible. >> >> I'm not so sure. The lax guidelines are more ambiguous, at no time >> do >> they clearly say "every directory must be owned" (with single or >> multiple owners). They say "the rule of thumb is everything must be > > Indeed. It would be much more clearer if there was, in addition to all > the explanations, a simple sentence saying, maybe as a conclusion of > all > the examples: > > "In any case there should never be any unowned directory appearing > after > a package uninstall." Who can add this ? -- Nicolas Mailhot From a.badger at gmail.com Thu Aug 23 16:11:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Aug 2007 09:11:10 -0700 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <48952.192.54.193.51.1187876585.squirrel@rousalka.dyndns.org> References: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> <20070823133452.GE2447@free.fr> <48952.192.54.193.51.1187876585.squirrel@rousalka.dyndns.org> Message-ID: <46CDB19E.80607@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: > Le Jeu 23 ao?t 2007 15:34, Patrice Dumas a ?crit : >> On Thu, Aug 23, 2007 at 01:14:45PM +0200, Nicolas Mailhot wrote: >>> Le Jeu 23 ao?t 2007 12:58, Patrice Dumas a ?crit : >>> >>>> Ok, I didn't understood it that way. But it isn't true, the >>> guidelines >>>> are setup such that having no ownership of a directory is >>> impossible. >>> >>> I'm not so sure. The lax guidelines are more ambiguous, at no time >>> do >>> they clearly say "every directory must be owned" (with single or >>> multiple owners). They say "the rule of thumb is everything must be >> Indeed. It would be much more clearer if there was, in addition to all >> the explanations, a simple sentence saying, maybe as a conclusion of >> all >> the examples: >> >> "In any case there should never be any unowned directory appearing >> after >> a package uninstall." > > Who can add this ? > New clarified language. Packaging Guidelines: ''' In general, your package should own all of the directories that it creates but the situation is more complex than in the case of files because many packages put files into the same directories. The rule of thumb is that your package should own all of the directories it creates except those owned by packages which your package depends on. *However, there are times when you should own more than this.* If the directory hierarchy your package is located in may change due to updates of packages you depend on, then you need to take care to own those pieces of the hierarchy. [snip examples] In any case, there should never be any unowned directories after a package is uninstalled from the system. ''' The one change and one addition are meant to clarify that owning more directories can be permissible but owning less is not. Package Review Guidelines: ''' - - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Refer to the [Packaging/Guidelines#FileAndDirectoryOwnership Guidelines] for examples. ''' I think the confusion in the Review Guidelines is over the extra wording which only lists exceptions for FHS directories: ''' The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. ''' Directing the reader to the Guidelines for complete details seems better. Matthias, does this address your concerns? - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzbGeX6yAic2E7kgRAgGmAKCwZZjGKK3Tq76AnakJtPl1Fe4j7ACfUmJT aPm8+Mo5pfNIORHHo+J4Vmc= =Do6j -----END PGP SIGNATURE----- From skasal at redhat.com Thu Aug 23 17:04:59 2007 From: skasal at redhat.com (Stepan Kasal) Date: Thu, 23 Aug 2007 19:04:59 +0200 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <46CDB19E.80607@gmail.com> References: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> <20070823133452.GE2447@free.fr> <48952.192.54.193.51.1187876585.squirrel@rousalka.dyndns.org> <46CDB19E.80607@gmail.com> Message-ID: <20070823170459.GD3656@camelia.ucw.cz.> Hello, On Thu, Aug 23, 2007 at 09:11:10AM -0700, Toshio Kuratomi wrote: > New clarified language. Packaging Guidelines: > ''' > In general, your package should own all of the directories that it > creates but the situation is more complex than in the case of files > because many packages put files into the same directories. the second half of the sentence really confuses me. I suggest to put period after "creates". > The rule of > thumb is that your package should own all of the directories it creates repeated again? > except those owned by packages which your package depends on. ok > *However, there are times when you should own more than this.* Again, this puzzles me. I would say: "In certain situations, a directory may be owned by two packages. Typically, more than one package has files in a common directory, but none of them requires another of them--in that case, each of them shall own the directory." > If the directory > hierarchy your package is located in may change due to updates of > packages you depend on, then you need to take care to own those pieces > of the hierarchy. This might be correct, but I'm not able to decipher it; perhaps I have not encountered such a situation yet. > [snip examples] > > In any case, there should never be any unowned directories after a > package is uninstalled from the system. Again, I would rephrase. Something like: "In any case, a system may never contain a file owned by an installed package whoch would lay below an unowned directory. (That's because such a directory would remain on the system after the corresponding package has been removed.)" I hope my comments help. Have a nice day, Stepan From mtasaka at ioa.s.u-tokyo.ac.jp Thu Aug 23 17:39:48 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 24 Aug 2007 02:39:48 +0900 Subject: [Fedora-packaging] commands under privileged users' path Message-ID: <46CDC664.8040009@ioa.s.u-tokyo.ac.jp> Well, currently I am reviewing several reviewing requests and I asked a submitter to change user/group registration scriptlets according to http://fedoraproject.org/wiki/Packaging/UsersAndGroups and he/she changed as such. Then I noticed : %pre servers # Following the Wiki instructions ... getent group iceuser > /dev/null || groupadd -r iceuser Here "groupadd" (which is in Fedora under /usr/sbin) is used by only basename, not by full path. IMO this will cause a problem when "yum update" or "rpm -ivh" is done by normal users using "su -c" or "sudo" because normal users usually don't have /usr/sbin in their path. So I think that the following should be added to the wiki that commands which are under privileged users' path and not under normal users' path must be written with full path. Do you have any suggestions? Regards, Mamoru From a.badger at gmail.com Thu Aug 23 18:01:32 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Aug 2007 11:01:32 -0700 Subject: [Fedora-packaging] review guidelines vs packaging guidelines In-Reply-To: <20070823170459.GD3656@camelia.ucw.cz.> References: <38883.192.54.193.51.1187867685.squirrel@rousalka.dyndns.org> <20070823133452.GE2447@free.fr> <48952.192.54.193.51.1187876585.squirrel@rousalka.dyndns.org> <46CDB19E.80607@gmail.com> <20070823170459.GD3656@camelia.ucw.cz.> Message-ID: <46CDCB7C.6050205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stepan Kasal wrote: > Hello, > > On Thu, Aug 23, 2007 at 09:11:10AM -0700, Toshio Kuratomi wrote: >> New clarified language. Packaging Guidelines: >> ''' >> In general, your package should own all of the directories that it >> creates but the situation is more complex than in the case of files >> because many packages put files into the same directories. > > the second half of the sentence really confuses me. > I suggest to put period after "creates". > >> The rule of >> thumb is that your package should own all of the directories it creates > > repeated again? > >> except those owned by packages which your package depends on. > > ok > >> *However, there are times when you should own more than this.* > > Again, this puzzles me. I would say: > "In certain situations, a directory may be owned by two packages. > Typically, more than one package has files in a common directory, but > none of them requires another of them--in that case, each of them > shall own the directory." > >> If the directory >> hierarchy your package is located in may change due to updates of >> packages you depend on, then you need to take care to own those pieces >> of the hierarchy. > > This might be correct, but I'm not able to decipher it; perhaps I > have not encountered such a situation yet. > >> [snip examples] >> >> In any case, there should never be any unowned directories after a >> package is uninstalled from the system. > > Again, I would rephrase. Something like: > "In any case, a system may never contain a file owned by an installed > package whoch would lay below an unowned directory. > (That's because such a directory would remain on the system after the > corresponding package has been removed.)" I didn't want to tear up the existing guidelines more than necessary. But I agree that the wording leaves something to be desired. How about: ''' Directory ownership is a little more complex than file ownership. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory. Examples of this are: 1) The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version. [perl module example here] 2) Multiple packages have files in a common directory but none of them requires others. [hierarchy example here] In all cases we are guarding against unowned directories being present on a system. Unowned directories are affected by the umask of the user installing the package and thus can be a security risk or lead to packages which won't run. ''' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzct8X6yAic2E7kgRAqC3AJ9GPui1N01ZhbfkK1UpQ9apCMnzeQCeL57r 5HQXjwmWXl4xJgt224Vci+I= =3ygx -----END PGP SIGNATURE----- From ville.skytta at iki.fi Thu Aug 23 19:10:19 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 23 Aug 2007 22:10:19 +0300 Subject: [Fedora-packaging] commands under privileged users' path In-Reply-To: <46CDC664.8040009@ioa.s.u-tokyo.ac.jp> References: <46CDC664.8040009@ioa.s.u-tokyo.ac.jp> Message-ID: <200708232210.19795.ville.skytta@iki.fi> On Thursday 23 August 2007, Mamoru Tasaka wrote: > > Then I noticed : > %pre servers > # Following the Wiki instructions ... > getent group iceuser > /dev/null || groupadd -r iceuser > > > Here "groupadd" (which is in Fedora under /usr/sbin) > is used by only basename, not by full path. That's intentional. People wanted to have a dependency on shadow-utils instead of the actual executables used, so it was changed, and thus we are now already making some assumptions about things and full hardcoded paths no longer add any real value, they just clutter specfiles. > IMO this will cause > a problem when "yum update" or "rpm -ivh" is done by normal > users using "su -c" or "sudo" because normal users usually > don't have /usr/sbin in their path. rpm ensures that it is there. More specifically, it sets this for all scriptlets (based on rpm hg sources, lib/psm.c): static char * SCRIPT_PATH = "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin"; Have you actually tested and found that the problem you describe exists in some scenarios? I do rpm/smart/yum operations from a "sudo -s" shell all the time (no /usr/sbin in PATH there), and have not encountered any problems like this. From mtasaka at ioa.s.u-tokyo.ac.jp Fri Aug 24 06:31:32 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 24 Aug 2007 15:31:32 +0900 Subject: [Fedora-packaging] commands under privileged users' path In-Reply-To: <200708232210.19795.ville.skytta@iki.fi> References: <46CDC664.8040009@ioa.s.u-tokyo.ac.jp> <200708232210.19795.ville.skytta@iki.fi> Message-ID: <46CE7B44.2050309@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote, at 08/24/2007 04:10 AM +9:00: > On Thursday 23 August 2007, Mamoru Tasaka wrote: > >> IMO this will cause >> a problem when "yum update" or "rpm -ivh" is done by normal >> users using "su -c" or "sudo" because normal users usually >> don't have /usr/sbin in their path. > > rpm ensures that it is there. More specifically, it sets this for all > scriptlets (based on rpm hg sources, lib/psm.c): > > static char * SCRIPT_PATH > = "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin"; > > Have you actually tested and found that the problem you describe exists in > some scenarios? I do rpm/smart/yum operations from a "sudo -s" shell all the > time (no /usr/sbin in PATH there), and have not encountered any problems like > this. Thank you for clarifying this. As I have always met with umask (permission) problem on the directories not properly owned, I was thinking that scriptlet path _may_ also have similar problems. Mamoru From mefoster at gmail.com Mon Aug 27 15:21:49 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Mon, 27 Aug 2007 17:21:49 +0200 Subject: [Fedora-packaging] Wiki is inconsistent on Mono file locations Message-ID: Disclaimer: I'm not a Mono programmer; I'm just trying to package something that includes some Mono pieces. I was looking at the Wiki about packaging for Mono (http://fedoraproject.org/wiki/Packaging/Mono), and it seems to contradict itself. Under "File locations", it says Mono packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir} Then, right below, it gives sample gacutil lines that install into %{_prefix}/lib, with a note that it might later change to %{_libdir} and a link to a bug with a lot of discussion, but no clear indication of whether the proposal was accepted or not. So, should my stuff go into %{_libdir} or %{_prefix}/lib? Thanks very much! MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From tcallawa at redhat.com Mon Aug 27 16:57:33 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 27 Aug 2007 12:57:33 -0400 Subject: [Fedora-packaging] Wiki is inconsistent on Mono file locations In-Reply-To: References: Message-ID: <1188233853.28181.44.camel@dhcp83-165.boston.redhat.com> On Mon, 2007-08-27 at 17:21 +0200, Mary Ellen Foster wrote: > Disclaimer: I'm not a Mono programmer; I'm just trying to package > something that includes some Mono pieces. > > I was looking at the Wiki about packaging for Mono > (http://fedoraproject.org/wiki/Packaging/Mono), and it seems to > contradict itself. Under "File locations", it says > Mono packages should install assemblies to %{_libdir} > rather than /usr/lib or %{_datadir} > > Then, right below, it gives sample gacutil lines that install into > %{_prefix}/lib, with a note that it might later change to %{_libdir} > and a link to a bug with a lot of discussion, but no clear indication > of whether the proposal was accepted or not. > > So, should my stuff go into %{_libdir} or %{_prefix}/lib? %{_libdir}. The example should have been corrected, I'll go fix it now. ~spot From mefoster at gmail.com Mon Aug 27 18:14:55 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Mon, 27 Aug 2007 20:14:55 +0200 Subject: [Fedora-packaging] Wiki is inconsistent on Mono file locations In-Reply-To: <1188233853.28181.44.camel@dhcp83-165.boston.redhat.com> References: <1188233853.28181.44.camel@dhcp83-165.boston.redhat.com> Message-ID: On 27/08/07, Tom spot Callaway wrote: > > On Mon, 2007-08-27 at 17:21 +0200, Mary Ellen Foster wrote: > > So, should my stuff go into %{_libdir} or %{_prefix}/lib? > > %{_libdir}. The example should have been corrected, I'll go fix it now. Awesome, thanks for the clarification! I think you missed the %{_prefix} in the actual cut'n'paste gacutil example, though. MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From opensource at till.name Tue Aug 28 21:39:00 2007 From: opensource at till.name (Till Maas) Date: Tue, 28 Aug 2007 23:39:00 +0200 Subject: [Fedora-packaging] overview of all Package Guidelines or use CategoryPackageGuidelines Message-ID: <200708282339.10766.opensource@till.name> Hi, is there a page in the wiki that simply lists all existing guidelines for packages in Fedora? I guess not. Therefore I suggest to add all these guidelines to CategoryPackageGuidelines. I cannot do this myself, because I cannot change the regarding wiki pages. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Wed Aug 29 01:11:54 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Aug 2007 18:11:54 -0700 Subject: [Fedora-packaging] Python Egg Guidelines Message-ID: <46D4C7DA.2010603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I've finished a first draft of guidelines for using python eggs. There's one open question -- whether we should be creating eggs for upstreams that do not create them by default. I think the answer to that is no except for one special case but others might disagree. The rest of it is pretty straightforward; made longer by the addition of copious examples. Take a look and give feedback. The Packaging Committee will vote on this on Tuesday (next week's packaging meeting.) https://fedoraproject.org/wiki/PackagingDrafts/PythonEggs PS: We already have a couple of cases where we need to apply these guidelines * Review for parallel installable python-sqlalchemy0.3: https://bugzilla.redhat.com/show_bug.cgi?id=257381 * Request for python-cherrypy-3.0 upgrade which needs a python-cherrypy2 compat package for TurboGears. https://bugzilla.redhat.com/show_bug.cgi?id=224683 * Request to add egginfo to docutils (which is a departure from upstream). https://bugzilla.redhat.com/show_bug.cgi?id=256541 - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1MfaX6yAic2E7kgRAmIlAJkBMOooviBZHGZhkg+Anh5kBQvDkACeIXLq poCNwcUzHDbE8DN8EHU+58g= =NZPE -----END PGP SIGNATURE----- From fedora at leemhuis.info Wed Aug 29 06:50:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 29 Aug 2007 08:50:23 +0200 Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? Message-ID: <46D5172F.7010604@leemhuis.info> Hi all, the Fonts section on http://fedoraproject.org/wiki/Packaging/ScriptletSnippets contains this: > Use this when your package installs new fonts. > > {{{ > %post > if [ -x %{_bindir}/fc-cache ]; then > %{_bindir}/fc-cache %{_datadir}/fonts > fi > %postun > if [ "$1" = "0" ]; then > if [ -x %{_bindir}/fc-cache ]; then > %{_bindir}/fc-cache %{_datadir}/fonts > fi > fi > }}} Is there a specific reason why there is no "|| :" at the end of "%{_bindir}/fc-cache %{_datadir}/fonts"? I think there should be one, as this happened to me during a F-7 -> rawhide update (that's still in progress while I'm writing this mail, so more errors might show up): > Updating : bitstream-vera-fonts ################### [ 383/1850] > /usr/share/fonts/default/Type1: failed to write cache > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(bitstream-vera-fonts-1.10-8.noarch) scriptlet failed, exit status 2 [...] > Updating : fontconfig ################### [ 416/1850] > /usr/share/fonts/default/Type1: failed to write cache > /usr/share/fonts/default/ghostscript: failed to write cache > /usr/share/X11/fonts/Type1: failed to write cache > error: %post(fontconfig-2.4.2-5.fc8.x86_64) scriptlet failed, exit status 3 [...] > Updating : dejavu-lgc-fonts ################### [ 548/1850] > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(dejavu-lgc-fonts-2.19-1.noarch) scriptlet failed, exit status 1 > Updating : liberation-fonts ################### [ 549/1850] > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(liberation-fonts-0.2-1.fc8.noarch) scriptlet failed, exit status 1 CU knurd From paul at city-fan.org Wed Aug 29 11:52:26 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Aug 2007 12:52:26 +0100 Subject: [Fedora-packaging] sendmail license Message-ID: <46D55DFA.3050402@city-fan.org> The sendmail license (http://www.sendmail.org/ftp/LICENSE) is not currently listed in the "Good licenses" list, nor is it listed on the FSF "list of licenses" page. However, sendmail *is* listed in the FSF directory of free software (http://directory.fsf.org/sendmail.html). Please can the sendmail license be added to the good licenses page? Paul. From paul at city-fan.org Wed Aug 29 13:06:07 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Aug 2007 14:06:07 +0100 Subject: [Fedora-packaging] Zope Public License Message-ID: <46D56F3F.8010107@city-fan.org> http://fedoraproject.org/wiki/Licensing lists two versions (1.0 and 2.0) of the Zope Public License in the "good licenses" list. Both entries in the table refer to http://www.zope.org/Resources/ZPL, which has contained the text of version 2.1 of the license for quite some time. Can ZPLv2.1 please be added to the good licenses list, as it's needed for python-zope-interface. Paul. From tcallawa at redhat.com Wed Aug 29 14:45:26 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 29 Aug 2007 10:45:26 -0400 Subject: [Fedora-packaging] Zope Public License In-Reply-To: <46D56F3F.8010107@city-fan.org> References: <46D56F3F.8010107@city-fan.org> Message-ID: <1188398726.3480.48.camel@dhcp83-165.boston.redhat.com> On Wed, 2007-08-29 at 14:06 +0100, Paul Howarth wrote: > http://fedoraproject.org/wiki/Licensing lists two versions (1.0 and 2.0) > of the Zope Public License in the "good licenses" list. Both entries in > the table refer to http://www.zope.org/Resources/ZPL, which has > contained the text of version 2.1 of the license for quite some time. > > Can ZPLv2.1 please be added to the good licenses list, as it's needed > for python-zope-interface. Done. ~spot From pertusus at free.fr Thu Aug 30 07:30:53 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 30 Aug 2007 09:30:53 +0200 Subject: [Fedora-packaging] tex related packages names Message-ID: <20070830073053.GB2751@free.fr> Hello, I propose tex packages to be named tex-something instead of tetex-something I also think that it is not worth renaming existing packages with tetex-, at least for now, maybe later, but instead have them Provides: tex-something = %{version}-%{release} -- Pat From jamatos at fc.up.pt Thu Aug 30 08:55:00 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 30 Aug 2007 09:55:00 +0100 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <20070830073053.GB2751@free.fr> References: <20070830073053.GB2751@free.fr> Message-ID: <200708300955.00406.jamatos@fc.up.pt> On Thursday 30 August 2007 08:30:53 Patrice Dumas wrote: > Hello, > > I propose tex packages to be named > tex-something > instead of > tetex-something Why not latex-something instead? The packages are latex packages after all... > I also think that it is not worth renaming existing packages with > tetex-, at least for now, maybe later, but instead have them > Provides: tex-something = %{version}-%{release} As soon as tetex is gone the name tetex- will be weird. The funny part is that we only have this problem because we have named the packages not following our general guidelines (packages are named after the language, not the implementation). ;-) > -- > Pat -- Jos? Ab?lio From pertusus at free.fr Thu Aug 30 09:02:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 30 Aug 2007 11:02:57 +0200 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <200708300955.00406.jamatos@fc.up.pt> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> Message-ID: <20070830090257.GK2751@free.fr> On Thu, Aug 30, 2007 at 09:55:00AM +0100, Jos? Matos wrote: > On Thursday 30 August 2007 08:30:53 Patrice Dumas wrote: > > Hello, > > > > I propose tex packages to be named > > tex-something > > instead of > > tetex-something > > Why not latex-something instead? latex is a subset of TeX. For example tetex-tex4ht works for tex and latex. -- Pat From jamatos at fc.up.pt Thu Aug 30 09:13:01 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 30 Aug 2007 10:13:01 +0100 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <20070830090257.GK2751@free.fr> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> <20070830090257.GK2751@free.fr> Message-ID: <200708301013.01409.jamatos@fc.up.pt> On Thursday 30 August 2007 10:02:57 Patrice Dumas wrote: > latex is a subset of TeX. For example tetex-tex4ht works for tex and > latex. I was thinking about context? modules and to have a way to distinguish them. But it there are modules that work with tex and not latex then the point is moot, it is not worth to have yet another category. > -- > Pat ? with the proper capitalisation that I always forget -- Jos? Ab?lio From jnovy at redhat.com Thu Aug 30 10:17:44 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 30 Aug 2007 12:17:44 +0200 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <200708300955.00406.jamatos@fc.up.pt> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> Message-ID: <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> On Thu, Aug 30, 2007 at 09:55:00AM +0100, Jos? Matos wrote: > On Thursday 30 August 2007 08:30:53 Patrice Dumas wrote: > > Hello, > > > > I propose tex packages to be named > > tex-something > > instead of > > tetex-something > > Why not latex-something instead? > > The packages are latex packages after all... > > > I also think that it is not worth renaming existing packages with > > tetex-, at least for now, maybe later, but instead have them > > Provides: tex-something = %{version}-%{release} > > As soon as tetex is gone the name tetex- will be weird. The funny part is > that we only have this problem because we have named the packages not > following our general guidelines (packages are named after the language, not > the implementation). ;-) > How about removing the prefix completely? Package description should be sufficient to figure out it ships a TeX related stuff and we don't have many of them currently. I see the only purpose of the prefix to avoid conficts with already existing packages, in that case (la)tex-* or suffix *-(la)tex is ok IMO. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jamatos at fc.up.pt Thu Aug 30 10:36:13 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 30 Aug 2007 11:36:13 +0100 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> Message-ID: <200708301136.13118.jamatos@fc.up.pt> On Thursday 30 August 2007 11:17:44 Jindrich Novy wrote: > How about removing the prefix completely? Package description should be > sufficient to figure out it ships a TeX related stuff and we don't have > many of them currently. I see the only purpose of the prefix to avoid > conficts with already existing packages, in that case (la)tex-* or suffix > *-(la)tex is ok IMO. > > Jindrich tex is a programming language, so IMHO we should follow the same rules as used for other programming languages, prefixing the package name with the language name. -- Jos? Ab?lio From jonathan.underwood at gmail.com Thu Aug 30 12:53:14 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 30 Aug 2007 13:53:14 +0100 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <20070830073053.GB2751@free.fr> References: <20070830073053.GB2751@free.fr> Message-ID: <645d17210708300553t738f66bja923df9794281d47@mail.gmail.com> On 30/08/2007, Patrice Dumas wrote: > Hello, > > I propose tex packages to be named > tex-something > instead of > tetex-something > > I also think that it is not worth renaming existing packages with > tetex-, at least for now, maybe later, but instead have them > Provides: tex-something = %{version}-%{release} Please see: http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming which I put together a number of months ago (and mentioned on list) - feel free to edit and add suggestions. Jonathan. From harald at redhat.com Thu Aug 30 14:12:01 2007 From: harald at redhat.com (Harald Hoyer) Date: Thu, 30 Aug 2007 16:12:01 +0200 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts Message-ID: <46D6D031.7020504@redhat.com> Open for comments/corrections/modifications... http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 30 14:42:23 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 30 Aug 2007 16:42:23 +0200 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <46D6D031.7020504@redhat.com> References: <46D6D031.7020504@redhat.com> Message-ID: <20070830164223.4148a903@python3.es.egwn.lan> Harald Hoyer wrote : > Open for comments/corrections/modifications... > > http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript Won't the unconditional fdr_status execution in that template always output something? (not to mention that it'll always be run even when completely unneeded)... I'd move it into the "cases" where it's needed, or maybe even inside the start() and stop() functions to make the restart cases shorter and cleaner. I also don't really like hardcoding "fdr" where "rh" was before... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 0.62 0.53 0.55 From pertusus at free.fr Thu Aug 30 15:29:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 30 Aug 2007 17:29:51 +0200 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <645d17210708300553t738f66bja923df9794281d47@mail.gmail.com> References: <20070830073053.GB2751@free.fr> <645d17210708300553t738f66bja923df9794281d47@mail.gmail.com> Message-ID: <20070830152951.GE6104@free.fr> On Thu, Aug 30, 2007 at 01:53:14PM +0100, Jonathan Underwood wrote: > On 30/08/2007, Patrice Dumas wrote: > > Hello, > > > > I propose tex packages to be named > > tex-something > > instead of > > tetex-something > > > > I also think that it is not worth renaming existing packages with > > tetex-, at least for now, maybe later, but instead have them > > Provides: tex-something = %{version}-%{release} > > Please see: > > http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming > > which I put together a number of months ago (and mentioned on list) - > feel free to edit and add suggestions. I remembered something but I was too lazy to search ;-) I think that there are 2 distinct issues that are raised in your proposal * tex related package names * virtual requires/provides I think that they should be discussed apart. The second issue could be solved simply without the packaging commitee ruling, but by asking Jindrich to add the virtual provide. Then the use of this provide could be advocated in the guidelines. I suggest discussing the virtual provides in one of the texlive submissions. For the tex related package names, my personnal point of view would be not to distinguish tex and latex add-ons (at least in the name). I have a slight preference for prepending tex- to all the tex/latex related packages. -- Pat From jonathan.underwood at gmail.com Thu Aug 30 16:29:45 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 30 Aug 2007 17:29:45 +0100 Subject: [Fedora-packaging] tex related packages names In-Reply-To: <20070830152951.GE6104@free.fr> References: <20070830073053.GB2751@free.fr> <645d17210708300553t738f66bja923df9794281d47@mail.gmail.com> <20070830152951.GE6104@free.fr> Message-ID: <645d17210708300929p71b91fe6xaec637ccdfb18fd8@mail.gmail.com> On 30/08/2007, Patrice Dumas wrote: > I think that there are 2 distinct issues that are raised in your > proposal > > * tex related package names > * virtual requires/provides > > I think that they should be discussed apart. The second issue could be > solved simply without the packaging commitee ruling, but by asking > Jindrich to add the virtual provide. Then the use of this provide could > be advocated in the guidelines. > Yep. > I suggest discussing the virtual provides in one of the texlive > submissions. > OK. > For the tex related package names, my personnal point of view would be > not to distinguish tex and latex add-ons (at least in the name). I have > a slight preference for prepending tex- to all the tex/latex related > packages. > Yes - I favour that too, but put other suggestions up there for consideration. > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From harald at redhat.com Thu Aug 30 17:24:52 2007 From: harald at redhat.com (Harald Hoyer) Date: Thu, 30 Aug 2007 19:24:52 +0200 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <20070830164223.4148a903@python3.es.egwn.lan> References: <46D6D031.7020504@redhat.com> <20070830164223.4148a903@python3.es.egwn.lan> Message-ID: <46D6FD64.10108@redhat.com> Matthias Saou schrieb: > Harald Hoyer wrote : > >> Open for comments/corrections/modifications... >> >> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript > > Won't the unconditional fdr_status execution in that template always > output something? correct > (not to mention that it'll always be run even when > completely unneeded)... I'd move it into the "cases" where it's > needed, or maybe even inside the start() and stop() functions to make > the restart cases shorter and cleaner. good point > > I also don't really like hardcoding "fdr" where "rh" was before... hardcoding? > > Matthias > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Thu Aug 30 19:08:20 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 30 Aug 2007 22:08:20 +0300 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <46D6FD64.10108@redhat.com> References: <46D6D031.7020504@redhat.com> <20070830164223.4148a903@python3.es.egwn.lan> <46D6FD64.10108@redhat.com> Message-ID: <200708302208.20831.ville.skytta@iki.fi> On Thursday 30 August 2007, Harald Hoyer wrote: > > I also don't really like hardcoding "fdr" where "rh" was before... > > hardcoding? The point I believe is that if we want a separate function in the init script template to be invoked for the status action, plain "status" cannot be used because there already is a function by that name in /etc/init.d/functions so it needs to have some other name. A "fdr_" prefix is IMHO as good as anything but some people don't like it. One way to solve it would be just to invoke the "status" from /etc/init.d/functions in the "status" action case and ditch the current separate fdr_status function. From jdennis at redhat.com Thu Aug 30 20:09:48 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 30 Aug 2007 16:09:48 -0400 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <200708302208.20831.ville.skytta@iki.fi> References: <46D6D031.7020504@redhat.com> <20070830164223.4148a903@python3.es.egwn.lan> <46D6FD64.10108@redhat.com> <200708302208.20831.ville.skytta@iki.fi> Message-ID: <1188504588.14525.14.camel@finch.boston.redhat.com> I think I'm a bit confused. The new initscript example on the wiki does not source /lib/lsb/functions. I thought there was something special about those as opposed to the implementation in /etc/init.d/functions and one of the driving forces behind having to edit every initscript. Also, for some reason the wike page I'm looking at has 'rh_' prefixes and not 'fdr_' prefixes. Am I looking at the wrong page? -- John Dennis From Axel.Thimm at ATrpms.net Thu Aug 30 23:03:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 31 Aug 2007 01:03:11 +0200 Subject: [Fedora-packaging] Prefix packages written in C/C++ with C-, CXX- (was: tex related packages names) In-Reply-To: <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> Message-ID: <20070830230311.GA3665@puariko.nirvana> On Thu, Aug 30, 2007 at 12:17:44PM +0200, Jindrich Novy wrote: > How about removing the prefix completely? Package description should be > sufficient to figure out it ships a TeX related stuff and we don't have many of > them currently. I see the only purpose of the prefix to avoid conficts with > already existing packages, in that case (la)tex-* or suffix *-(la)tex is ok IMO. You'd have my vote for that. I find the overprefixing a bit silly - next we'll have C-glibc. Prefixing should be used for resolving ambiguous situations, not as a replacement for the Groups: tag. Oh yes, the subject is just to catch reading eyes. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From panemade at gmail.com Fri Aug 31 04:06:44 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 31 Aug 2007 09:36:44 +0530 Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? In-Reply-To: <46D5172F.7010604@leemhuis.info> References: <46D5172F.7010604@leemhuis.info> Message-ID: Hi, On 8/29/07, Thorsten Leemhuis wrote: > Hi all, > > the Fonts section on > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets > contains this: > > > Use this when your package installs new fonts. > > > > {{{ > > %post > > if [ -x %{_bindir}/fc-cache ]; then > > %{_bindir}/fc-cache %{_datadir}/fonts > > fi > > %postun > > if [ "$1" = "0" ]; then > > if [ -x %{_bindir}/fc-cache ]; then > > %{_bindir}/fc-cache %{_datadir}/fonts > > fi > > fi > > }}} > > Is there a specific reason why there is no "|| :" at the end of > "%{_bindir}/fc-cache %{_datadir}/fonts"? I think there should be one, as > this happened to me during a F-7 -> rawhide update (that's still in > progress while I'm writing this mail, so more errors might show up): > > > Updating : bitstream-vera-fonts ################### [ 383/1850] > > /usr/share/fonts/default/Type1: failed to write cache > > /usr/share/fonts/default/ghostscript: failed to write cache > > error: %post(bitstream-vera-fonts-1.10-8.noarch) scriptlet failed, exit status 2 > [...] > > Updating : fontconfig ################### [ 416/1850] > > /usr/share/fonts/default/Type1: failed to write cache > > /usr/share/fonts/default/ghostscript: failed to write cache > > /usr/share/X11/fonts/Type1: failed to write cache > > error: %post(fontconfig-2.4.2-5.fc8.x86_64) scriptlet failed, exit status 3 > [...] > > Updating : dejavu-lgc-fonts ################### [ 548/1850] > > /usr/share/fonts/default/ghostscript: failed to write cache > > error: %post(dejavu-lgc-fonts-2.19-1.noarch) scriptlet failed, exit status 1 > > Updating : liberation-fonts ################### [ 549/1850] > > /usr/share/fonts/default/ghostscript: failed to write cache > > error: %post(liberation-fonts-0.2-1.fc8.noarch) scriptlet failed, exit status 1 This is because of timestamp problem on your machine. check " man FcDirCacheValid" to know more why FcDirCacheValid call produced output as " failed to write cache". Regards, Parag. From fedora at leemhuis.info Fri Aug 31 04:45:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 31 Aug 2007 06:45:28 +0200 Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? In-Reply-To: References: <46D5172F.7010604@leemhuis.info> Message-ID: <46D79CE8.2040005@leemhuis.info> On 31.08.2007 06:06, Parag N(????) wrote: > On 8/29/07, Thorsten Leemhuis wrote: >> the Fonts section on >> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets >> contains this: >> >>> Use this when your package installs new fonts. >>> >>> {{{ >>> %post >>> if [ -x %{_bindir}/fc-cache ]; then >>> %{_bindir}/fc-cache %{_datadir}/fonts >>> fi >>> %postun >>> if [ "$1" = "0" ]; then >>> if [ -x %{_bindir}/fc-cache ]; then >>> %{_bindir}/fc-cache %{_datadir}/fonts >>> fi >>> fi >>> }}} >> Is there a specific reason why there is no "|| :" at the end of >> "%{_bindir}/fc-cache %{_datadir}/fonts"? I think there should be one, as >> this happened to me during a F-7 -> rawhide update (that's still in >> progress while I'm writing this mail, so more errors might show up): >> >>> Updating : bitstream-vera-fonts ################### [ 383/1850] >>> /usr/share/fonts/default/Type1: failed to write cache >>> /usr/share/fonts/default/ghostscript: failed to write cache >>> error: %post(bitstream-vera-fonts-1.10-8.noarch) scriptlet failed, exit status 2 >> [...] >>> Updating : fontconfig ################### [ 416/1850] >>> /usr/share/fonts/default/Type1: failed to write cache >>> /usr/share/fonts/default/ghostscript: failed to write cache >>> /usr/share/X11/fonts/Type1: failed to write cache >>> error: %post(fontconfig-2.4.2-5.fc8.x86_64) scriptlet failed, exit status 3 >> [...] >>> Updating : dejavu-lgc-fonts ################### [ 548/1850] >>> /usr/share/fonts/default/ghostscript: failed to write cache >>> error: %post(dejavu-lgc-fonts-2.19-1.noarch) scriptlet failed, exit status 1 >>> Updating : liberation-fonts ################### [ 549/1850] >>> /usr/share/fonts/default/ghostscript: failed to write cache >>> error: %post(liberation-fonts-0.2-1.fc8.noarch) scriptlet failed, exit status 1 > > This is because of timestamp problem on your machine. check " man > FcDirCacheValid" to know more why FcDirCacheValid call produced output > as " failed to write cache". I noticed in between that is was something stupid on my side, but that doesn't matter much IMHO. The ScriptletSnippets IMHO and AFAIK should be adjusted to make sure the script for this or similar errors don't end with a errorlevel != 0 CU thl From nicolas.mailhot at laposte.net Fri Aug 31 09:32:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 31 Aug 2007 11:32:37 +0200 (CEST) Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? In-Reply-To: <46D79CE8.2040005@leemhuis.info> References: <46D5172F.7010604@leemhuis.info> <46D79CE8.2040005@leemhuis.info> Message-ID: <9650.192.54.193.51.1188552757.squirrel@rousalka.dyndns.org> Le Ven 31 ao?t 2007 06:45, Thorsten Leemhuis a ?crit : > I noticed in between that is was something stupid on my side, but that > doesn't matter much IMHO. The ScriptletSnippets IMHO and AFAIK should > be > adjusted to make sure the script for this or similar errors don't end > with a errorlevel != 0 If this is a one-off or a very unusual failure, I don't see what for. We only ignore harmless common errors. -- Nicolas Mailhot From jonathan.underwood at gmail.com Fri Aug 31 11:04:48 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 31 Aug 2007 12:04:48 +0100 Subject: [Fedora-packaging] Prefix packages written in C/C++ with C-, CXX- (was: tex related packages names) In-Reply-To: <20070830230311.GA3665@puariko.nirvana> References: <20070830073053.GB2751@free.fr> <200708300955.00406.jamatos@fc.up.pt> <20070830101744.GA8299@dhcp-lab-186.brq.redhat.com> <20070830230311.GA3665@puariko.nirvana> Message-ID: <645d17210708310404pbea32eewb34f9e5a79f6fbd2@mail.gmail.com> On 31/08/2007, Axel Thimm wrote: > On Thu, Aug 30, 2007 at 12:17:44PM +0200, Jindrich Novy wrote: > > How about removing the prefix completely? Package description should be > > sufficient to figure out it ships a TeX related stuff and we don't have many of > > them currently. I see the only purpose of the prefix to avoid conficts with > > already existing packages, in that case (la)tex-* or suffix *-(la)tex is ok IMO. > > You'd have my vote for that. I find the overprefixing a bit > silly - next we'll have C-glibc. Prefixing should be used for > resolving ambiguous situations, not as a replacement for the Groups: > tag. > > Oh yes, the subject is just to catch reading eyes. Thing is, (la)tex add on packages are frequently named with rather generic names, and so there is a very real world need for a prefix, I would argue.... eg. preview, prosper, unicode, bytefield (all current tetex add-ons)... I could imagine other programs chosing these names too. It seems to be a fact that programmers lack originality in naming :) From ndbecker2 at gmail.com Fri Aug 31 12:07:52 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 31 Aug 2007 08:07:52 -0400 Subject: [Fedora-packaging] kernel mod package howto? Message-ID: I'm submitting blcr which builds a kernel mod. Where can I find info on packaging for kernel mods? Examples? From opensource at till.name Fri Aug 31 12:34:57 2007 From: opensource at till.name (Till Maas) Date: Fri, 31 Aug 2007 14:34:57 +0200 Subject: [Fedora-packaging] kernel mod package howto? In-Reply-To: References: Message-ID: <200708311434.58431.opensource@till.name> On Fr August 31 2007, Neal Becker wrote: > I'm submitting blcr which builds a kernel mod. Where can I find info on > packaging for kernel mods? Examples? You have to ask FESCO for permission, first. When you get permission, you can use the hints here: http://fedoraproject.org/wiki/Packaging/KernelModules Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Fri Aug 31 12:40:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 31 Aug 2007 14:40:22 +0200 Subject: [Fedora-packaging] kernel mod package howto? In-Reply-To: <200708311434.58431.opensource@till.name> References: <200708311434.58431.opensource@till.name> Message-ID: <46D80C36.10505@leemhuis.info> On 31.08.2007 14:34, Till Maas wrote: > On Fr August 31 2007, Neal Becker wrote: >> I'm submitting blcr which builds a kernel mod. Where can I find info on >> packaging for kernel mods? Examples? > You have to ask FESCO for permission, first. And I looks like FESCo will disallow kernel module packages soon completely -- http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal was on the agenda for yesterdays meeting, but was adjourned until next week. > When you get permission, you can > use the hints here: http://fedoraproject.org/wiki/Packaging/KernelModules I use the situation to bring up a question here that I asked on fedora-devel yesterday already: [...] - (partly a question for the Packaging committee as well) The current Kernel Module standard was not only meant for Fedora, but for RHEL also and a suggested one for 3rd party Fedora-repos as well. Are those still a goal? If not: will the stuff simply be removed from the Guidelines, to make them easier to read? [...] CU knurd From paul at city-fan.org Fri Aug 31 12:41:20 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 31 Aug 2007 13:41:20 +0100 Subject: [Fedora-packaging] kernel mod package howto? In-Reply-To: <200708311434.58431.opensource@till.name> References: <200708311434.58431.opensource@till.name> Message-ID: <46D80C70.8030101@city-fan.org> Till Maas wrote: > On Fr August 31 2007, Neal Becker wrote: >> I'm submitting blcr which builds a kernel mod. Where can I find info on >> packaging for kernel mods? Examples? > > You have to ask FESCO for permission, first. When you get permission, you can > use the hints here: http://fedoraproject.org/wiki/Packaging/KernelModules Bear in mind though that this is currently being discussed: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal Paul. From Axel.Thimm at ATrpms.net Fri Aug 31 17:28:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 31 Aug 2007 19:28:06 +0200 Subject: [Fedora-packaging] Re: kernel mod package howto? In-Reply-To: <46D80C36.10505@leemhuis.info> References: <200708311434.58431.opensource@till.name> <46D80C36.10505@leemhuis.info> Message-ID: <20070831172806.GJ16579@puariko.nirvana> On Fri, Aug 31, 2007 at 02:40:22PM +0200, Thorsten Leemhuis wrote: > I use the situation to bring up a question here that I asked on > fedora-devel yesterday already: > [...] > - (partly a question for the Packaging committee as well) The current > Kernel Module standard was not only meant for Fedora, but for RHEL also > and a suggested one for 3rd party Fedora-repos as well. Are those still > a goal? If not: will the stuff simply be removed from the Guidelines, to > make them easier to read? > [...] Remove kmod and introduce kmdl2? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Aug 31 17:38:56 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 31 Aug 2007 20:38:56 +0300 Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? In-Reply-To: <9650.192.54.193.51.1188552757.squirrel@rousalka.dyndns.org> References: <46D5172F.7010604@leemhuis.info> <46D79CE8.2040005@leemhuis.info> <9650.192.54.193.51.1188552757.squirrel@rousalka.dyndns.org> Message-ID: <200708312038.56593.ville.skytta@iki.fi> On Friday 31 August 2007, Nicolas Mailhot wrote: > Le Ven 31 ao?t 2007 06:45, Thorsten Leemhuis a ?crit : > > I noticed in between that is was something stupid on my side, but that > > doesn't matter much IMHO. The ScriptletSnippets IMHO and AFAIK should > > be > > adjusted to make sure the script for this or similar errors don't end > > with a errorlevel != 0 > > If this is a one-off or a very unusual failure, I don't see what for. > > We only ignore harmless common errors. No, we only accept non-zero scriptlet exit statuses *very* rarely, if ever. See the last two paragraphs of the Syntax chapter of http://fedoraproject.org/wiki/Packaging/ScriptletSnippets From notting at redhat.com Fri Aug 31 19:10:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 31 Aug 2007 15:10:59 -0400 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <46D6D031.7020504@redhat.com> References: <46D6D031.7020504@redhat.com> Message-ID: <20070831191059.GB31970@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > Open for comments/corrections/modifications... > > http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript # config: # pidfile: # processname: # probe: are all not used by anything; not sure we want to specify them. In fact, 'probe' dates back to *linuxconf*. Ick. Probably should explain that starting by default with 'Default-Start' is generally discouraged. [ "$NETWORKING" ] tests are crack and should be removed. /var/lock/subsys/$foo needs to match the init script name, not the daemon name. Bill From ndbecker2 at gmail.com Fri Aug 31 19:42:57 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 31 Aug 2007 15:42:57 -0400 Subject: [Fedora-packaging] Re: kernel mod package howto? References: <200708311434.58431.opensource@till.name> <46D80C36.10505@leemhuis.info> <20070831172806.GJ16579@puariko.nirvana> Message-ID: Axel Thimm wrote: > On Fri, Aug 31, 2007 at 02:40:22PM +0200, Thorsten Leemhuis wrote: >> I use the situation to bring up a question here that I asked on >> fedora-devel yesterday already: >> [...] >> - (partly a question for the Packaging committee as well) The current >> Kernel Module standard was not only meant for Fedora, but for RHEL also >> and a suggested one for 3rd party Fedora-repos as well. Are those still >> a goal? If not: will the stuff simply be removed from the Guidelines, to >> make them easier to read? >> [...] > > Remove kmod and introduce kmdl2? Pointer? (google kmdl2 doesn't lead anywhere) From Axel.Thimm at ATrpms.net Fri Aug 31 21:51:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 31 Aug 2007 23:51:46 +0200 Subject: [Fedora-packaging] Re: kernel mod package howto? In-Reply-To: References: <200708311434.58431.opensource@till.name> <46D80C36.10505@leemhuis.info> <20070831172806.GJ16579@puariko.nirvana> Message-ID: <20070831215146.GK16579@puariko.nirvana> On Fri, Aug 31, 2007 at 03:42:57PM -0400, Neal Becker wrote: > Axel Thimm wrote: > >> - (partly a question for the Packaging committee as well) The > >> current Kernel Module standard was not only meant for Fedora, but > >> for RHEL also and a suggested one for 3rd party Fedora-repos as > >> well. Are those still a goal? If not: will the stuff simply be > >> removed from the Guidelines, to make them easier to read? [...] > > > > Remove kmod and introduce kmdl2? > > Pointer? (google kmdl2 doesn't lead anywhere) It's the kmdl API with more encapsulated parts (e.g. even smaller specfiles) and a shifting helper package removing the neccessity of yum plugins and thus working the same on yum/apt/smart/any depsolver. There is also a dkmdl subsystem to make dkms users happy It's not yet released though as my real life has gotten in the way. But it's better than sliced bread, I'd dare compare it to peanut butter. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: