From pertusus at free.fr Sat Mar 3 00:22:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 Mar 2007 01:22:24 +0100 Subject: [Fedora-packaging] Re: Fonts scriptlet for CORE packages In-Reply-To: References: Message-ID: <20070303002224.GA12901@free.fr> On Fri, Mar 02, 2007 at 12:32:42PM +0530, Parag N(????) wrote: > > Do we need to have alternative scriptlet that includes above lines for > post section for fonts packages in CORE? I am not a specialist, but my findings is that it depends on the type of font. It could be different for bitmap fonts, type1 fonts and truetype fonts. I asked for more precise guidelines some time ago, but nobody was willing to answer. Now that it is more or less mandatory to be able to review core packages, hopefully things will be better. -- Pat From ml at deadbabylon.de Sun Mar 4 16:13:19 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 4 Mar 2007 17:13:19 +0100 Subject: [Fedora-packaging] Two different locale names in one package? Message-ID: <20070304171319.5da18a5b@localhost.localdomain> Hi. A few days ago I've taken over the package kerry due to AWOL of the former maintainer. Today I've tried to package the new version of kerry. But I've encountered a problem: The new package contains two different named locale files: kerry.mo and kcmbeagle.mo. In one package I could only use one %find_lang. One solution could be to split up the package. That's what I have done for now (kerry and kerry-kcontrol). But the normal package would miss some features when not installing the sub-package. But I don't think a require for kerry-kcontrol in kerry itself would be a good idea. What would be the best solution in this situation? Really splitting up the package? And if so, also putting a require for kerry-kcontrol in kerry? Or is there an option for %find_lang I don't know? I've uploaded the srpm and the spec so that you could have a look: http://www.deadbabylon.de/fedora/extras/kerry/ Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Mar 4 17:02:51 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 05 Mar 2007 02:02:51 +0900 Subject: [Fedora-packaging] Two different locale names in one package? In-Reply-To: <20070304171319.5da18a5b@localhost.localdomain> References: <20070304171319.5da18a5b@localhost.localdomain> Message-ID: <45EAFBBB.7060209@ioa.s.u-tokyo.ac.jp> Sebastian Vahl wrote: > Hi. > > The new package contains two > different named locale files: kerry.mo and kcmbeagle.mo. In one package > I could only use one %find_lang. > > What would be the best solution in this situation? Really splitting up > the package? And if so, also putting a require for kerry-kcontrol in > kerry? Or is there an option for %find_lang I don't know? > Wouldn't the following work? ---------------------------------------------- %find_lang %{name} %find_lang kcmbeagle cat kcmbeagle.lang >> %{name}.lang ---------------------------------------------- Mamoru From mr.ecik at gmail.com Sun Mar 4 17:09:41 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 4 Mar 2007 18:09:41 +0100 Subject: [Fedora-packaging] Two different locale names in one package? In-Reply-To: <45EAFBBB.7060209@ioa.s.u-tokyo.ac.jp> References: <20070304171319.5da18a5b@localhost.localdomain> <45EAFBBB.7060209@ioa.s.u-tokyo.ac.jp> Message-ID: <668bb39a0703040909q24c1709bia811c1a0420c12ad@mail.gmail.com> 2007/3/4, Mamoru Tasaka : > Wouldn't the following work? > ---------------------------------------------- > %find_lang %{name} > %find_lang kcmbeagle > cat kcmbeagle.lang >> %{name}.lang > ---------------------------------------------- This is what I proposed a few minutes ago ;-) -- Micha? Bentkowski mr.ecik at gmail.com From mr.ecik at gmail.com Sun Mar 4 16:56:52 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 4 Mar 2007 17:56:52 +0100 Subject: [Fedora-packaging] Two different locale names in one package? In-Reply-To: <20070304171319.5da18a5b@localhost.localdomain> References: <20070304171319.5da18a5b@localhost.localdomain> Message-ID: <668bb39a0703040856l43852804oede15fa2f0352586@mail.gmail.com> If you aren't going to split up the package, just use %find_lang twice and do `cat kcmbeagle.lang >> %{name}.lang` 2007/3/4, Sebastian Vahl : > Hi. > > A few days ago I've taken over the package kerry due to AWOL of the > former maintainer. Today I've tried to package the new version of > kerry. But I've encountered a problem: The new package contains two > different named locale files: kerry.mo and kcmbeagle.mo. In one package > I could only use one %find_lang. > One solution could be to split up the package. That's what I have done > for now (kerry and kerry-kcontrol). But the normal package would miss > some features when not installing the sub-package. But I don't think a > require for kerry-kcontrol in kerry itself would be a good idea. > > What would be the best solution in this situation? Really splitting up > the package? And if so, also putting a require for kerry-kcontrol in > kerry? Or is there an option for %find_lang I don't know? > > I've uploaded the srpm and the spec so that you could have a look: > http://www.deadbabylon.de/fedora/extras/kerry/ > > Sebastian > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > > -- Micha? Bentkowski mr.ecik at gmail.com From ml at deadbabylon.de Sun Mar 4 18:41:05 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 4 Mar 2007 19:41:05 +0100 Subject: [Fedora-packaging] Two different locale names in one package? In-Reply-To: <45EAFBBB.7060209@ioa.s.u-tokyo.ac.jp> References: <20070304171319.5da18a5b@localhost.localdomain> <45EAFBBB.7060209@ioa.s.u-tokyo.ac.jp> Message-ID: <20070304194105.2f1aac38@localhost.localdomain> Am Mon, 05 Mar 2007 02:02:51 +0900 schrieb Mamoru Tasaka : > Sebastian Vahl wrote: > > Hi. > > > > The new package contains two > > different named locale files: kerry.mo and kcmbeagle.mo. In one > > package I could only use one %find_lang. > > > > What would be the best solution in this situation? Really splitting > > up the package? And if so, also putting a require for > > kerry-kcontrol in kerry? Or is there an option for %find_lang I > > don't know? > > > > Wouldn't the following work? > ---------------------------------------------- > %find_lang %{name} > %find_lang kcmbeagle > cat kcmbeagle.lang >> %{name}.lang > ---------------------------------------------- > Works fine. Thanks! Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Mar 4 21:49:00 2007 From: opensource at till.name (Till Maas) Date: Sun, 04 Mar 2007 22:49:00 +0100 Subject: [Fedora-packaging] Permissions to edit Review / PackageGuidelines Message-ID: <200703042249.07581.opensource@till.name> Aloas, I just noticed that I can edit the Review and PackageGuidelines - is this intended or maybe a bug because of the wiki upgrade? I added a link to fedora-packaging list to ask questions and that static libraries must go into a -static subpackge into the ReviewGuidelines to sync them with the PackageGuidelines. But I am not really sure whether or not this was the right way to make this change... Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Mar 4 21:58:52 2007 From: opensource at till.name (Till Maas) Date: Sun, 04 Mar 2007 22:58:52 +0100 Subject: [Fedora-packaging] Reply-To on fedora-package-review list Message-ID: <200703042258.52688.opensource@till.name> Hiyas, the reply-to of messages on fedora-package-review is set to fedora-maintainers. I think that this list fits better, do you agree? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Mar 4 22:06:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Mar 2007 17:06:49 -0500 Subject: [Fedora-packaging] Reply-To on fedora-package-review list In-Reply-To: <200703042258.52688.opensource@till.name> References: <200703042258.52688.opensource@till.name> Message-ID: <200703041706.49612.jkeating@redhat.com> On Sunday 04 March 2007 16:58:52 Till Maas wrote: > Hiyas, > > the reply-to of messages on fedora-package-review is set to > fedora-maintainers. I think that this list fits better, do you agree? > > Regards, > Till Not really. -- Jesse Keating Release Engineer: Fedora -------------- 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 Mon Mar 5 05:29:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 Mar 2007 00:29:15 -0500 Subject: [Fedora-packaging] Two different locale names in one package? In-Reply-To: <20070304171319.5da18a5b@localhost.localdomain> References: <20070304171319.5da18a5b@localhost.localdomain> Message-ID: <1173072555.6968.2.camel@localhost.localdomain> On Sun, 2007-03-04 at 17:13 +0100, Sebastian Vahl wrote: > Hi. > > A few days ago I've taken over the package kerry due to AWOL of the > former maintainer. Today I've tried to package the new version of > kerry. But I've encountered a problem: The new package contains two > different named locale files: kerry.mo and kcmbeagle.mo. In one package > I could only use one %find_lang. > One solution could be to split up the package. That's what I have done > for now (kerry and kerry-kcontrol). But the normal package would miss > some features when not installing the sub-package. But I don't think a > require for kerry-kcontrol in kerry itself would be a good idea. > > What would be the best solution in this situation? Really splitting up > the package? And if so, also putting a require for kerry-kcontrol in > kerry? Or is there an option for %find_lang I don't know? > You can look at how the gtk2 package solves the same problem: %find_lang gtk20 %find_lang gtk20-properties cat gtk20.lang gtk20-properties.lang > all.lang From Axel.Thimm at ATrpms.net Mon Mar 5 11:19:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:19:32 +0100 Subject: [Fedora-packaging] Proposal to disallow %config* under /usr Message-ID: <20070305111932.GJ29562@neu.nirvana> Hi, there seems to be confusion on f-m about whether %config* files ahve a place in /usr or not. I think it is quite evident that FHS and stateless goals rather forbid any %config bits under /usr and wouldn't really need any explicit mentioning. But as this created a lengthy thread being refueled every now and then, and the same may happen in the future again, maybe that's worth a clarification in the guideline? /me hopes that the FPC will simply vote on that w/o creating another lengthy thread. -- 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 Mon Mar 5 11:58:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:58:51 +0100 Subject: [Fedora-packaging] Re: Proposal to disallow %config* under /usr In-Reply-To: <20070305111932.GJ29562@neu.nirvana> References: <20070305111932.GJ29562@neu.nirvana> Message-ID: <20070305115851.GM29562@neu.nirvana> On Mon, Mar 05, 2007 at 12:19:32PM +0100, Axel Thimm wrote: > there seems to be confusion on f-m about whether %config* files ahve a > place in /usr or not. I think it is quite evident that FHS and > stateless goals rather forbid any %config bits under /usr and wouldn't > really need any explicit mentioning. > > But as this created a lengthy thread being refueled every now and > then, and the same may happen in the future again, maybe that's worth > a clarification in the guideline? > > /me hopes that the FPC will simply vote on that w/o creating another > lengthy thread. Just to throw something in to vote upon: | Proposal: Append to the section "Configuration files" | | Don't use %config or %config(noreplace) under /usr. /usr is deemed | to not contain configuration files in Fedora. If your package needs | a config file under /usr for upstream reasons try for example to | move it to under /etc and place a symlink to it. +1 -- 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 opensource at till.name Mon Mar 5 13:48:22 2007 From: opensource at till.name (Till Maas) Date: Mon, 05 Mar 2007 14:48:22 +0100 Subject: [Fedora-packaging] License question - fastcgi / openmarket license Message-ID: <200703051448.35317.opensource@till.name> Hello, is this license ok for a fedora package? http://www.fastcgi.com/devkit/LICENSE.TERMS Regards, Till -------------- 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 Mon Mar 5 14:00:37 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Mar 2007 14:00:37 +0000 Subject: [Fedora-packaging] License question - fastcgi / openmarket license In-Reply-To: <200703051448.35317.opensource@till.name> References: <200703051448.35317.opensource@till.name> Message-ID: <45EC2285.6030800@city-fan.org> Till Maas wrote: > Hello, > > is this license ok for a fedora package? > > http://www.fastcgi.com/devkit/LICENSE.TERMS Looks very BSD-ish to me. Paul. From tcallawa at redhat.com Tue Mar 6 00:03:22 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Mar 2007 18:03:22 -0600 Subject: [Fedora-packaging] License question - fastcgi / openmarket license In-Reply-To: <45EC2285.6030800@city-fan.org> References: <200703051448.35317.opensource@till.name> <45EC2285.6030800@city-fan.org> Message-ID: <1173139402.1407.100.camel@localhost.localdomain> On Mon, 2007-03-05 at 14:00 +0000, Paul Howarth wrote: > Till Maas wrote: > > Hello, > > > > is this license ok for a fedora package? > > > > http://www.fastcgi.com/devkit/LICENSE.TERMS > > Looks very BSD-ish to me. It is modified BSD, fine for Fedora. ~spot From jeff at ocjtech.us Tue Mar 6 06:14:33 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 06 Mar 2007 00:14:33 -0600 Subject: [Fedora-packaging] IAXy Firmware Message-ID: <1173161673.4593.9.camel@lt21223.campus.dmacc.edu> Well, after a long time off, I'm back to working on packaging Asterisk, and I thought that I'd revisit my previous decision to exclude the IAXy firmware. The IAXy is a small networked device produced by Digium (the developers of Asterisk) to connect an analog phone to an Asterisk PBX[0]. It needs some firmware to operate that can be served up to an IAXy over the network by Asterisk. The IAXy firmware is included with the Asterisk tarball, the relevant section from the LICENSE file is this: contrib/firmware/iax/iaxy.bin: This file is Copyright (C) Digium, Inc. and is licensed for use with Digium IAXy hardware devices only. It can be distributed freely as long as the distribution is in the original form present in this package (not reformatted or modified). Based upon recent discussion regarding wireless firmware, it seems that it is permissible to package the IAXy firmware. Am I correct? Jeff [0] http://www.digium.com/en/products/hardware/s101i.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Mar 6 14:30:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Mar 2007 08:30:51 -0600 Subject: [Fedora-packaging] IAXy Firmware In-Reply-To: <1173161673.4593.9.camel@lt21223.campus.dmacc.edu> References: <1173161673.4593.9.camel@lt21223.campus.dmacc.edu> Message-ID: <45ED7B1B.8040802@math.unl.edu> Jeffrey C. Ollie wrote: > The IAXy firmware is included with the Asterisk > tarball, the relevant section from the LICENSE file is this: > > contrib/firmware/iax/iaxy.bin: > This file is Copyright (C) Digium, Inc. and is licensed for > use with Digium IAXy hardware devices only. It can be > distributed freely as long as the distribution is in the > original form present in this package (not reformatted or > modified). > > Based upon recent discussion regarding wireless firmware, it seems that > it is permissible to package the IAXy firmware. Am I correct? IMO, yes, all fedora requires (now) is redistributability. -- Rex From mr.ecik at gmail.com Wed Mar 7 17:48:01 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 7 Mar 2007 18:48:01 +0100 Subject: [Fedora-packaging] Desktop files guidelines Message-ID: <668bb39a0703070948t2af5e957vb5ba4dedb28b318e@mail.gmail.com> Hi! A few days ago one man filled a bug against my package [1] and he's written that openarena's menu entry is not HIG complaint [2]. There are some nice guidelines about how to make the basic integration within the user environment of desktop. It could be nice if we took it as a one of Fedora guidelines. What do you think? Links: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231088 [2] http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-tooltips -- Micha? Bentkowski mr.ecik at gmail.com From Axel.Thimm at ATrpms.net Thu Mar 8 22:01:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 23:01:02 +0100 Subject: [Fedora-packaging] %config on folder permissions? Message-ID: <20070308220102.GA20275@neu.nirvana> Does this work? See #231542 -- 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 a.badger at gmail.com Thu Mar 8 22:35:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Mar 2007 14:35:44 -0800 Subject: [Fedora-packaging] Daylight saving time Message-ID: <1173393344.3329.146.camel@localhost.localdomain> We've been adjusting our meeting time to account for daylight saving time but this year will be the first time that we're on the new US DST plan. So hours in the US and Europe will shift on different weekends. Do we want to shift meeting times this weekend or wait until Europe shifts? We're currently meeting at 17:00UTC so waiting until Europe shifts would make the interim meetings take place later in the day for people in the US. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Mar 8 23:18:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Mar 2007 18:18:16 -0500 Subject: [Fedora-packaging] Daylight saving time In-Reply-To: <1173393344.3329.146.camel@localhost.localdomain> References: <1173393344.3329.146.camel@localhost.localdomain> Message-ID: <200703081818.16369.jkeating@redhat.com> On Thursday 08 March 2007 17:35:44 Toshio Kuratomi wrote: > We've been adjusting our meeting time to account for daylight saving > time but this year will be the first time that we're on the new US DST > plan. ?So hours in the US and Europe will shift on different weekends. > > Do we want to shift meeting times this weekend or wait until Europe > shifts? ?We're currently meeting at 17:00UTC so waiting until Europe > shifts would make the interim meetings take place later in the day for > people in the US. I'd rather keep the meeting time in UTC and leave it at that, no adjustments. The side effect would be that I no longer have to skip lunch for the meeting in a week or so. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Mar 8 23:39:32 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Mar 2007 15:39:32 -0800 Subject: [Fedora-packaging] Daylight saving time In-Reply-To: <200703081818.16369.jkeating@redhat.com> References: <1173393344.3329.146.camel@localhost.localdomain> <200703081818.16369.jkeating@redhat.com> Message-ID: <1173397172.3329.156.camel@localhost.localdomain> On Thu, 2007-03-08 at 18:18 -0500, Jesse Keating wrote: > On Thursday 08 March 2007 17:35:44 Toshio Kuratomi wrote: > > We've been adjusting our meeting time to account for daylight saving > > time but this year will be the first time that we're on the new US DST > > plan. So hours in the US and Europe will shift on different weekends. > > > > Do we want to shift meeting times this weekend or wait until Europe > > shifts? We're currently meeting at 17:00UTC so waiting until Europe > > shifts would make the interim meetings take place later in the day for > > people in the US. > > I'd rather keep the meeting time in UTC and leave it at that, no adjustments. > The side effect would be that I no longer have to skip lunch for the meeting > in a week or so. That would be fine for me as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Thu Mar 8 23:49:58 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 08 Mar 2007 16:49:58 -0700 Subject: [Fedora-packaging] Temporarily removing a sub-package Message-ID: <45F0A126.9080703@cora.nwra.com> I'm looking to remove the -mpi subpackage of paraview because it does not build. I've poked upstream to no avail, and I haven't been able to figure out the problem myself. If this gets fixed, I'd like to add it back. In the meantime, what kind of Provides/Obsoletes makes sense? Provides: paraview-mpi Obsoletes: paraview-mpi < %{version}-%{release} ? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Fri Mar 9 01:01:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Mar 2007 19:01:22 -0600 Subject: [Fedora-packaging] Temporarily removing a sub-package In-Reply-To: <45F0A126.9080703@cora.nwra.com> References: <45F0A126.9080703@cora.nwra.com> Message-ID: <45F0B1E2.4080309@math.unl.edu> Orion Poplawski wrote: > I'm looking to remove the -mpi subpackage of paraview because it does > not build. I've poked upstream to no avail, and I haven't been able to > figure out the problem myself. If this gets fixed, I'd like to add it > back. > > In the meantime, what kind of Provides/Obsoletes makes sense? > > Provides: paraview-mpi > Obsoletes: paraview-mpi < %{version}-%{release} imo, if the mpi functionality is missing, you should omit the Provides. -- Rex From dlutter at redhat.com Fri Mar 9 01:47:28 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 08 Mar 2007 17:47:28 -0800 Subject: [Fedora-packaging] Packaging of ruby gems Message-ID: <1173404848.3331.53.camel@localhost.localdomain> At long last, I wrote up a guideline [1] for packaging ruby gems, ruby's own packaging format; since almost any ruby library is packaged as a gem, and some of them provide no other way of installation, it becomes increasingly important to enable packaging of gems for Fedora. At the same time, it is fairly easy to automate most of this process[2], which hopefully means that lots of people will submit packages of ruby gems. You can find some examples of ruby gems packaged as rpm's on my people page [3] - look for specfiles called 'rubygem-*' David [1] http://fedoraproject.org/wiki/PackagingDrafts/RubyGems [2] http://people.redhat.com/dlutter/gem2spec.html [3] http://people.redhat.com/dlutter/yum/spec/ From mharris at mharris.ca Fri Mar 9 06:08:11 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 09 Mar 2007 01:08:11 -0500 Subject: [Fedora-packaging] Re: Temporarily removing a sub-package In-Reply-To: <45F0A126.9080703@cora.nwra.com> References: <45F0A126.9080703@cora.nwra.com> Message-ID: <45F0F9CB.3050502@mharris.ca> Orion Poplawski wrote: > I'm looking to remove the -mpi subpackage of paraview because it does > not build. I've poked upstream to no avail, and I haven't been able to > figure out the problem myself. If this gets fixed, I'd like to add it > back. > > In the meantime, what kind of Provides/Obsoletes makes sense? > > Provides: paraview-mpi > Obsoletes: paraview-mpi < %{version}-%{release} If the functionality of the -mpi subpackage is not going to be provided at all (temporarily or otherwise), then neither. Use an rpm macro to include/exclude the package: %define with_mpi 0 Then wrap all areas of the spec file that concern the generation of mpi functionality, installation, packaging, file manifest, etc. with "%if %{with_mpi}" or "%if ! %{with_mpi}" checks as appropriate. Having package contain Provides/Obsoletes for a previous subpackage which provides some actual functionality, but which is not present due to being disabled, means that software which requires the functionality is lied to, and dependency resolution is tricked into working, but there are runtime software failures or similar. Not the correct way to go. From orion at cora.nwra.com Fri Mar 9 18:26:51 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 09 Mar 2007 11:26:51 -0700 Subject: [Fedora-packaging] Re: Temporarily removing a sub-package In-Reply-To: <45F0F9CB.3050502@mharris.ca> References: <45F0A126.9080703@cora.nwra.com> <45F0F9CB.3050502@mharris.ca> Message-ID: <45F1A6EB.20800@cora.nwra.com> Mike A. Harris wrote: > > If the functionality of the -mpi subpackage is not going to > be provided at all (temporarily or otherwise), then neither. > > Use an rpm macro to include/exclude the package: > > %define with_mpi 0 > > Then wrap all areas of the spec file that concern the generation > of mpi functionality, installation, packaging, file manifest, etc. > with "%if %{with_mpi}" or "%if ! %{with_mpi}" checks as appropriate. > Did that already, thanks. > Having package contain Provides/Obsoletes for a previous subpackage > which provides some actual functionality, but which is not present > due to being disabled, means that software which requires the > functionality is lied to, and dependency resolution is tricked into > working, but there are runtime software failures or similar. > > Not the correct way to go. Okay. Is there any concern about old paraview-mpi packages being stranded, in case this can't be fixed by F7 release (or freeze)? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Fri Mar 9 18:31:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Mar 2007 12:31:14 -0600 Subject: [Fedora-packaging] Re: Temporarily removing a sub-package In-Reply-To: <45F1A6EB.20800@cora.nwra.com> References: <45F0A126.9080703@cora.nwra.com> <45F0F9CB.3050502@mharris.ca> <45F1A6EB.20800@cora.nwra.com> Message-ID: <45F1A7F2.8060103@math.unl.edu> Orion Poplawski wrote: > Mike A. Harris wrote: >> Having package contain Provides/Obsoletes for a previous subpackage >> which provides some actual functionality, but which is not present >> due to being disabled, means that software which requires the >> functionality is lied to, and dependency resolution is tricked into >> working, but there are runtime software failures or similar. It's only a lie if a false Provides is added, imo. > Okay. Is there any concern about old paraview-mpi packages being > stranded, in case this can't be fixed by F7 release (or freeze)? Yes, a problem, which is why I recommended using Obsoletes, but not Provides. Without out, users with it currently installed may/will soon end up with dependency problems. -- Rex From ville.skytta at iki.fi Sat Mar 10 10:57:54 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 10 Mar 2007 12:57:54 +0200 Subject: [Fedora-packaging] perl-* build dependencies Message-ID: <200703101257.55695.ville.skytta@iki.fi> Hello, Whether the perl/perl-devel split in devel (#226276) is here to stay or not, I'd like to make the attached change to the rpmdevtools perl spec template. Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in the vast majority of cases, no matter in which package ExtUtils::MakeMaker is included. Packages using Module::Build should change the dep to perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's needed for Module::Build's non-compat mode. Doing the build dep this way should work for all distro versions as-is without the need to put ugly conditionals on whether to pull in perl-devel or not or whatever other perl package reorganizations we might see in the future. I see some packagers have already started to make those unnecessary specfile complications/per-distro forks so it'd be good to have this in the spec template as well as applicable Wiki pages as soon as possible. Comments, objections? -------------- next part -------------- A non-text attachment was scrubbed... Name: perlspec.patch Type: text/x-diff Size: 700 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 11:15:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 12:15:38 +0100 Subject: [Fedora-packaging] Re: perl-* build dependencies In-Reply-To: <200703101257.55695.ville.skytta@iki.fi> References: <200703101257.55695.ville.skytta@iki.fi> Message-ID: <20070310111538.GE20977@neu.nirvana> On Sat, Mar 10, 2007 at 12:57:54PM +0200, Ville Skytt? wrote: > Hello, > > Whether the perl/perl-devel split in devel (#226276) is here to stay or not, > I'd like to make the attached change to the rpmdevtools perl spec template. > > Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in > the vast majority of cases, no matter in which package ExtUtils::MakeMaker is > included. Packages using Module::Build should change the dep to > perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's > needed for Module::Build's non-compat mode. > > Doing the build dep this way should work for all distro versions as-is without > the need to put ugly conditionals on whether to pull in perl-devel or not or > whatever other perl package reorganizations we might see in the > future. Good idea! > I see some packagers have already started to make those unnecessary > specfile complications/per-distro forks so it'd be good to have this > in the spec template as well as applicable Wiki pages as soon as > possible. > > Comments, objections? Even if it seems (technically) redunant, I would recommend to leave the explicit perl dependency in it, as a documentation/educational entity. > Index: spectemplate-perl.spec > =================================================================== > RCS file: /cvs/fedora/fedora-rpmdevtools/spectemplate-perl.spec,v > retrieving revision 1.14 > diff -u -r1.14 spectemplate-perl.spec > --- spectemplate-perl.spec 20 Jul 2006 17:46:34 -0000 1.14 > +++ spectemplate-perl.spec 10 Mar 2007 10:52:17 -0000 > @@ -10,7 +10,8 @@ > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > BuildArch: > -BuildRequires: perl > +# Correct for lots of packages, other common choices include eg. Module::Build > +BuildRequires: perl(ExtUtils::MakeMaker) > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) > > %description -- 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 cweyl at alumni.drew.edu Sun Mar 11 05:24:44 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 10 Mar 2007 21:24:44 -0800 Subject: [Fedora-packaging] perl-* build dependencies In-Reply-To: <200703101257.55695.ville.skytta@iki.fi> References: <200703101257.55695.ville.skytta@iki.fi> Message-ID: <7dd7ab490703102124m48c39bc8x17932ce419ffdbad@mail.gmail.com> On 3/10/07, Ville Skytt? wrote: > Whether the perl/perl-devel split in devel (#226276) is here to stay or not, > I'd like to make the attached change to the rpmdevtools perl spec template. > > Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in > the vast majority of cases, no matter in which package ExtUtils::MakeMaker is > included. Packages using Module::Build should change the dep to > perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's > needed for Module::Build's non-compat mode. [...] > Comments, objections? +1. Spec conditionals tend to hurt my brain :) -Chris -- Chris Weyl Ex astris, scientia From cweyl at alumni.drew.edu Sun Mar 11 05:26:46 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 10 Mar 2007 21:26:46 -0800 Subject: [Fedora-packaging] perl-* build dependencies In-Reply-To: <7dd7ab490703102124m48c39bc8x17932ce419ffdbad@mail.gmail.com> References: <200703101257.55695.ville.skytta@iki.fi> <7dd7ab490703102124m48c39bc8x17932ce419ffdbad@mail.gmail.com> Message-ID: <7dd7ab490703102126y6841c103ue74586ff1d8fb43@mail.gmail.com> On 3/10/07, Chris Weyl wrote: > +1. Spec conditionals tend to hurt my brain :) Not that I can vote here. That's just my rabble "nod of agreement." :) -Chris -- Chris Weyl Ex astris, scientia From steve at silug.org Sun Mar 11 19:59:00 2007 From: steve at silug.org (Steven Pritchard) Date: Sun, 11 Mar 2007 14:59:00 -0500 Subject: [Fedora-packaging] perl-* build dependencies In-Reply-To: <200703101257.55695.ville.skytta@iki.fi> References: <200703101257.55695.ville.skytta@iki.fi> Message-ID: <20070311195900.GA29754@osiris.silug.org> On Sat, Mar 10, 2007 at 12:57:54PM +0200, Ville Skytt? wrote: > Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in > the vast majority of cases, no matter in which package ExtUtils::MakeMaker is > included. Not that I get a vote, but +1. I'll be making the same change to cpanspec unless I hear otherwise... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From paul at city-fan.org Mon Mar 12 08:22:43 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Mar 2007 08:22:43 +0000 Subject: [Fedora-packaging] perl-* build dependencies In-Reply-To: <200703101257.55695.ville.skytta@iki.fi> References: <200703101257.55695.ville.skytta@iki.fi> Message-ID: <1173687763.6256.0.camel@metropolis.intra.city-fan.org> On Sat, 2007-03-10 at 12:57 +0200, Ville Skytt? wrote: > Hello, > > Whether the perl/perl-devel split in devel (#226276) is here to stay or not, > I'd like to make the attached change to the rpmdevtools perl spec template. > > Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in > the vast majority of cases, no matter in which package ExtUtils::MakeMaker is > included. Packages using Module::Build should change the dep to > perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's > needed for Module::Build's non-compat mode. > > Doing the build dep this way should work for all distro versions as-is without > the need to put ugly conditionals on whether to pull in perl-devel or not or > whatever other perl package reorganizations we might see in the future. I > see some packagers have already started to make those unnecessary specfile > complications/per-distro forks so it'd be good to have this in the spec > template as well as applicable Wiki pages as soon as possible. > > Comments, objections? No objection in principle but this should probably wait until Bug #231549 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549) is resolved. Paul. From opensource at till.name Mon Mar 12 20:29:44 2007 From: opensource at till.name (Till Maas) Date: Mon, 12 Mar 2007 21:29:44 +0100 Subject: [Fedora-packaging] buildroot race condition Message-ID: <200703122129.54677.opensource@till.name> Hello, an OpenSUSE packager made me aware of a race condition problem with a lot of fedora specs: http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html A lot of specs and the template specs from rpmdev-newspec use following: %install rm -rf $RPM_BUILD_ROOT # racing time mkdir -p $RPM_BUILD_ROOT/bla/foo The solution is to make the following mandatory: %install rm -rf $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 12 20:33:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Mar 2007 15:33:10 -0500 Subject: [Fedora-packaging] buildroot race condition In-Reply-To: <200703122129.54677.opensource@till.name> References: <200703122129.54677.opensource@till.name> Message-ID: <45F5B906.6090305@math.unl.edu> Till Maas wrote: > Hello, > > an OpenSUSE packager made me aware of a race condition problem with a lot of > fedora specs: > > http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html > > A lot of specs and the template specs from rpmdev-newspec use following: > > %install > rm -rf $RPM_BUILD_ROOT > # racing time How is that a race exactly? rm doesn't exit/return until it is done, afaik. -- Rex From notting at redhat.com Mon Mar 12 20:30:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Mar 2007 16:30:55 -0400 Subject: [Fedora-packaging] buildroot race condition In-Reply-To: <45F5B906.6090305@math.unl.edu> References: <200703122129.54677.opensource@till.name> <45F5B906.6090305@math.unl.edu> Message-ID: <20070312203055.GB32743@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > How is that a race exactly? rm doesn't exit/return until it is done, afaik. Someone could pre-make the build root in between the rm and mkdir calls. Bill From tcallawa at redhat.com Mon Mar 12 21:05:58 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Mar 2007 16:05:58 -0500 Subject: [Fedora-packaging] buildroot race condition In-Reply-To: <20070312203055.GB32743@nostromo.devel.redhat.com> References: <200703122129.54677.opensource@till.name> <45F5B906.6090305@math.unl.edu> <20070312203055.GB32743@nostromo.devel.redhat.com> Message-ID: <1173733558.25122.28.camel@localhost.localdomain> On Mon, 2007-03-12 at 16:30 -0400, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > How is that a race exactly? rm doesn't exit/return until it is done, afaik. > > Someone could pre-make the build root in between the rm and mkdir calls. Erm, ok. In the buildsystem, this should never happen (hooray mock), but when building on a multi-user system, I can see the remote possibility. However, we're talking about someone performing an operation in a very tiny gap. It's just as likely that they would manually replace files at any point in the process, or to argue that someone might rm -rf $RPM_BUILD_ROOT behind my back. Basically, what I'm saying is that this "race" is so unlikely, I don't think we need to bother to go out of our way to prevent it. It would be far easier for an attacker to leverage wildcarding in %files while a package is building, wait for it to perform make install, then slide in their malicious bits. ~spot From opensource at till.name Mon Mar 12 21:20:22 2007 From: opensource at till.name (Till Maas) Date: Mon, 12 Mar 2007 22:20:22 +0100 Subject: [Fedora-packaging] buildroot race condition In-Reply-To: <1173733558.25122.28.camel@localhost.localdomain> References: <200703122129.54677.opensource@till.name> <20070312203055.GB32743@nostromo.devel.redhat.com> <1173733558.25122.28.camel@localhost.localdomain> Message-ID: <200703122220.35405.opensource@till.name> On Mo M?rz 12 2007, Tom 'spot' Callaway wrote: > However, we're talking about someone performing an operation in a very > tiny gap. It's just as likely that they would manually replace files at This can be easily automated, > any point in the process, or to argue that someone might rm -rf > $RPM_BUILD_ROOT behind my back. while this normally is not possible with correct/normal file permissions. > Basically, what I'm saying is that this "race" is so unlikely, I don't > think we need to bother to go out of our way to prevent it. The fix is very easy, just add one line with mkdir. > It would be far easier for an attacker to leverage wildcarding in %files > while a package is building, wait for it to perform make install, then > slide in their malicious bits. This is also not possible with normal file permissions, Regards, Till -------------- 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 Mon Mar 12 22:19:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 12 Mar 2007 23:19:30 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <1173733558.25122.28.camel@localhost.localdomain> References: <200703122129.54677.opensource@till.name> <45F5B906.6090305@math.unl.edu> <20070312203055.GB32743@nostromo.devel.redhat.com> <1173733558.25122.28.camel@localhost.localdomain> Message-ID: <20070312221930.GF4363@neu.nirvana> On Mon, Mar 12, 2007 at 04:05:58PM -0500, Tom 'spot' Callaway wrote: > On Mon, 2007-03-12 at 16:30 -0400, Bill Nottingham wrote: > > Rex Dieter (rdieter at math.unl.edu) said: > > > How is that a race exactly? rm doesn't exit/return until it is done, afaik. > > > > Someone could pre-make the build root in between the rm and mkdir calls. > > Erm, ok. In the buildsystem, this should never happen (hooray mock), but > when building on a multi-user system, I can see the remote possibility. Hey, our new preferred buildroot makes it even harder to guess the Buildroot name, hooray2 ;) > It would be far easier for an attacker to leverage wildcarding in %files > while a package is building, wait for it to perform make install, then > slide in their malicious bits. How would the attacker do that if the buildroot belongs to another user? -- 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 petersen at redhat.com Tue Mar 13 02:31:06 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 13 Mar 2007 12:31:06 +1000 Subject: [Fedora-packaging] legal guidelines for new fonts? Message-ID: <45F60CEA.8050308@redhat.com> Hi, Would it be a good idea to add a page under Packaging describing basic legal requirements for new fonts being added to Fedora? Typically it is a good idea to contact the original authors and the maintainers of fonts to ascertain the origin and ownership of the design as part of the review process. I think this is something that we should consider making mandatory for all new fonts packages. Jens From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 13 08:05:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 13 Mar 2007 09:05:05 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <1173733558.25122.28.camel@localhost.localdomain> (Tom Callaway's message of "Mon, 12 Mar 2007 16:05:58 -0500") References: <200703122129.54677.opensource@till.name> <45F5B906.6090305@math.unl.edu> <20070312203055.GB32743@nostromo.devel.redhat.com> <1173733558.25122.28.camel@localhost.localdomain> Message-ID: <873b49zhzi.fsf@kosh.bigo.ensc.de> "Tom 'spot' Callaway" writes: >> Someone could pre-make the build root in between the rm and mkdir >> calls. > > Erm, ok. In the buildsystem, this should never happen (hooray mock), but > when building on a multi-user system, I can see the remote possibility. > However, we're talking about someone performing an operation in a very > tiny gap. No; should be trivial to exploit with: $ create-big-load & $ d=/var/tmp/foo-package-root-512 $ while test ! -e "$d"/bin/prog; do rm -rf "$d"; mkdir -m0777 -p "$d"/bin; done; \ rm -f "$d/bin/prog"; cp -a my-backdoored-prog "$d/bin/prog" [ the while-loop should be implemented in C ] Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 13 08:13:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 13 Mar 2007 09:13:05 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <200703122129.54677.opensource@till.name> (Till Maas's message of "Mon, 12 Mar 2007 21:29:44 +0100") References: <200703122129.54677.opensource@till.name> Message-ID: <871wjtzhm6.fsf@kosh.bigo.ensc.de> Till Maas writes: > an OpenSUSE packager made me aware of a race condition problem with a > lot of fedora specs: > > http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html Was brought up already when $RPM_BUILD_ROOT was discussed.... > The solution is to make the following mandatory: > %install > rm -rf $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists Will work; another solution would be to use a secure %_tmpdir (which is write and perhaps readable by the packager only). Packagers have to setup %_topdir already so this should happen for %_tmpdir too. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 13 10:14:49 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 13 Mar 2007 11:14:49 +0100 Subject: [Fedora-packaging] buildroot race condition In-Reply-To: <200703122129.54677.opensource@till.name> References: <200703122129.54677.opensource@till.name> Message-ID: <20070313111449.6977fd16@python3.es.egwn.lan> Till Maas wrote : > A lot of specs and the template specs from rpmdev-newspec use following: > > %install > rm -rf $RPM_BUILD_ROOT > # racing time > mkdir -p $RPM_BUILD_ROOT/bla/foo > > The solution is to make the following mandatory: > %install > rm -rf $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists Other solutions : - Use mach or mock - Use a _tmppath inside your $HOME (thus buildroot will be too) We all do one or the other, or even both, right? :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.07 0.20 0.32 From rdieter at math.unl.edu Tue Mar 13 18:05:48 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 13:05:48 -0500 Subject: [Fedora-packaging] cmake rpm macro(s): Message-ID: <45F6E7FC.3000605@math.unl.edu> Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r). Made each cmake option a separate macro to make in easier to override. Comments? -- Rex ################################# ## /etc/rpm/macros.cmake: %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %{_bindir}/cmake \\\ %{?_cmake_install_prefix} \\\ %{?_cmake_build_shared_libs} \\\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\\ %endif \ ###############################3# From rc040203 at freenet.de Tue Mar 13 18:38:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Mar 2007 19:38:01 +0100 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <45F6E7FC.3000605@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> Message-ID: <1173811082.4680.6.camel@mccallum.corsepiu.local> On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote: > Appended is a first try at rpm macro'izing the the call to cmake per: > http://fedoraproject.org/wiki/PackagingDrafts/cmake > > I chose not to implement the out-of-tree style of build in the > PackagingDraft to keep things simple(r). > > Made each cmake option a separate macro to make in easier to override. > > Comments? 1) This proposal doesn't handle %{_*dir}'s but _prefix I.e. it will break when any of them changes. 2) I don't like macros, once they have been introduced, you hardly can get rid of them. Ralf From rdieter at math.unl.edu Tue Mar 13 18:42:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 13:42:30 -0500 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <1173811082.4680.6.camel@mccallum.corsepiu.local> References: <45F6E7FC.3000605@math.unl.edu> <1173811082.4680.6.camel@mccallum.corsepiu.local> Message-ID: <45F6F096.10804@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote: >> Appended is a first try at rpm macro'izing the the call to cmake per: >> http://fedoraproject.org/wiki/PackagingDrafts/cmake >> >> I chose not to implement the out-of-tree style of build in the >> PackagingDraft to keep things simple(r). >> >> Made each cmake option a separate macro to make in easier to override. >> >> Comments? > 1) This proposal doesn't handle %{_*dir}'s but _prefix > I.e. it will break when any of them changes. cmake doesn't use those other rpm macros anyway, so this proposal doesn't help/harm that. (: -- Rex From rc040203 at freenet.de Tue Mar 13 18:43:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Mar 2007 19:43:46 +0100 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <45F6F096.10804@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> <1173811082.4680.6.camel@mccallum.corsepiu.local> <45F6F096.10804@math.unl.edu> Message-ID: <1173811427.4680.8.camel@mccallum.corsepiu.local> On Tue, 2007-03-13 at 13:42 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote: > >> Appended is a first try at rpm macro'izing the the call to cmake per: > >> http://fedoraproject.org/wiki/PackagingDrafts/cmake > >> > >> I chose not to implement the out-of-tree style of build in the > >> PackagingDraft to keep things simple(r). > >> > >> Made each cmake option a separate macro to make in easier to override. > >> > >> Comments? > > 1) This proposal doesn't handle %{_*dir}'s but _prefix > > I.e. it will break when any of them changes. > > cmake doesn't use those other rpm macros anyway, so this proposal > doesn't help/harm that. (: Yes, cmake is imake in new clothes: Hardcoded inflexibility ;) Ralf From rdieter at math.unl.edu Tue Mar 13 19:11:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 14:11:41 -0500 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <45F6E7FC.3000605@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> Message-ID: <45F6F76D.7050602@math.unl.edu> Rex Dieter wrote: > Appended is a first try at rpm macro'izing the the call to cmake per: > http://fedoraproject.org/wiki/PackagingDrafts/cmake > > I chose not to implement the out-of-tree style of build in the > PackagingDraft to keep things simple(r). Updated PackagingDrafts/cmake to include proposed macro. -- Rex From orion at cora.nwra.com Tue Mar 13 20:09:37 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 13 Mar 2007 14:09:37 -0600 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <45F6F76D.7050602@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> <45F6F76D.7050602@math.unl.edu> Message-ID: <45F70501.5000002@cora.nwra.com> Rex Dieter wrote: > Rex Dieter wrote: >> Appended is a first try at rpm macro'izing the the call to cmake per: >> http://fedoraproject.org/wiki/PackagingDrafts/cmake >> >> I chose not to implement the out-of-tree style of build in the >> PackagingDraft to keep things simple(r). > > Updated PackagingDrafts/cmake to include proposed macro. > First off, your macro doesn't specify any source directory, which you must. That's actually good, because then you can do: %cmake And it keeps the macro usage the same as the command usage. I think you have to support out of tree builds as many projects actually don't support in tree builds (specifically, paraview). The question then becomes sub-dir or parallel-dir? %build cd .. mkdir fedora cd fedora %cmake ../package- or %build mkdir fedora cd fedora %cmake .. I'm not really sure there is a difference, but I've seen both in instructions from packages using cmake. I'll bring it up on the cmake list. The latter seems easier for building RPMS, and possibly required due to filesystem collision (unless you do something like mkdir package--fedora). Also, paraview gets built twice with different options in different dirs. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Tue Mar 13 20:14:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Mar 2007 21:14:26 +0100 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <45F6E7FC.3000605@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> Message-ID: <20070313201426.GI10782@neu.nirvana> Hi, On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote: > Appended is a first try at rpm macro'izing the the call to cmake per: > http://fedoraproject.org/wiki/PackagingDrafts/cmake > > I chose not to implement the out-of-tree style of build in the > PackagingDraft to keep things simple(r). > > Made each cmake option a separate macro to make in easier to override. > > Comments? do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros. > -- Rex > > ################################# > ## /etc/rpm/macros.cmake: > > %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON > %_cmake_lib_suffix64 -DLIB_SUFFIX=64 > > %cmake \ > CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ > CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ > FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ > %{_bindir}/cmake \\\ > %{?_cmake_install_prefix} \\\ > %{?_cmake_build_shared_libs} \\\ > %if "%{?_lib}" == "lib64" \ > %{?_cmake_lib_suffix64} \\\ > %endif \ > > ###############################3# > -- 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 rdieter at math.unl.edu Tue Mar 13 20:15:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 15:15:45 -0500 Subject: [Fedora-packaging] cmake rpm macro(s): In-Reply-To: <45F70501.5000002@cora.nwra.com> References: <45F6E7FC.3000605@math.unl.edu> <45F6F76D.7050602@math.unl.edu> <45F70501.5000002@cora.nwra.com> Message-ID: <45F70671.6010209@math.unl.edu> Orion Poplawski wrote: > Rex Dieter wrote: >> Rex Dieter wrote: >>> Appended is a first try at rpm macro'izing the the call to cmake per: >>> http://fedoraproject.org/wiki/PackagingDrafts/cmake >>> >>> I chose not to implement the out-of-tree style of build in the >>> PackagingDraft to keep things simple(r). >> >> Updated PackagingDrafts/cmake to include proposed macro. >> > > First off, your macro doesn't specify any source directory, which you > must. That's actually good, because then you can do: > > %cmake > > And it keeps the macro usage the same as the command usage. > > I think you have to support out of tree builds as many projects actually > don't support in tree builds (specifically, paraview). The question > then becomes sub-dir or parallel-dir? Well, I wasn't aware of in-tree problems, so my first draft left out the details wrt out-of-tree builds. Certainly the macros shouldn't touch which dir to use, leave that to users and specfiles. -- Rex From rdieter at math.unl.edu Tue Mar 13 20:18:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 15:18:30 -0500 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <20070313201426.GI10782@neu.nirvana> References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> Message-ID: <45F70716.1050108@math.unl.edu> Axel Thimm wrote: > Hi, > > On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote: >> Appended is a first try at rpm macro'izing the the call to cmake per: >> http://fedoraproject.org/wiki/PackagingDrafts/cmake >> >> I chose not to implement the out-of-tree style of build in the >> PackagingDraft to keep things simple(r). >> >> Made each cmake option a separate macro to make in easier to override. >> >> Comments? > > do you need the _cmake_* macros for other things? If not, I would > simply write the values into the %cmake macros. Using _cmake_* macros allows for users to easily override/change individual items, if needed. -- Rex From ville.skytta at iki.fi Tue Mar 13 20:35:40 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 13 Mar 2007 22:35:40 +0200 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <45F70716.1050108@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> Message-ID: <200703132235.40669.ville.skytta@iki.fi> On Tuesday 13 March 2007, Rex Dieter wrote: > Using _cmake_* macros allows for users to easily override/change > individual items, if needed. Following this path, the cmake command should probably be macroized too instead of hardcoding it to %{_bindir}/cmake. From opensource at till.name Tue Mar 13 20:35:16 2007 From: opensource at till.name (Till Maas) Date: Tue, 13 Mar 2007 21:35:16 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <20070312221930.GF4363@neu.nirvana> References: <200703122129.54677.opensource@till.name> <1173733558.25122.28.camel@localhost.localdomain> <20070312221930.GF4363@neu.nirvana> Message-ID: <200703132135.36547.opensource@till.name> On Mo M?rz 12 2007, Axel Thimm wrote: > On Mon, Mar 12, 2007 at 04:05:58PM -0500, Tom 'spot' Callaway wrote: > > Erm, ok. In the buildsystem, this should never happen (hooray mock), but > > when building on a multi-user system, I can see the remote possibility. > > Hey, our new preferred buildroot makes it even harder to guess the > Buildroot name, hooray2 ;) Does "grep RPM_BUILD_ROOT= /var/tmp/rpm-tmp.*" not work with the preferred buildroot? Regards, Till -------------- 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 Mar 13 20:37:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Mar 2007 21:37:11 +0100 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <45F70716.1050108@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> Message-ID: <20070313203711.GA24460@neu.nirvana> On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote: > Axel Thimm wrote: > >Hi, > > > >On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote: > >>Appended is a first try at rpm macro'izing the the call to cmake per: > >>http://fedoraproject.org/wiki/PackagingDrafts/cmake > >> > >>I chose not to implement the out-of-tree style of build in the > >>PackagingDraft to keep things simple(r). > >> > >>Made each cmake option a separate macro to make in easier to override. > >> > >>Comments? > > > >do you need the _cmake_* macros for other things? If not, I would > >simply write the values into the %cmake macros. > > > %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > > %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON > > %_cmake_lib_suffix64 -DLIB_SUFFIX=64 > > Using _cmake_* macros allows for users to easily override/change > individual items, if needed. What would one override? They are already generic enough. If they really need changing then cmake will have changed so much that the %cmake macro would also not be valid anymore. E.g. it would be like building %configure on blocks like %_configure_bindir --bindir=%{_bindir} -- 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 Tue Mar 13 20:51:09 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 13 Mar 2007 22:51:09 +0200 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <871wjtzhm6.fsf@kosh.bigo.ensc.de> References: <200703122129.54677.opensource@till.name> <871wjtzhm6.fsf@kosh.bigo.ensc.de> Message-ID: <200703132251.10847.ville.skytta@iki.fi> On Tuesday 13 March 2007, Enrico Scholz wrote: > > > The solution is to make the following mandatory: > > %install > > rm -rf $RPM_BUILD_ROOT > > mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists > > Will work; ...but will break in setups where some subdirs of $RPM_BUILD_ROOT are missing before %install. This wouldn't suffer from that drawback: %install rm -rf $RPM_BUILD_ROOT mkdir -p $(dirname $RPM_BUILD_ROOT) ; mkdir $RPM_BUILD_ROOT From rdieter at math.unl.edu Tue Mar 13 20:55:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 15:55:42 -0500 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <20070313203711.GA24460@neu.nirvana> References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> Message-ID: <45F70FCE.4080507@math.unl.edu> Axel Thimm wrote: > On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote: >> Axel Thimm wrote: >>> Hi, >>> >>> On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote: >>>> Appended is a first try at rpm macro'izing the the call to cmake per: >>>> http://fedoraproject.org/wiki/PackagingDrafts/cmake >>>> >>>> I chose not to implement the out-of-tree style of build in the >>>> PackagingDraft to keep things simple(r). >>>> >>>> Made each cmake option a separate macro to make in easier to override. >>>> >>>> Comments? >>> do you need the _cmake_* macros for other things? If not, I would >>> simply write the values into the %cmake macros. >>> %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} >>> %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON >>> %_cmake_lib_suffix64 -DLIB_SUFFIX=64 >> Using _cmake_* macros allows for users to easily override/change >> individual items, if needed. > > What would one override? They are already generic enough. If they > really need changing then cmake will have changed so much that the > %cmake macro would also not be valid anymore. Then, do you have other method of overriding/omitting, say, -DBUILD_SHARED_LIBS:BOOL=ON from the build? -- Rex From Axel.Thimm at ATrpms.net Tue Mar 13 20:58:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Mar 2007 21:58:39 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <200703132135.36547.opensource@till.name> References: <200703122129.54677.opensource@till.name> <1173733558.25122.28.camel@localhost.localdomain> <20070312221930.GF4363@neu.nirvana> <200703132135.36547.opensource@till.name> Message-ID: <20070313205839.GB24460@neu.nirvana> On Tue, Mar 13, 2007 at 09:35:16PM +0100, Till Maas wrote: > On Mo M?rz 12 2007, Axel Thimm wrote: > > On Mon, Mar 12, 2007 at 04:05:58PM -0500, Tom 'spot' Callaway wrote: > > > > Erm, ok. In the buildsystem, this should never happen (hooray mock), but > > > when building on a multi-user system, I can see the remote possibility. > > > > Hey, our new preferred buildroot makes it even harder to guess the > > Buildroot name, hooray2 ;) > > Does "grep RPM_BUILD_ROOT= /var/tmp/rpm-tmp.*" not work with the preferred > buildroot? The race between two rm/mkdir are about 50%. If you add a grep into one of them the balance will be strongly shifted in our favour, just try it. The true solution is the mkdir w/o -p method, but it didn't pass the vote. :( -- 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 Mar 13 21:02:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Mar 2007 22:02:12 +0100 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: <45F70FCE.4080507@math.unl.edu> References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <45F70FCE.4080507@math.unl.edu> Message-ID: <20070313210212.GC24460@neu.nirvana> On Tue, Mar 13, 2007 at 03:55:42PM -0500, Rex Dieter wrote: > Axel Thimm wrote: > >On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote: > >>Axel Thimm wrote: > >>>On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote: > >>>>Appended is a first try at rpm macro'izing the the call to cmake per: > >>>>http://fedoraproject.org/wiki/PackagingDrafts/cmake > >>>> > >>>>I chose not to implement the out-of-tree style of build in the > >>>>PackagingDraft to keep things simple(r). > >>>> > >>>>Made each cmake option a separate macro to make in easier to override. > >>>> > >>>>Comments? > >>>do you need the _cmake_* macros for other things? If not, I would > >>>simply write the values into the %cmake macros. > >>>%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > >>>%_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON > >>>%_cmake_lib_suffix64 -DLIB_SUFFIX=64 > >>Using _cmake_* macros allows for users to easily override/change > >>individual items, if needed. > > > >What would one override? They are already generic enough. If they > >really need changing then cmake will have changed so much that the > >%cmake macro would also not be valid anymore. > > Then, do you have other method of overriding/omitting, say, > -DBUILD_SHARED_LIBS:BOOL=ON > from the build? Would I ever want that? And in that case I would just not use %cmake. Same as if I don't want %configure to pass CFLAGS=%{optflags} 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 opensource at till.name Tue Mar 13 21:48:55 2007 From: opensource at till.name (Till Maas) Date: Tue, 13 Mar 2007 22:48:55 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <20070313205839.GB24460@neu.nirvana> References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> Message-ID: <200703132248.56520.opensource@till.name> On Di M?rz 13 2007, Axel Thimm wrote: > The race between two rm/mkdir are about 50%. If you add a grep into > one of them the balance will be strongly shifted in our favour, just > try it. The grep needs only to be performed once before the race to "guess" the buildroot. Regards, Till From enrico.scholz at informatik.tu-chemnitz.de Wed Mar 14 00:41:40 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Mar 2007 01:41:40 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <200703132251.10847.ville.skytta@iki.fi> (Ville Skytt's message of "Tue, 13 Mar 2007 22:51:09 +0200") References: <200703122129.54677.opensource@till.name> <871wjtzhm6.fsf@kosh.bigo.ensc.de> <200703132251.10847.ville.skytta@iki.fi> Message-ID: <8764941wsb.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> > %install >> > rm -rf $RPM_BUILD_ROOT >> > mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists >> >> Will work; > > ...but will break in setups where some subdirs of $RPM_BUILD_ROOT are missing > before %install. This wouldn't suffer from that drawback: > > %install > rm -rf $RPM_BUILD_ROOT > mkdir -p $(dirname $RPM_BUILD_ROOT) ; mkdir $RPM_BUILD_ROOT ... but opens a new attack vector because attacker could do | mkdir -m777 -p $(dirname $RPM_BUILD_ROOT) | ... wait until victim executes the first 2 %install lines | mv $RPM_BUILD_ROOT $(dirname $RPM_BUILD_ROOT)/old-buildroot | mkdir $RPM_BUILD_ROOT (easy to automate by some inotify in $(dirname $RPM_BUILD_ROOT)) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Mar 14 11:14:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 12:14:22 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <200703132248.56520.opensource@till.name> References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> <200703132248.56520.opensource@till.name> Message-ID: <20070314111422.GE15787@neu.nirvana> On Tue, Mar 13, 2007 at 10:48:55PM +0100, Till Maas wrote: > On Di M?rz 13 2007, Axel Thimm wrote: > > > The race between two rm/mkdir are about 50%. If you add a grep into > > one of them the balance will be strongly shifted in our favour, just > > try it. > > The grep needs only to be performed once before the race to "guess" the > buildroot. Yes, once, but in the right time window, which is when between when the scriplet is written to disk and being executed. So the attacker has to win two races, not only one, and the grep itself and subsequent text parsing takes more time than the script's rm/mkdir. But this is all academic, try an attack and check the success rates, I'm sure they will be very low in the mktemp BuildRoot, even if you write the grep/sed stuff in C. But they will be zero if we handle the race in the specfile, I'm not trying to play the true issue down. -- 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 Wed Mar 14 11:21:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 12:21:45 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <8764941wsb.fsf@kosh.bigo.ensc.de> References: <200703122129.54677.opensource@till.name> <871wjtzhm6.fsf@kosh.bigo.ensc.de> <200703132251.10847.ville.skytta@iki.fi> <8764941wsb.fsf@kosh.bigo.ensc.de> Message-ID: <20070314112145.GF15787@neu.nirvana> On Wed, Mar 14, 2007 at 01:41:40AM +0100, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > >> > %install > >> > rm -rf $RPM_BUILD_ROOT > >> > mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists > >> > >> Will work; > > > > ...but will break in setups where some subdirs of $RPM_BUILD_ROOT are missing > > before %install. This wouldn't suffer from that drawback: > > > > %install > > rm -rf $RPM_BUILD_ROOT > > mkdir -p $(dirname $RPM_BUILD_ROOT) ; mkdir $RPM_BUILD_ROOT > > ... but opens a new attack vector because attacker could do > > | mkdir -m777 -p $(dirname $RPM_BUILD_ROOT) > | ... wait until victim executes the first 2 %install lines > | mv $RPM_BUILD_ROOT $(dirname $RPM_BUILD_ROOT)/old-buildroot > | mkdir $RPM_BUILD_ROOT > > (easy to automate by some inotify in $(dirname $RPM_BUILD_ROOT)) Nice catch. I agree with Enrico, if we start trying to fix that, too, we end up with a loop of mkdir's (w/o -p) from outer to inner with testing ownerships/permissions and so on. This would then bloat to take over most of the %install section. We already have resistance to adding a single mkdir line. :/ Instead the plain mkdir solution *will* fail, making the user rethink about his setup. If the user wants to build all his stuff under /var/tmp//... (which is a legitimate setup, of course), he needs to first create the basic sceleton with proper permissions, and the failure will make him do that. Otherwise we create scenarios like Enrico describes. E.g. The buildroot setting should assume that the parent folders are all properly set up beforehand, including existance, ownership and permissions. Then we only need an rm/mkdir pair. -- 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 opensource at till.name Wed Mar 14 14:07:30 2007 From: opensource at till.name (Till Maas) Date: Wed, 14 Mar 2007 15:07:30 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <20070314111422.GE15787@neu.nirvana> References: <200703122129.54677.opensource@till.name> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> Message-ID: <200703141507.32685.opensource@till.name> On Mi M?rz 14 2007, Axel Thimm wrote: > Yes, once, but in the right time window, which is when between when the > scriplet is written to disk and being executed. So the attacker has to win > two races, not only one, and the grep itself and subsequent text parsing > takes more time than the script's rm/mkdir. In the rpm-tmp files I have on my system, there is not only the install part in the file, but also the build part. So I assume that after the file is created and the attackers knows the buildroot, he has all the time until %build is finished, to prepare the race betwenn rm/mkdir in %install. Regards, Till From Axel.Thimm at ATrpms.net Wed Mar 14 15:23:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 16:23:41 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <200703141507.32685.opensource@till.name> References: <200703122129.54677.opensource@till.name> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> <200703141507.32685.opensource@till.name> Message-ID: <20070314152341.GA30080@neu.nirvana> On Wed, Mar 14, 2007 at 03:07:30PM +0100, Till Maas wrote: > On Mi M?rz 14 2007, Axel Thimm wrote: > > > Yes, once, but in the right time window, which is when between when the > > scriplet is written to disk and being executed. So the attacker has to win > > two races, not only one, and the grep itself and subsequent text parsing > > takes more time than the script's rm/mkdir. > > In the rpm-tmp files I have on my system, there is not only the install part > in the file, but also the build part. So I assume that after the file is > created and the attackers knows the buildroot, he has all the time > until %build is finished, to prepare the race betwenn rm/mkdir in %install. Ouch! Another reason why %build even knowing where %{buildroot} is, is bad. So, indeed we need to fix this somehow (e.g. the rm/mkdir suggestion). Very nice thinking! -- 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 enrico.scholz at informatik.tu-chemnitz.de Wed Mar 14 18:53:15 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Mar 2007 19:53:15 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <20070314111422.GE15787@neu.nirvana> (Axel Thimm's message of "Wed, 14 Mar 2007 12:14:22 +0100") References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> Message-ID: <874ponzmg4.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > But this is all academic, try an attack and check the success rates, > I'm sure they will be very low in the mktemp BuildRoot, I do not think that probabilities should be considered in security related discussions; "A little bit insecure" is like "a little bit pregnant" ;) Attacker could start 100 of programs which are trying to exploit the race. This has the effect of: * increasing the load which in turn enlarges the timeslot for the race * increasing the probability that the whole attack succeeds Therefore: either let us fix this issue completely ('mkdir $RPM_BUILD_ROOT'), perhaps with reducing functionality in some use cases (e.g. %_tmpdir/%username/%name-... buildroot). Moving the (secure) RPM_BUILD_ROOT initialization into the automatically generated rpm script (afair, recent (jbj-)rpm does already 'rm -rf $RPM_BUILD_ROOT' by default) should free packager from this task but will require changes to all spec files. Or, assume/require that %_tmpdir is at a secure location. I think, nearly nobody reviews buildprocesses for security, but assumes that they happen in a trusted environment. Builds itself have to happen as a separate user; I do not want a broken Makefile which wipes my $HOME... > even if you write the grep/sed stuff in C. The 'mktemp(1) - rm(1)' sequence is done in the shell, which calls dynamic linked binaries, which are doing lot of stuff before the first 'unlink(2)/rmdir(2)' is called. In the meantime, attacker's C program has only to react on the inotify(7) event (e.g. return from select(2)) and has to readdir(2) /var/tmp. I think this is much faster than the 'mktemp(1) - rm(1)' sequence. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Mar 14 19:55:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 20:55:55 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <874ponzmg4.fsf@kosh.bigo.ensc.de> References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> <874ponzmg4.fsf@kosh.bigo.ensc.de> Message-ID: <20070314195555.GB10100@neu.nirvana> On Wed, Mar 14, 2007 at 07:53:15PM +0100, Enrico Scholz wrote: > Therefore: either let us fix this issue completely ('mkdir > $RPM_BUILD_ROOT'), perhaps with reducing functionality in some use cases > (e.g. %_tmpdir/%username/%name-... buildroot). Make no mistake: I'm all for doing so, we even voted yesterday, but the vote didn't went well. -- 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 rc040203 at freenet.de Wed Mar 14 21:35:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Mar 2007 22:35:51 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <20070314195555.GB10100@neu.nirvana> References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> <874ponzmg4.fsf@kosh.bigo.ensc.de> <20070314195555.GB10100@neu.nirvana> Message-ID: <1173908151.4680.51.camel@mccallum.corsepiu.local> On Wed, 2007-03-14 at 20:55 +0100, Axel Thimm wrote: > On Wed, Mar 14, 2007 at 07:53:15PM +0100, Enrico Scholz wrote: > > Therefore: either let us fix this issue completely ('mkdir > > $RPM_BUILD_ROOT'), perhaps with reducing functionality in some use cases > > (e.g. %_tmpdir/%username/%name-... buildroot). > > Make no mistake: I'm all for doing so, we even voted yesterday, but > the vote didn't went well. I voted against it, because a) all this is playing with symptoms. The real cause is inside of rpm and therefore should be fixed inside of rpm. b) this is all is not a real issue in practice. Ralf From Axel.Thimm at ATrpms.net Wed Mar 14 21:50:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Mar 2007 22:50:14 +0100 Subject: [Fedora-packaging] Re: buildroot race condition In-Reply-To: <1173908151.4680.51.camel@mccallum.corsepiu.local> References: <200703122129.54677.opensource@till.name> <200703132135.36547.opensource@till.name> <20070313205839.GB24460@neu.nirvana> <200703132248.56520.opensource@till.name> <20070314111422.GE15787@neu.nirvana> <874ponzmg4.fsf@kosh.bigo.ensc.de> <20070314195555.GB10100@neu.nirvana> <1173908151.4680.51.camel@mccallum.corsepiu.local> Message-ID: <20070314215014.GE10100@neu.nirvana> On Wed, Mar 14, 2007 at 10:35:51PM +0100, Ralf Corsepius wrote: > On Wed, 2007-03-14 at 20:55 +0100, Axel Thimm wrote: > > On Wed, Mar 14, 2007 at 07:53:15PM +0100, Enrico Scholz wrote: > > > Therefore: either let us fix this issue completely ('mkdir > > > $RPM_BUILD_ROOT'), perhaps with reducing functionality in some use cases > > > (e.g. %_tmpdir/%username/%name-... buildroot). > > > > Make no mistake: I'm all for doing so, we even voted yesterday, but > > the vote didn't went well. > I voted against it, because > a) all this is playing with symptoms. The real cause is inside of rpm > and therefore should be fixed inside of rpm. That's as helpful as "The real cause of buffer overflows is that C doesn't handle them, so we should stop fixing them until #C++ double-O fixes them." > b) this is all is not a real issue in practice. Well, you need to pick a side. On odd days in the calendar you require corner-case buildroot setup that allows mulitple users to builde xactly the same package with the same evr. On even days the same users will take a vow to never mess with each other's buildroots. -- 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 kevin.kofler at chello.at Thu Mar 15 03:23:48 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 03:23:48 +0000 (UTC) Subject: [Fedora-packaging] Re: cmake rpm macro(s): References: <45F6E7FC.3000605@math.unl.edu> <45F6F76D.7050602@math.unl.edu> <45F70501.5000002@cora.nwra.com> <45F70671.6010209@math.unl.edu> Message-ID: Rex Dieter math.unl.edu> writes: > Well, I wasn't aware of in-tree problems, so my first draft left out the > details wrt out-of-tree builds. FYI, all the kde*4 modules don't support in-tree building. They recommend you to create a build subdirectory within the source directory, and use that as the build directory. I'm following that recommendation in my packaging (though any build directory other than the source directory should work). Kevin Kofler From kevin.kofler at chello.at Thu Mar 15 03:25:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 03:25:19 +0000 (UTC) Subject: [Fedora-packaging] Re: cmake rpm macro(s): References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > > > %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > > > %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON > > > %_cmake_lib_suffix64 -DLIB_SUFFIX=64 > > > > Using _cmake_* macros allows for users to easily override/change > > individual items, if needed. > > What would one override? They are already generic enough. Because KDE 4 needs to go to /opt/kde4 (or /usr/kde4 or some other prefix, but not /usr) or it will trip on KDE 3. For example, kdelibs-devel and kdelibs4-devel would clash on the .so symlinks if I packaged KDE 4 into /usr. Kevin Kofler From Axel.Thimm at ATrpms.net Thu Mar 15 08:53:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 09:53:39 +0100 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> Message-ID: <20070315085339.GC25860@neu.nirvana> On Thu, Mar 15, 2007 at 03:25:19AM +0000, Kevin Kofler wrote: > Axel Thimm ATrpms.net> writes: > > > > %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > > > > %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON > > > > %_cmake_lib_suffix64 -DLIB_SUFFIX=64 > > > > > > Using _cmake_* macros allows for users to easily override/change > > > individual items, if needed. > > > > What would one override? They are already generic enough. > > Because KDE 4 needs to go to /opt/kde4 (or /usr/kde4 or some other prefix, but > not /usr) or it will trip on KDE 3. For example, kdelibs-devel and > kdelibs4-devel would clash on the .so symlinks if I packaged KDE 4 into /usr. You would set a different %{_prefix} then. I wasn't arguing about the use of %{_prefix}, that's more than fine. -- 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 Thu Mar 15 11:49:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 12:49:56 +0100 Subject: [Fedora-packaging] How to deal with folders that need the user to change permissions on? Message-ID: <20070315114956.GH25860@neu.nirvana> Hi, the default mediawiki install does not allow image uploads (on puprose) and requires the user to adjust permissions (#231542). Perhaps there is a better way to deal with this in mediawiki, but the general issue came up: Suppose a package requires the user/admin to change permissions on a folder to enable some functionality. How do we deal with that? A package upgrade resets the permissions and there is no way to tell rpm that this folder is "%configdir". A workaround would be to not own this folder which is very ugly, violates guidelines, leaves orphaned folders behind, and is just not The Right Solution. Which is The Right Solution? (again in the context of "folder permission change really required by a package", I hope mediawiki's issue may be worked around, so don't stick to this example) -- 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 Thu Mar 15 13:16:12 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 15 Mar 2007 15:16:12 +0200 Subject: [Fedora-packaging] How to deal with folders that need the user to change permissions on? In-Reply-To: <20070315114956.GH25860@neu.nirvana> References: <20070315114956.GH25860@neu.nirvana> Message-ID: <200703151516.12530.ville.skytta@iki.fi> On Thursday 15 March 2007, Axel Thimm wrote: > A workaround would be to not own this folder which is very ugly, > violates guidelines, leaves orphaned folders behind, and is just not > The Right Solution. Which is The Right Solution? Well, if I understand correctly, considering that fiddling with the permissions of this dir is required for the purpose of enabling mediawiki to create files in it, and those created files will not be owned by the mediawiki package in any case and will be left behind on package erase (ditto the dir if there are files in it, dir owned or not), I don't think leaving it unowned would be anywhere near a cardinal sin either. In fact, it sounds much better to me than changing permissions of packaged files - package upgrades reset permissions of files, %config or not. Ditto rpm --setperms/--setugids. Which is why IMHO the answer to the original question is "don't even try to require changing permissions/ownership of packaged files, find a better way around the problem". Marking the dir as %ghost and experimenting how it behaves then could also be of (mostly academic) interest. From Axel.Thimm at ATrpms.net Thu Mar 15 14:40:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 15:40:40 +0100 Subject: [Fedora-packaging] Re: How to deal with folders that need the user to change permissions on? In-Reply-To: <200703151516.12530.ville.skytta@iki.fi> References: <20070315114956.GH25860@neu.nirvana> <200703151516.12530.ville.skytta@iki.fi> Message-ID: <20070315144040.GJ25860@neu.nirvana> On Thu, Mar 15, 2007 at 03:16:12PM +0200, Ville Skytt? wrote: > On Thursday 15 March 2007, Axel Thimm wrote: > > > A workaround would be to not own this folder which is very ugly, > > violates guidelines, leaves orphaned folders behind, and is just not > > The Right Solution. Which is The Right Solution? > > Well, if I understand correctly, considering that fiddling with the > permissions of this dir is required for the purpose of enabling mediawiki to > create files in it, and those created files will not be owned by the > mediawiki package in any case and will be left behind on package erase (ditto > the dir if there are files in it, dir owned or not), I don't think leaving it > unowned would be anywhere near a cardinal sin either. > > In fact, it sounds much better to me than changing permissions of packaged > files - package upgrades reset permissions of files, %config or not. Ditto > rpm --setperms/--setugids. Which is why IMHO the answer to the original > question is "don't even try to require changing permissions/ownership of > packaged files, find a better way around the problem". So, you suggest to not ship the folder at all? Or create it in %post to evade the folder entering the manifest? > Marking the dir as %ghost and experimenting how it behaves then could also be > of (mostly academic) interest. Well, %ghosting is for having something in the manifest w/o shipping it. I want the opposite :) -- 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 Thu Mar 15 14:49:31 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 15 Mar 2007 16:49:31 +0200 Subject: [Fedora-packaging] Re: How to deal with folders that need the user to change permissions on? In-Reply-To: <20070315144040.GJ25860@neu.nirvana> References: <20070315114956.GH25860@neu.nirvana> <200703151516.12530.ville.skytta@iki.fi> <20070315144040.GJ25860@neu.nirvana> Message-ID: <200703151649.31401.ville.skytta@iki.fi> On Thursday 15 March 2007, Axel Thimm wrote: > So, you suggest to not ship the folder at all? Or create it in %post > to evade the folder entering the manifest? Not at all, if it can't be done right out of the box. > > Marking the dir as %ghost and experimenting how it behaves then could > > also be of (mostly academic) interest. > > Well, %ghosting is for having something in the manifest w/o shipping > it. Not only that; if a %ghost'ed file didn't exist when one installed a package, but exist when that package is erased, it will be removed. You seemed to be concerned about the dir being unowned and not removed on erase - %ghosting would help with it being owned, and in some cases the removal as well. What I don't know is whether ownership/modes of %ghosted but present files are reset on package install/upgrade or not. From kevin.kofler at chello.at Sun Mar 18 01:58:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 18 Mar 2007 01:58:15 +0000 (UTC) Subject: [Fedora-packaging] Re: cmake rpm macro(s): References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <20070315085339.GC25860@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > You would set a different %{_prefix} then. I wasn't arguing about the > use of %{_prefix}, that's more than fine. Won't setting %{_prefix} make the package relocatable? I want to have cmake install into another prefix, but not make the RPM relocatable, because the prefix is hardcoded in at least kde4-config. Kevin Kofler From Axel.Thimm at ATrpms.net Sun Mar 18 10:04:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 11:04:40 +0100 Subject: [Fedora-packaging] Re: cmake rpm macro(s): In-Reply-To: References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <20070315085339.GC25860@neu.nirvana> Message-ID: <20070318100440.GA18524@neu.nirvana> On Sun, Mar 18, 2007 at 01:58:15AM +0000, Kevin Kofler wrote: > Axel Thimm ATrpms.net> writes: > > You would set a different %{_prefix} then. I wasn't arguing about the > > use of %{_prefix}, that's more than fine. > > Won't setting %{_prefix} make the package relocatable? At build time? No, it won't, and for truly being relocatable the package needs to support this at runtime, e.g. the build should not hardwire /usr and friends anywhere. Being relocatabale needs a lot of work at the source level. > I want to have cmake install into another prefix, but not make the > RPM relocatable, because the prefix is hardcoded in at least > kde4-config. Same as for any other package: rpmbuild --define '%_prefix /opt/my/stuff' Or define _prefix somewhere more global as you will probably want to put more packages under your /opt hierarchy. -- 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 fedora at leemhuis.info Sun Mar 18 14:17:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 15:17:13 +0100 Subject: [Fedora-packaging] Repotag in EPEL Message-ID: <45FD49E9.7070701@leemhuis.info> Hi, I'd like to ask the Packaging Committee (which afaics is responsible for the Packaging standards used in Fedora projects, which includes EPEL) for advice and a formal decision about using a repotag in EPEL. There are a lot of people strongly urging to use one -- see attached mails or the threads in the online archive at https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html I (and some other EPEL SIG members afaics) don't care much about using one or not. But afaics the use of a repotag is unwanted in Fedora-land up to now afaics. If the answer from the PC is "yes, EPEL is free to use a repotag" then please decide how to actually use it -- Add a "repotag" macro defined by the buildsys or overload %{dist}, ... We need a decision soon. Thanks for your support. CU thl -------------- next part -------------- An embedded message was scrubbed... From: Dag Wieers Subject: Repotag Date: Wed, 14 Mar 2007 12:49:13 +0100 (CET) Size: 4724 URL: -------------- next part -------------- An embedded message was scrubbed... From: Dennis Gilmore Subject: Re: Repotag Date: Wed, 14 Mar 2007 07:08:31 -0500 Size: 7021 URL: -------------- next part -------------- An embedded message was scrubbed... From: Dag Wieers Subject: Re: Repotag Date: Wed, 14 Mar 2007 13:27:57 +0100 (CET) Size: 6899 URL: -------------- next part -------------- An embedded message was scrubbed... From: Thorsten Leemhuis Subject: Re: Repotag Date: Wed, 14 Mar 2007 15:11:52 +0100 Size: 5134 URL: -------------- next part -------------- An embedded message was scrubbed... From: Dag Wieers Subject: Re: Repotag Date: Thu, 15 Mar 2007 13:16:09 +0100 (CET) Size: 6770 URL: -------------- next part -------------- An embedded message was scrubbed... From: Mike McGrath Subject: Re: Repotag Date: Thu, 15 Mar 2007 08:36:26 -0500 Size: 4232 URL: -------------- next part -------------- An embedded message was scrubbed... From: Dag Wieers Subject: Re: Repotag Date: Thu, 15 Mar 2007 18:25:03 +0100 (CET) Size: 5289 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Greg Swallow" Subject: RE: Repotag Date: Thu, 15 Mar 2007 10:34:26 -0700 Size: 5001 URL: -------------- next part -------------- An embedded message was scrubbed... From: Axel Thimm Subject: Re: Repotag Date: Thu, 15 Mar 2007 18:42:37 +0100 Size: 6456 URL: -------------- next part -------------- An embedded message was scrubbed... From: Phil Schaffner Subject: RE: Repotag Date: Thu, 15 Mar 2007 08:44:42 -0400 Size: 5897 URL: -------------- next part -------------- An embedded message was scrubbed... From: Jarod Wilson Subject: Re: Repotag Date: Thu, 15 Mar 2007 14:10:03 -0400 Size: 7105 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Greg Swallow" Subject: RE: Repotag Date: Thu, 15 Mar 2007 11:37:35 -0700 Size: 5414 URL: -------------- next part -------------- An embedded message was scrubbed... From: Jarod Wilson Subject: Re: Repotag Date: Thu, 15 Mar 2007 14:48:00 -0400 Size: 6923 URL: -------------- next part -------------- An embedded message was scrubbed... From: Tim Lauridsen Subject: Re: Repotag Date: Fri, 16 Mar 2007 13:25:43 +0100 Size: 4174 URL: -------------- next part -------------- An embedded message was scrubbed... From: Patrice Dumas Subject: Re: Repotag Date: Fri, 16 Mar 2007 14:12:03 +0100 Size: 6528 URL: -------------- next part -------------- An embedded message was scrubbed... From: Dag Wieers Subject: Re: [users] Dropping the repotag Date: Sun, 18 Mar 2007 14:43:27 +0100 (CET) Size: 9434 URL: From ville.skytta at iki.fi Sun Mar 18 17:12:44 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 18 Mar 2007 19:12:44 +0200 Subject: [Fedora-packaging] Repotag in EPEL In-Reply-To: <45FD49E9.7070701@leemhuis.info> References: <45FD49E9.7070701@leemhuis.info> Message-ID: <200703181912.44458.ville.skytta@iki.fi> On Sunday 18 March 2007, Thorsten Leemhuis wrote: > > I (and some other EPEL SIG members afaics) don't care much about using > one or not. But afaics the use of a repotag is unwanted in Fedora-land > up to now afaics. > > If the answer from the PC is "yes, EPEL is free to use a repotag" then > please decide how to actually use it -- Add a "repotag" macro defined by > the buildsys or overload %{dist}, ... My .02?: as a user of an enterprise distro, using several repos which ship the same software in slightly different packages is most definitely something I wouldn't do (at least without actively taking care of overlaps myself eg. with explicit per-repo exclusions/inclusions in depsolver configs, and accepting the blame if it blows up on me). Repotag seems to encourage such repo mixing somewhat, which is why I'm slightly leaning against it. Or put another way, I really don't care because I think if I'm in a situation where repotags between repos start to matter at all, I should sanity check my setup before doing anything else. But if there is a "repotag", it needs to be placed in the release tag in a way that it doesn't affect version comparisons between package releases (within a repo). Just defining %{dist} eg. as .elX.epel wouldn't work as %{dist} is optional, but defining eg. %{repo} and making its usage rules the same as %{dist}'s (except if dist is there too, repo needs to come directly appended to it) could work. From Axel.Thimm at ATrpms.net Sun Mar 18 17:24:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 18:24:56 +0100 Subject: [Fedora-packaging] Re: Repotag in EPEL In-Reply-To: <45FD49E9.7070701@leemhuis.info> References: <45FD49E9.7070701@leemhuis.info> Message-ID: <20070318172456.GC31755@neu.nirvana> On Sun, Mar 18, 2007 at 03:17:13PM +0100, Thorsten Leemhuis wrote: > I'd like to ask the Packaging Committee (which afaics is responsible > for the Packaging standards used in Fedora projects, which includes > EPEL) for advice and a formal decision about using a repotag in > EPEL. We do need a mandate, but that's in the works, so let's assume the FPC is empowered and willing (I am, I can't speak about the rest of the members) to define EPEL guidelines as well. > There are a lot of people strongly urging to use one > I (and some other EPEL SIG members afaics) don't care much about using > one or not. But afaics the use of a repotag is unwanted in Fedora-land > up to now afaics. > > If the answer from the PC is "yes, EPEL is free to use a repotag" then > please decide how to actually use it -- Add a "repotag" macro defined by > the buildsys or overload %{dist}, ... Technically, if EPEL gets a repotag it should be via %dist, so that no specfile using %dist will need to be touched. Furthermore it would have to be something like say ".el5.epel" or similar to fit the usual .. structure. The topic is a bit political as it influences the releationship between EPEL and other 3rd party RHEL supporters. Furthermore we don't even have a *disttag* *mandatory* for FC because there are different views withing the contributor body (inner politics if you like). I think the general repotag issue needs to be solved by EPEL (whether there will be one or not). We are trying to focus on purely technically oriented topics and avoid any political decisions, e.g. what software is allowed to be packaged, the range of licenses allowed, the firmware policy and so on are mostly input for us (there is a two way communication to fesco, of course) and we outline the policies. So if *the EPEL wants* a repotag we'll be able to shape it into guidelines. If it doesn't we'll write that down as well. But we'd probably not decide on whether EPEL marks their packages or not and thus potentially create political issues between EPEL and other repos by the feather of the FPC. -- 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 dlutter at redhat.com Mon Mar 19 23:05:09 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 19 Mar 2007 16:05:09 -0700 Subject: [Fedora-packaging] Repotag in EPEL In-Reply-To: <200703181912.44458.ville.skytta@iki.fi> References: <45FD49E9.7070701@leemhuis.info> <200703181912.44458.ville.skytta@iki.fi> Message-ID: <1174345509.10131.56.camel@localhost.localdomain> On Sun, 2007-03-18 at 19:12 +0200, Ville Skytt? wrote: > Repotag seems to encourage such > repo mixing somewhat, which is why I'm slightly leaning against it. OTOH, we'll never completely prevent people shooting themselves in the foot; all we can do make that less painful. > But if there is a "repotag", it needs to be placed in the release tag in a way > that it doesn't affect version comparisons between package releases (within a > repo). Just defining %{dist} eg. as .elX.epel wouldn't work as %{dist} is > optional, Could EPEL make it mandoatory for its packages ? It seems that expanding %{dist} for this would be very low overhead and unintrusive for packagers. David From pertusus at free.fr Mon Mar 19 23:22:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 20 Mar 2007 00:22:37 +0100 Subject: [Fedora-packaging] Repotag in EPEL In-Reply-To: <1174345509.10131.56.camel@localhost.localdomain> References: <45FD49E9.7070701@leemhuis.info> <200703181912.44458.ville.skytta@iki.fi> <1174345509.10131.56.camel@localhost.localdomain> Message-ID: <20070319232237.GF2905@free.fr> On Mon, Mar 19, 2007 at 04:05:09PM -0700, David Lutterkort wrote: > Could EPEL make it mandoatory for its packages ? It seems that expanding > %{dist} for this would be very low overhead and unintrusive for > packagers. For some packages it is better not to have a dist tag (noarch data packages, mostly). -- Pat From tcallawa at redhat.com Tue Mar 20 13:03:12 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 08:03:12 -0500 Subject: [Fedora-packaging] Repotag in EPEL In-Reply-To: <20070319232237.GF2905@free.fr> References: <45FD49E9.7070701@leemhuis.info> <200703181912.44458.ville.skytta@iki.fi> <1174345509.10131.56.camel@localhost.localdomain> <20070319232237.GF2905@free.fr> Message-ID: <1174395792.16111.36.camel@localhost.localdomain> On Tue, 2007-03-20 at 00:22 +0100, Patrice Dumas wrote: > On Mon, Mar 19, 2007 at 04:05:09PM -0700, David Lutterkort wrote: > > Could EPEL make it mandoatory for its packages ? It seems that expanding > > %{dist} for this would be very low overhead and unintrusive for > > packagers. > > For some packages it is better not to have a dist tag (noarch data > packages, mostly). Indeed. I'm not necessarily opposed to the repotag being part of %{dist} for EPEL, but I am opposed to making %{dist} mandatory. I've still not exactly heard a good reason for a repotag yet, or rather, what problem we solve with it. Are we simply trying to identify the repository from which a package came for the purposes of enabling users to file a bug in the right place? Or is this something more complicated? ~spot From Axel.Thimm at ATrpms.net Tue Mar 20 13:27:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 14:27:43 +0100 Subject: [Fedora-packaging] Re: Repotag in EPEL In-Reply-To: <1174395792.16111.36.camel@localhost.localdomain> References: <45FD49E9.7070701@leemhuis.info> <200703181912.44458.ville.skytta@iki.fi> <1174345509.10131.56.camel@localhost.localdomain> <20070319232237.GF2905@free.fr> <1174395792.16111.36.camel@localhost.localdomain> Message-ID: <20070320132743.GO14567@neu.nirvana> On Tue, Mar 20, 2007 at 08:03:12AM -0500, Tom spot Callaway wrote: > Indeed. I'm not necessarily opposed to the repotag being part of %{dist} > for EPEL, but I am opposed to making %{dist} mandatory. I don't think disttag was called for becoming mandatory. -- 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 kevin.kofler at chello.at Tue Mar 20 13:48:45 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 Mar 2007 13:48:45 +0000 (UTC) Subject: [Fedora-packaging] Re: cmake rpm macro(s): References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <20070315085339.GC25860@neu.nirvana> <20070318100440.GA18524@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > > Won't setting %{_prefix} make the package relocatable? > > At build time? No, it won't, and for truly being relocatable the > package needs to support this at runtime, e.g. the build should not > hardwire /usr and friends anywhere. Being relocatabale needs a lot of > work at the source level. No, my question was if it will make RPM _think_ the package is relocatable, even if it actually is not, which of course will screw up badly if the user really tries to relocate the package. Kevin Kofler From tcallawa at redhat.com Tue Mar 20 09:10:33 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 04:10:33 -0500 Subject: [Fedora-packaging] Re: Repotag in EPEL In-Reply-To: <20070320132743.GO14567@neu.nirvana> References: <45FD49E9.7070701@leemhuis.info> <200703181912.44458.ville.skytta@iki.fi> <1174345509.10131.56.camel@localhost.localdomain> <20070319232237.GF2905@free.fr> <1174395792.16111.36.camel@localhost.localdomain> <20070320132743.GO14567@neu.nirvana> Message-ID: <1174381833.3563.2.camel@dhcp83-55.boston.redhat.com> On Tue, 2007-03-20 at 14:27 +0100, Axel Thimm wrote: > On Tue, Mar 20, 2007 at 08:03:12AM -0500, Tom spot Callaway wrote: > > Indeed. I'm not necessarily opposed to the repotag being part of %{dist} > > for EPEL, but I am opposed to making %{dist} mandatory. > > I don't think disttag was called for becoming mandatory. I just wanted to make that crystal clear. :) ~spot From Axel.Thimm at ATrpms.net Tue Mar 20 14:33:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 15:33:02 +0100 Subject: [Fedora-packaging] %{_prefix} vs Prefix: and relocatable packages (was: cmake rpm macro(s):) In-Reply-To: References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <20070315085339.GC25860@neu.nirvana> <20070318100440.GA18524@neu.nirvana> Message-ID: <20070320143302.GA6726@neu.nirvana> On Tue, Mar 20, 2007 at 01:48:45PM +0000, Kevin Kofler wrote: > Axel Thimm ATrpms.net> writes: > > > Won't setting %{_prefix} make the package relocatable? > > > > At build time? No, it won't, and for truly being relocatable the > > package needs to support this at runtime, e.g. the build should not > > hardwire /usr and friends anywhere. Being relocatabale needs a lot of > > work at the source level. > > No, my question was if it will make RPM _think_ the package is relocatable, > even if it actually is not, which of course will screw up badly if the user > really tries to relocate the package. I understand what you mean - no, setting _prefix does not make a package relocatable. The long version follows: Packages become relocatable by having a Prefix: ... tag. That's not how _prefix is set, _prefix is set like %_prefix /usr under /usr/lib/rpm somewhere, or even by %define _prefix ... in the specfile. You will sometimes find Prefix: / or Prefix: /usr or Prefix: %{_prefix} That doesn't really set prefix, it tells rpm that you promise to install everything under that folder and nowhere else outside of it (rpmbuild will bail out otherwise) and that that part of the buildroot is relocatable. Is it clearer or did I add to the confusion :) -- 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 kevin.kofler at chello.at Tue Mar 20 14:45:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 Mar 2007 14:45:18 +0000 (UTC) Subject: [Fedora-packaging] Re: %{_prefix} vs Prefix: and relocatable packages (was: cmake rpm macro(s):) References: <45F6E7FC.3000605@math.unl.edu> <20070313201426.GI10782@neu.nirvana> <45F70716.1050108@math.unl.edu> <20070313203711.GA24460@neu.nirvana> <20070315085339.GC25860@neu.nirvana> <20070318100440.GA18524@neu.nirvana> <20070320143302.GA6726@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > Packages become relocatable by having a > > Prefix: ... > > tag. That's not how _prefix is set, [...] > Is it clearer or did I add to the confusion :) That cleared it up. Kevin Kofler From fnasser at redhat.com Wed Mar 21 13:39:39 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 21 Mar 2007 09:39:39 -0400 Subject: [Fedora-packaging] Post-release tags Message-ID: <4601359B.1060309@redhat.com> Hi all, We have for quite some time figured out what to do with pre-release tags: 0.#..#%{?dist} But what to do with _post_-release tags? Here is an example: These upstream software releases its software from pre-release to final like that: 1_1_0_BETA 1_1_0_BETA1 1_1_0_BETA2 1_1_0_CR1 1_1_0_CR2 1_1_0_GA So far so good, we use pre-release tags for all but the last, which we call just '1.1.0'. After the final release (GA- General Availability), the process goes on. After some fixes are added, they release: 1_1_0_CP1 1_1_0_CP2 1_1_0_CP3 So I thought we could just add one decimal point: .1, .2 and .3 for the above. Eventually, they have a wider distribution one with a different naming: 1_1_0_SP1 (SP = Service Pack) And there goes my extra decimal point scheme. I think CPs after that would go like: 1_1_0_SP1_CP1 as I've also seen then use 1_1_0_GA_CP1 instead of just 1_1_0_CP1 I've also seem ugly things like 1_1_0_PATCH1 What should we do in these cases? Add non-numerics in the version field and have: 1.1.0.GA 1.1.0.GA.CP1 or 1.1.0.GA_CP1 Or should we create a "post-release" convention, with a numeric field (non-zero, to distinguish from pre-release tags) followed by the alphanumeric from upstream, like "GA", "GA_CP1" etc? Please, think a little bit about this, they have quite a few packages. Regards to all, Fernando P.S.: We don't need the leading '0.' in this case as there won't be a following pure digit version, like it happens for pre-release tags. From tcallawa at redhat.com Wed Mar 21 14:29:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 Mar 2007 09:29:20 -0500 Subject: [Fedora-packaging] Post-release tags In-Reply-To: <4601359B.1060309@redhat.com> References: <4601359B.1060309@redhat.com> Message-ID: <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-03-21 at 09:39 -0400, Fernando Nasser wrote: > Hi all, > > We have for quite some time figured out what to do with pre-release > tags: 0.#..#%{?dist} > > But what to do with _post_-release tags? >From http://fedoraproject.org/wiki/Packaging/NamingGuidelines "Post-release packages: Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a. In this case, the non-numeric characters are permitted in the Version: field. " > Here is an example: > > These upstream software releases its software from pre-release to final > like that: > > 1_1_0_BETA > 1_1_0_BETA1 > 1_1_0_BETA2 > 1_1_0_CR1 > 1_1_0_CR2 > 1_1_0_GA > > So far so good, we use pre-release tags for all but the last, which we > call just '1.1.0'. > > After the final release (GA- General Availability), the process goes on. > After some fixes are added, they release: > > 1_1_0_CP1 > 1_1_0_CP2 > 1_1_0_CP3 > > So I thought we could just add one decimal point: .1, .2 and .3 for the > above. Two methods come to mind: 1. Just increment the release and ignore the post release tagging, e.g. foo-1.1.0-0.1.BETA foo-1.1.0-0.2.BETA1 foo-1.1.0-0.3.BETA2 foo-1.1.0-0.4.CR1 foo-1.1.0-0.5.CR2 foo-1.1.0-1 (is actually GA) foo-1.1.0-2 (is actually CP1) foo-1.1.0-3 (is actually CP2) foo-1.1.0-4 (is actually CP3) foo-1.1.0-5 (is actually SP1) foo-1.1.0-6 (is actually SP1_CP1) 2. Use the post release tag like a CVS/SVN checkout tag: foo-1.1.0-0.1.BETA foo-1.1.0-0.2.BETA1 foo-1.1.0-0.3.BETA2 foo-1.1.0-0.4.CR1 foo-1.1.0-0.5.CR2 foo-1.1.0-1 (is actually GA) foo-1.1.0-2.CP1 foo-1.1.0-3.CP2 foo-1.1.0-4.CP3 foo-1.1.0-5.SP1 foo-1.1.0-6.SP1_CP1 I prefer option 1, as I suspect that users might care when something is in beta/pre-release, but don't care at all about post-release levels as long as it works. Either way works. The latter mechanism is a logical extension of CVS/SVN release naming, but it introduces icky underscores and makes the n-v-r longer (for what benefit)? ~spot From nicolas.mailhot at laposte.net Wed Mar 21 15:04:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Mar 2007 16:04:42 +0100 (CET) Subject: [Fedora-packaging] Post-release tags In-Reply-To: <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> References: <4601359B.1060309@redhat.com> <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> Message-ID: <31534.192.54.193.51.1174489482.squirrel@rousalka.dyndns.org> Le Mer 21 mars 2007 15:29, Tom \"spot\" Callaway a ?crit : > I prefer option 1, as I suspect that users might care when something is > in beta/pre-release, IMHO option 2 is better > but don't care at all about post-release levels as > long as it works. Either way works. The latter mechanism is a logical > extension of CVS/SVN release naming, And is good for the same reason pre-release is (stop users complaining because they don't understand the actual version used) > but it introduces icky underscores > and makes the n-v-r longer (for what benefit)? There's no reason not to sanitize alphatags, using small caps and replacing underscores with something else (nothing, dot, whatever). Alphatags are informative -- Nicolas Mailhot From alcapcom at gmail.com Wed Mar 21 15:09:34 2007 From: alcapcom at gmail.com (alcapcom) Date: Wed, 21 Mar 2007 16:09:34 +0100 Subject: [Fedora-packaging] [review: xorg-x11-server-Xgl] How you prefer start Xgl? Message-ID: <1174489774.3418.134.camel@xp2000.planet-cameleon.org> Hi list, Few months ago I have add a review for Xgl, without success at this time. Considering that fglrx driver still not support AIGLX, this package is useful for most of the fedora Desktop users. The specfile follow the packaging guide line, and seem to be clean. The only blocker that stay is "howto start Xgl". The goal of this mail, is to know which of the two solutions you preferred and why. Have try to sum the (+/-) of each solution, if there is other coolstuff/limitation/problem of one of them, it should be useful to know too. In advance, Thanks. Alphonse Start Xgl from GDM (session menu) --------------------------------- (+) The login time is shorter (last Xorg improvement) (+) Can choice a X type before login (-) Traditionally X is started on the display :0, but that is not possible if we start Xgl from GDM (dislay :0 should already used by GDM) (-) There are 3 log files for X (Xorg.0.log, Xorg.1.log and Xorg.93.log) that should appear strange for the end user. (-) For each WM available available on fedora, we needs a .desktop file (GDM session menu can quickly look too long) (-) two X are loaded at boot time + 1 if rgbd is used (graphical boot). Try it : http://files.damaestro.us/xgl/Xgl-settings-0.1-3.fc6.noarch.rpm Start GDM with Xgl ------------------ (+) do not have any of (-) thing of the first solution. (-) The only thing that I see is that the login take more time between the username input and the password input. Try it: http://download.tuxfamily.org/fedoraxgl/6/i386/system-config-xselector-0.1-1.noarch.rpm --- REVIEW BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192436 SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec SRPM: http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.4.20070102git.fc6.src.rpm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fnasser at redhat.com Wed Mar 21 21:24:57 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 21 Mar 2007 17:24:57 -0400 Subject: [Fedora-packaging] Post-release tags In-Reply-To: <31534.192.54.193.51.1174489482.squirrel@rousalka.dyndns.org> References: <4601359B.1060309@redhat.com> <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> <31534.192.54.193.51.1174489482.squirrel@rousalka.dyndns.org> Message-ID: <4601A2A9.8010401@redhat.com> Nicolas Mailhot wrote: > Le Mer 21 mars 2007 15:29, Tom \"spot\" Callaway a ?crit : > >> I prefer option 1, as I suspect that users might care when something is >> in beta/pre-release, > > IMHO option 2 is better > Yeah, for me too. The reason is that people are informed that certain bugs are fixed in (and after) certain post-releases, so they really need to know which one they have. >> but don't care at all about post-release levels as >> long as it works. Either way works. The latter mechanism is a logical >> extension of CVS/SVN release naming, > > And is good for the same reason pre-release is (stop users complaining > because they don't understand the actual version used) > >> but it introduces icky underscores >> and makes the n-v-r longer (for what benefit)? > > There's no reason not to sanitize alphatags, using small caps and > replacing underscores with something else (nothing, dot, whatever). > Alphatags are informative > As you brought that up... I saw that some keep the uppercase letters from the upstream tag or tar ball version, others make it lower case. What is the correct way? Fernando From fnasser at redhat.com Wed Mar 21 21:28:48 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 21 Mar 2007 17:28:48 -0400 Subject: [Fedora-packaging] Post-release tags In-Reply-To: <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> References: <4601359B.1060309@redhat.com> <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> Message-ID: <4601A390.80508@redhat.com> Hi Tom, Tom "spot" Callaway wrote: > On Wed, 2007-03-21 at 09:39 -0400, Fernando Nasser wrote: >> Hi all, >> >> We have for quite some time figured out what to do with pre-release >> tags: 0.#..#%{?dist} >> >> But what to do with _post_-release tags? > >>From http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > "Post-release packages: Packages released after a "final" version. This > usually is due to a quick bugfix release, such as openssl-0.9.6b or > gkrellm-2.1.7a. In this case, the non-numeric characters are permitted > in the Version: field. " > Yeah, I saw that. It did not bother me while these thing were a single letter like 'a' of 'b'. But when things start becomeing strings like SP1_CP2 or GA_CP1 it made me wish to have them out of the version part. > >> Here is an example: >> >> These upstream software releases its software from pre-release to final >> like that: >> >> 1_1_0_BETA >> 1_1_0_BETA1 >> 1_1_0_BETA2 >> 1_1_0_CR1 >> 1_1_0_CR2 >> 1_1_0_GA >> >> So far so good, we use pre-release tags for all but the last, which we >> call just '1.1.0'. >> >> After the final release (GA- General Availability), the process goes on. >> After some fixes are added, they release: >> >> 1_1_0_CP1 >> 1_1_0_CP2 >> 1_1_0_CP3 >> >> So I thought we could just add one decimal point: .1, .2 and .3 for the >> above. > > Two methods come to mind: > > 1. Just increment the release and ignore the post release tagging, e.g. > > foo-1.1.0-0.1.BETA > foo-1.1.0-0.2.BETA1 > foo-1.1.0-0.3.BETA2 > foo-1.1.0-0.4.CR1 > foo-1.1.0-0.5.CR2 > foo-1.1.0-1 (is actually GA) > foo-1.1.0-2 (is actually CP1) > foo-1.1.0-3 (is actually CP2) > foo-1.1.0-4 (is actually CP3) > foo-1.1.0-5 (is actually SP1) > foo-1.1.0-6 (is actually SP1_CP1) > The post-release information is important to the users, as it relates to where bugs were fixed. > > 2. Use the post release tag like a CVS/SVN checkout tag: > > foo-1.1.0-0.1.BETA > foo-1.1.0-0.2.BETA1 > foo-1.1.0-0.3.BETA2 > foo-1.1.0-0.4.CR1 > foo-1.1.0-0.5.CR2 > foo-1.1.0-1 (is actually GA) > foo-1.1.0-2.CP1 > foo-1.1.0-3.CP2 > foo-1.1.0-4.CP3 > foo-1.1.0-5.SP1 > foo-1.1.0-6.SP1_CP1 > This one works. > I prefer option 1, as I suspect that users might care when something is > in beta/pre-release, but don't care at all about post-release levels as > long as it works. Either way works. The latter mechanism is a logical > extension of CVS/SVN release naming, but it introduces icky underscores > and makes the n-v-r longer (for what benefit)? > Yeah, the underscore is a drag, but at least it is in the same situation as the ones from CVS tags. Cheers, Fernando From tcallawa at redhat.com Wed Mar 21 21:40:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 Mar 2007 16:40:56 -0500 Subject: [Fedora-packaging] Post-release tags In-Reply-To: <4601A390.80508@redhat.com> References: <4601359B.1060309@redhat.com> <1174487360.3288.14.camel@dhcp67.install.boston.redhat.com> <4601A390.80508@redhat.com> Message-ID: <1174513256.3288.46.camel@dhcp67.install.boston.redhat.com> On Wed, 2007-03-21 at 17:28 -0400, Fernando Nasser wrote: > > 2. Use the post release tag like a CVS/SVN checkout tag: > > > > foo-1.1.0-0.1.BETA > > foo-1.1.0-0.2.BETA1 > > foo-1.1.0-0.3.BETA2 > > foo-1.1.0-0.4.CR1 > > foo-1.1.0-0.5.CR2 > > foo-1.1.0-1 (is actually GA) > > foo-1.1.0-2.CP1 > > foo-1.1.0-3.CP2 > > foo-1.1.0-4.CP3 > > foo-1.1.0-5.SP1 > > foo-1.1.0-6.SP1_CP1 > > > > This one works. I'll draft this one up, we'll discuss it during next week's meeting. ~spot From tcallawa at redhat.com Fri Mar 23 17:10:05 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 23 Mar 2007 12:10:05 -0500 Subject: [Fedora-packaging] [DRAFT] ExtraDistTagConditionalMacros Message-ID: <1174669805.5072.21.camel@1cc-dhcp-162.media.mit.edu> I have added a draft for Extra DistTag Conditional Macros. Dag Wieers pointed out on the epel-devel mailing list that there were some useful macros that we could add to the existing helper macros to ease conditionals in spec files. http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros Comments are always welcomed. ~spot From Axel.Thimm at ATrpms.net Fri Mar 23 17:51:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 18:51:53 +0100 Subject: [Fedora-packaging] Re: ExtraDistTagConditionalMacros In-Reply-To: <1174669805.5072.21.camel@1cc-dhcp-162.media.mit.edu> References: <1174669805.5072.21.camel@1cc-dhcp-162.media.mit.edu> Message-ID: <20070323175153.GH3019@neu.nirvana> On Fri, Mar 23, 2007 at 12:10:05PM -0500, Tom spot Callaway wrote: > I have added a draft for Extra DistTag Conditional Macros. Dag Wieers > pointed out on the epel-devel mailing list that there were some useful > macros that we could add to the existing helper macros to ease > conditionals in spec files. > > http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros > > Comments are always welcomed. Having the macros is OK, but we should discourage lazy-riding on them, as it tends to assume an API/ABI stability, that doesn't exist (at least not on Fedora in that extend). For example F7 has foo-1 and therefore the packager of bar thinks it would be easier to query the fc7 or f7 macro than to check for foo's version. On the next update of foo to foo-2 package bar and it's specfile break. E.g. add something like: "Try to avoid explict conditionals on the distribution and prefer testing for features instead" -- 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 Fri Mar 23 17:58:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 18:58:19 +0100 Subject: [Fedora-packaging] Re: Post-release tags In-Reply-To: <4601359B.1060309@redhat.com> References: <4601359B.1060309@redhat.com> Message-ID: <20070323175819.GI3019@neu.nirvana> On Wed, Mar 21, 2007 at 09:39:39AM -0400, Fernando Nasser wrote: > We have for quite some time figured out what to do with pre-release > tags: 0.#..#%{?dist} > > But what to do with _post_-release tags? The reason for moving part of the version into the release (because in 1.0rc5, "rc5" *is* part of the upstream version) is to cope with rpm's ordering w/o having to resort to Bad Unnamed Things. But usually post-release tags are less complicated, they usually follow a scheme like 1.2.3p1,2,3,4,... or 1.2.3a,b,c,... etc, which are properly ordered wrt to both the "patchlevel 0" release and the next upcoming release. In these simple cases (which make most of the post-release taggings) I'd say use the full version as is. Less confusing to users and fits nicely. If your project goes up and down with the post-releases (rpm-wise) like 1.0 -> 1.0patch1 -> 1.0a2 then you need to split off part of the version again and shoot the upstream authors. -- 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 fedora at leemhuis.info Fri Mar 23 18:16:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Mar 2007 19:16:26 +0100 Subject: [Fedora-packaging] Re: ExtraDistTagConditionalMacros In-Reply-To: <20070323175153.GH3019@neu.nirvana> References: <1174669805.5072.21.camel@1cc-dhcp-162.media.mit.edu> <20070323175153.GH3019@neu.nirvana> Message-ID: <4604197A.8060103@leemhuis.info> Axel Thimm schrieb: > On Fri, Mar 23, 2007 at 12:10:05PM -0500, Tom spot Callaway wrote: >> I have added a draft for Extra DistTag Conditional Macros. Dag Wieers >> pointed out on the epel-devel mailing list that there were some useful >> macros that we could add to the existing helper macros to ease >> conditionals in spec files. >> http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros >> Comments are always welcomed. > Having the macros is OK, but we should discourage lazy-riding on them, > as it tends to assume an API/ABI stability, that doesn't exist (at > least not on Fedora in that extend). > > For example F7 has foo-1 and therefore the packager of bar thinks it > would be easier to query the fc7 or f7 macro than to check for foo's > version. On the next update of foo to foo-2 package bar and it's > specfile break. > > E.g. add something like: "Try to avoid explict conditionals on the > distribution and prefer testing for features instead" Strongly agreed. A nice thing about the current spec files in Fedora-land IMHO is that they are easy to read and to understand, even if you look at them for the first time. That's IMHO often not the case for some spec files out in the wild that use conditionals quite heavily. Heavily IMHO = all those with more then three --with/--without or other conditionals. CU thl From tcallawa at redhat.com Fri Mar 23 19:38:55 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 23 Mar 2007 14:38:55 -0500 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags Message-ID: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> I have added a draft for handling Post Release packages. http://fedoraproject.org/wiki/PackagingDrafts/PostRelease Comments are always welcomed. ~spot From tibbs at math.uh.edu Fri Mar 23 19:50:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Mar 2007 14:50:12 -0500 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> I have added a draft for handling Post Release packages. It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like: openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final Epoch is probably the only way out here unless we allow something nasty. - J< From nicolas.mailhot at laposte.net Fri Mar 23 20:01:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Mar 2007 21:01:34 +0100 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> Message-ID: <1174680094.3903.1.camel@rousalka.dyndns.org> Le vendredi 23 mars 2007 ? 14:50 -0500, Jason L Tibbitts III a ?crit : > >>>>> "TC" == Tom \"spot\" Callaway writes: > > TC> I have added a draft for handling Post Release packages. > > It might be worth mentioning what to do when upstream ODs on the > crackrock and unexpectedly changes to a non-ordered versioning scheme > in the middle of a sequence. Something like: > > openssl-0.9.6g > openssl-0.9.6h > openssl-0.9.6final > > Epoch is probably the only way out here unless we allow something Just proves adding any non-numeric part to versions is a bad idea -- 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 fnasser at redhat.com Fri Mar 23 20:31:24 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 23 Mar 2007 16:31:24 -0400 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> Message-ID: <4604391C.2010201@redhat.com> Tom "spot" Callaway wrote: > I have added a draft for handling Post Release packages. > > http://fedoraproject.org/wiki/PackagingDrafts/PostRelease > > Comments are always welcomed. > It seems very consistent, and the text is well written. I like it! --Fernando From fnasser at redhat.com Fri Mar 23 20:36:20 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 23 Mar 2007 16:36:20 -0400 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1174680094.3903.1.camel@rousalka.dyndns.org> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174680094.3903.1.camel@rousalka.dyndns.org> Message-ID: <46043A44.1050003@redhat.com> Nicolas Mailhot wrote: > Le vendredi 23 mars 2007 ? 14:50 -0500, Jason L Tibbitts III a ?crit : >>>>>>> "TC" == Tom \"spot\" Callaway writes: >> TC> I have added a draft for handling Post Release packages. >> >> It might be worth mentioning what to do when upstream ODs on the >> crackrock and unexpectedly changes to a non-ordered versioning scheme >> in the middle of a sequence. Something like: >> >> openssl-0.9.6g >> openssl-0.9.6h >> openssl-0.9.6final >> >> Epoch is probably the only way out here unless we allow something > > Just proves adding any non-numeric part to versions is a bad idea > Tom's text implies that if you take that route (alphas in versions) you are sure that the upstream guys are not doing that and that is only a single letter minor differentiator (i.e., it is just a single letter license indicator, a upward moving sequence like a,b,c...). If that cannot be guaranteed or the string is not that trivial, there is the use of releases similar to what is done for pre-release tags. Are you suggesting that the text should be more emphatic w.r.t. the risks of taking the first route, perhaps? Cheers, Fernando From nicolas.mailhot at laposte.net Fri Mar 23 21:03:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Mar 2007 22:03:04 +0100 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <46043A44.1050003@redhat.com> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174680094.3903.1.camel@rousalka.dyndns.org> <46043A44.1050003@redhat.com> Message-ID: <1174683784.4579.3.camel@rousalka.dyndns.org> Le vendredi 23 mars 2007 ? 16:36 -0400, Fernando Nasser a ?crit : > Tom's text implies that if you take that route (alphas in versions) you > are sure that the upstream guys are not doing that and that is only a > single letter minor differentiator (i.e., it is just a single letter > license indicator, a upward moving sequence like a,b,c...). > > If that cannot be guaranteed or the string is not that trivial, there is > the use of releases similar to what is done for pre-release tags. > > Are you suggesting that the text should be more emphatic w.r.t. the > risks of taking the first route, perhaps? We've seen time and time again upstreams do not consider themselves bound by any sanity rule when using letters/words. Any letter part in versions should be a red flag. -- 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 a.badger at gmail.com Fri Mar 23 21:18:33 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 23 Mar 2007 14:18:33 -0700 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> Message-ID: <1174684713.8986.54.camel@localhost.localdomain> On Fri, 2007-03-23 at 14:50 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom \"spot\" Callaway writes: > > TC> I have added a draft for handling Post Release packages. > > It might be worth mentioning what to do when upstream ODs on the > crackrock and unexpectedly changes to a non-ordered versioning scheme > in the middle of a sequence. Something like: > > openssl-0.9.6g > openssl-0.9.6h > openssl-0.9.6final > > Epoch is probably the only way out here unless we allow something > nasty. Note that this particular example would be very cracktastic as we're talking about postrelease tags.. so presumably upstream has already released openssl-0.9.6. Which is not to say that upstream's twisted numbering scheme won't do *something* unexpected. Which is one reason I'd rather see us use the %{X}.%{alphatag} syntax always. The other reason is that using it always makes things less complicated. Instead of asking:: Is this a prerelease or a postrelease? If postrelease, is upstream likely to use sane numbering? If no, use postrelease scheme If yes, use upstreams version until they screw up one time If prerelease, use prerelease scheme Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Mar 23 21:35:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 22:35:45 +0100 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <4604391C.2010201@redhat.com> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <4604391C.2010201@redhat.com> Message-ID: <20070323213545.GA21465@neu.nirvana> On Fri, Mar 23, 2007 at 04:31:24PM -0400, Fernando Nasser wrote: > Tom "spot" Callaway wrote: > >I have added a draft for handling Post Release packages. > > > >http://fedoraproject.org/wiki/PackagingDrafts/PostRelease > > > >Comments are always welcomed. > > > > It seems very consistent, and the text is well written. I like it! +1, if spot is looking for FPC votes. -- 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 Fri Mar 23 21:51:11 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 23 Mar 2007 16:51:11 -0500 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1174684713.8986.54.camel@localhost.localdomain> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174684713.8986.54.camel@localhost.localdomain> Message-ID: <1174686671.5072.32.camel@1cc-dhcp-162.media.mit.edu> On Fri, 2007-03-23 at 14:18 -0700, Toshio Kuratomi wrote: > Which is not to say that upstream's twisted numbering scheme won't do > *something* unexpected. Which is one reason I'd rather see us use the > %{X}.%{alphatag} syntax always. The other reason is that using it > always makes things less complicated. Instead of asking:: > > Is this a prerelease or a postrelease? > If postrelease, is upstream likely to use sane numbering? > If no, use postrelease scheme > If yes, use upstreams version until they screw up one time > If prerelease, use prerelease scheme > > Our rule would be:: > Does upstreams version have an alpha tag? > If yes, use alphatag versioning. I'm not opposed to this. I wonder how many examples of the old model are actually in Fedora. ~spot From Axel.Thimm at ATrpms.net Sat Mar 24 00:52:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 24 Mar 2007 01:52:08 +0100 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <1174684713.8986.54.camel@localhost.localdomain> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174684713.8986.54.camel@localhost.localdomain> Message-ID: <20070324005208.GB25468@neu.nirvana> On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote: > On Fri, 2007-03-23 at 14:50 -0500, Jason L Tibbitts III wrote: > > >>>>> "TC" == Tom \"spot\" Callaway writes: > > > > TC> I have added a draft for handling Post Release packages. > > > > It might be worth mentioning what to do when upstream ODs on the > > crackrock and unexpectedly changes to a non-ordered versioning scheme > > in the middle of a sequence. Something like: > > > > openssl-0.9.6g > > openssl-0.9.6h > > openssl-0.9.6final > > > > Epoch is probably the only way out here unless we allow something > > nasty. > > Note that this particular example would be very cracktastic as we're > talking about postrelease tags.. so presumably upstream has already > released openssl-0.9.6. > > Which is not to say that upstream's twisted numbering scheme won't do > *something* unexpected. That's true for purely numerical schemes as well. Looking at perl and perl modules a rpm packager gets head-aches. > Which is one reason I'd rather see us use the %{X}.%{alphatag} > syntax always. The other reason is that using it always makes > things less complicated. Instead of asking:: > > Is this a prerelease or a postrelease? > If postrelease, is upstream likely to use sane numbering? > If no, use postrelease scheme > If yes, use upstreams version until they screw up one time > If prerelease, use prerelease scheme > > Our rule would be:: > Does upstreams version have an alpha tag? > If yes, use alphatag versioning. The point is that we don't really want too many of the prereleases and therefore don't care about the (temporary) obfuscation that much (not that we could do anything better anyway). But with "postreleases" it's quite different. openssl is a prominent example where people will be confused to see openssl-0.9.8-8.3.b.fc6 instead of what we currently have: openssl-0.9.8b-8.3.fc6. Other prominent or not so prominent examples I find on my system are openssh-4.3p2-14.fc6, libjpeg-6b-37, automake14-1.4p6-13, flex-2.5.4a-41.fc6, tzdata-2007c-1.fc6, ntp-4.2.4p0-1.fc6, setuptools-0.6c2-5.fc6.at, man-1.6d-2.fc6, libcdaudio-0.99.12p2-8.fc6.at. I agree that letters in versioning are a bad thing, but we should try to get that done upstream, and try to stick as much as technically sane to upstream versioning (e.g. epochs are not considered sane in this context). -- 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 tibbs at math.uh.edu Sat Mar 24 03:48:13 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Mar 2007 22:48:13 -0500 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <20070324005208.GB25468@neu.nirvana> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174684713.8986.54.camel@localhost.localdomain> <20070324005208.GB25468@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I agree that letters in versioning are a bad thing, but we should AT> try to get that done upstream, and try to stick as much as AT> technically sane to upstream versioning (e.g. epochs are not AT> considered sane in this context). I don't disagree, but if we're going to say that packagers should use alphanumeric versioning when there's a reasonable expectation that it will remain sanely ordered, we should at least give some thought as to what to recommend in the case that upstream decides to abandon sanity. Epochs are the default out here, I think. In some situations there may be other outs. In a related case I've advocated using a version like "1.2release" when a packager disliked Epoch:, ignored the guidelines, used a version like "1.2beta2", and got stuck. Not terribly pretty, but it only has to last until the next version bump whereas Epoch is forever. Anyway, I don't want to derail the discussion, and I agree with what's in the draft. We can add additional advice as necessary. - J< From nicolas.mailhot at laposte.net Sat Mar 24 12:15:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 24 Mar 2007 13:15:50 +0100 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <20070324005208.GB25468@neu.nirvana> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174684713.8986.54.camel@localhost.localdomain> <20070324005208.GB25468@neu.nirvana> Message-ID: <1174738550.7719.7.camel@rousalka.dyndns.org> Le samedi 24 mars 2007 ? 01:52 +0100, Axel Thimm a ?crit : > On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote: > > Our rule would be:: > > Does upstreams version have an alpha tag? > > If yes, use alphatag versioning. > > The point is that we don't really want too many of the prereleases and > therefore don't care about the (temporary) obfuscation that much (not > that we could do anything better anyway). > > But with "postreleases" it's quite different. openssl is a prominent > example where people will be confused to see openssl-0.9.8-8.3.b.fc6 > instead of what we currently have: openssl-0.9.8b-8.3.fc6. IMHO people (both users and packagers) will be confused if we don't follow consistent rules. The "what if we can reasonably expect upstream to be sane" argument has been rejected for pre-releases (and we've forced the java folks to change their rules accordingly) I really don't see why it should apply for post releases "But we've done differently in the past" is a weak argument. In the past we had incomplete BRs and broken EVR upgrade paths, we changed stuff to fix it, and people weren't confused. Lastly consistent rules means we can hope to built them in some future rpm version instead of relying on guidelines, now that rpm dev has resumed. -- 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 Axel.Thimm at ATrpms.net Sat Mar 24 13:06:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 24 Mar 2007 14:06:53 +0100 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <1174738550.7719.7.camel@rousalka.dyndns.org> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <1174684713.8986.54.camel@localhost.localdomain> <20070324005208.GB25468@neu.nirvana> <1174738550.7719.7.camel@rousalka.dyndns.org> Message-ID: <20070324130653.GA27848@neu.nirvana> On Sat, Mar 24, 2007 at 01:15:50PM +0100, Nicolas Mailhot wrote: > Le samedi 24 mars 2007 ? 01:52 +0100, Axel Thimm a ?crit : > > On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote: > > > > Our rule would be:: > > > Does upstreams version have an alpha tag? > > > If yes, use alphatag versioning. > > > > The point is that we don't really want too many of the prereleases and > > therefore don't care about the (temporary) obfuscation that much (not > > that we could do anything better anyway). > > > > But with "postreleases" it's quite different. openssl is a prominent > > example where people will be confused to see openssl-0.9.8-8.3.b.fc6 > > instead of what we currently have: openssl-0.9.8b-8.3.fc6. > > IMHO people (both users and packagers) will be confused if we don't > follow consistent rules. The "what if we can reasonably expect upstream > to be sane" argument has been rejected for pre-releases No, why do you say so? We are promoting upstream to use even/odd schemes or 1.2.99 schemes (for prereleases to 1.3). If it plays well with rpm, why break it? > "But we've done differently in the past" is a weak argument. In the past > we had incomplete BRs and broken EVR upgrade paths, we changed stuff to > fix it, and people weren't confused. Well, consider a dependency on openssl >= 0.9.8b. If the postrelease letter slides into the release then suddenly we need to know about build-ids in comparisons like >= 0.9.8-X.b. Dependencies force us to leave the versioning rather uncumbered. > Lastly consistent rules means we can hope to built them in some future > rpm version instead of relying on guidelines, now that rpm dev has > resumed. I don't think the rpmvercmp will ever change, no matter how active rpm development is. This is being discussed since rpm was born and the point is no matter how you try to adjust to upstream versioning some upstream authors will be clever enough to break any machine ordering scheme. -- 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 jeremy at hinegardner.org Wed Mar 28 17:05:02 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Wed, 28 Mar 2007 11:05:02 -0600 Subject: [Fedora-packaging] Packaging of ruby gems In-Reply-To: <1173404848.3331.53.camel@localhost.localdomain> References: <1173404848.3331.53.camel@localhost.localdomain> Message-ID: <20070328170502.GA4034@hinegardner.org> On Thu, Mar 08, 2007 at 05:47:28PM -0800, David Lutterkort wrote: > At long last, I wrote up a guideline [1] for packaging ruby gems, ruby's > own packaging format; since almost any ruby library is packaged as a > gem, and some of them provide no other way of installation, it becomes > increasingly important to enable packaging of gems for Fedora. > > At the same time, it is fairly easy to automate most of this process[2], > which hopefully means that lots of people will submit packages of ruby > gems. > > You can find some examples of ruby gems packaged as rpm's on my people > page [3] - look for specfiles called 'rubygem-*' I just became a packager and am very interested in making sure Fedora and rubygems work well together. I'll try packaging up a couple of gems with your guidelines in the next week or so and see how it goes. I may have comments or suggestions afterwards. Have you given thought to gems that are also applications? I have an application 'keybox' that is a gem, but it is really a command line application, at what point would we want to draw the line between saying package this as a rubygems-* vs. a normal package that just Requires: ruby and maybe some rubygems-*. Or would you rather think of rubygems-* as being packaged from the gem and anything that was self contained be packaged from the .tgz or the original source? enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From fedora at leemhuis.info Wed Mar 28 17:19:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 19:19:17 +0200 Subject: [Fedora-packaging] to fuse- prefix or not to fuse- preifx Message-ID: <460AA395.3060307@leemhuis.info> Hi, I searched for a fuse solution for ftp/gmail today and noticed that we have four fuse files systems with fuse- prefix in Fedora: $ yum list fuse-* [...] fuse-convmvfs.i386 0.2.3-2.fc7 fuse-encfs.i386 1.3.1-3.fc6 fuse-smb.i386 0.8.5-5.fc7 fuse-sshfs.i386 1.7-2.fc6 [...] And at least two without: $ yum list ntfs-3g curlftpfs [...] curlftpfs.i386 0.9-3.fc7 ntfs-3g.i386 2:1.0-1.fc7 [...] :-( Do we care about that mismatch? Should we rename the two latter in the long term just to be consistent? I tend to say "yes", so users that search like I did (yum list fuse-*) don't get taken into the wrong direction. Yes, it's just a small detail, but having some package with prefix and some without is IMHO just confusing. CU thl From Axel.Thimm at ATrpms.net Wed Mar 28 17:38:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Mar 2007 19:38:35 +0200 Subject: [Fedora-packaging] Re: to fuse- prefix or not to fuse- preifx In-Reply-To: <460AA395.3060307@leemhuis.info> References: <460AA395.3060307@leemhuis.info> Message-ID: <20070328173835.GE32452@neu.nirvana> On Wed, Mar 28, 2007 at 07:19:17PM +0200, Thorsten Leemhuis wrote: > Hi, > > I searched for a fuse solution for ftp/gmail today and noticed that we > have four fuse files systems with fuse- prefix in Fedora: > > $ yum list fuse-* > [...] > fuse-convmvfs.i386 0.2.3-2.fc7 > fuse-encfs.i386 1.3.1-3.fc6 > fuse-smb.i386 0.8.5-5.fc7 > fuse-sshfs.i386 1.7-2.fc6 > [...] > > And at least two without: > > $ yum list ntfs-3g curlftpfs > [...] > curlftpfs.i386 0.9-3.fc7 > ntfs-3g.i386 2:1.0-1.fc7 > [...] > > :-( > > Do we care about that mismatch? Should we rename the two latter in the > long term just to be consistent? I tend to say "yes", so users that > search like I did (yum list fuse-*) don't get taken into the wrong > direction. > > Yes, it's just a small detail, but having some package with prefix and > some without is IMHO just confusing. Some time back there was the opposite request to remove the prefix, supposedly even uttered by upstream. Personally I'd prefer it to keep the prefix. Imagine fuse-ext2 w/o the prefix :) -- 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 a.badger at gmail.com Wed Mar 28 17:48:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 28 Mar 2007 10:48:04 -0700 Subject: [Fedora-packaging] Re: to fuse- prefix or not to fuse- preifx In-Reply-To: <20070328173835.GE32452@neu.nirvana> References: <460AA395.3060307@leemhuis.info> <20070328173835.GE32452@neu.nirvana> Message-ID: <1175104084.16371.87.camel@localhost.localdomain> On Wed, 2007-03-28 at 19:38 +0200, Axel Thimm wrote: > On Wed, Mar 28, 2007 at 07:19:17PM +0200, Thorsten Leemhuis wrote: > > And at least two without: > > > > $ yum list ntfs-3g curlftpfs > > [...] > > curlftpfs.i386 0.9-3.fc7 > > ntfs-3g.i386 2:1.0-1.fc7 > > [...] > > > > :-( > > > > Do we care about that mismatch? Should we rename the two latter in the > > long term just to be consistent? I tend to say "yes", so users that > > search like I did (yum list fuse-*) don't get taken into the wrong > > direction. > > > > Yes, it's just a small detail, but having some package with prefix and > > some without is IMHO just confusing. > > Some time back there was the opposite request to remove the prefix, > supposedly even uttered by upstream. > > Personally I'd prefer it to keep the prefix. Imagine fuse-ext2 w/o the > prefix :) I like the prefix as well. If upstream is pushing to not have the prefix we're between a rock and a hard place. Upstream really has no business deciding on rpm-package names... but making them angry at us is the path to despair. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Mar 28 17:52:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 19:52:38 +0200 Subject: [Fedora-packaging] Re: to fuse- prefix or not to fuse- preifx In-Reply-To: <20070328173835.GE32452@neu.nirvana> References: <460AA395.3060307@leemhuis.info> <20070328173835.GE32452@neu.nirvana> Message-ID: <460AAB66.2020908@leemhuis.info> Axel Thimm schrieb: > On Wed, Mar 28, 2007 at 07:19:17PM +0200, Thorsten Leemhuis wrote: >> I searched for a fuse solution for ftp/gmail today and noticed that we >> have four fuse files systems with fuse- prefix in Fedora: >> >> $ yum list fuse-* >> [...] >> fuse-convmvfs.i386 0.2.3-2.fc7 >> fuse-encfs.i386 1.3.1-3.fc6 >> fuse-smb.i386 0.8.5-5.fc7 >> fuse-sshfs.i386 1.7-2.fc6 >> [...] >> >> And at least two without: >> >> $ yum list ntfs-3g curlftpfs >> [...] >> curlftpfs.i386 0.9-3.fc7 >> ntfs-3g.i386 2:1.0-1.fc7 >> [...] >> >> :-( >> >> Do we care about that mismatch? Should we rename the two latter in the >> long term just to be consistent? I tend to say "yes", so users that >> search like I did (yum list fuse-*) don't get taken into the wrong >> direction. >> >> Yes, it's just a small detail, but having some package with prefix and >> some without is IMHO just confusing. > > Some time back there was the opposite request to remove the prefix, > supposedly even uttered by upstream. The real "just make it work" solution might be use the prefix and also provide the prefix-less name , and teach "yum list" and other utils to list the provides, too. (just a thought that came up, not sure if this really is a good idea...) > Personally I'd prefer it to keep the prefix. Imagine fuse-ext2 w/o the > prefix :) Hehe, agreed :-) CU thl From jwilson at redhat.com Wed Mar 28 19:45:01 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Mar 2007 15:45:01 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? Message-ID: <460AC5BD.6090107@redhat.com> I'd like to package up Maia Mailguard, and the license appears to be original BSD (advertising clause included) with a branding extension added. Thoughts? http://www.maiamailguard.org/license.php -- 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 tibbs at math.uh.edu Wed Mar 28 20:09:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Mar 2007 15:09:41 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460AC5BD.6090107@redhat.com> References: <460AC5BD.6090107@redhat.com> Message-ID: >>>>> "JW" == Jarod Wilson writes: JW> I'd like to package up Maia Mailguard, and the license appears to JW> be original BSD (advertising clause included) with a branding JW> extension added. Thoughts? In a way it's sort of like the GFDL with its invariant section. I personally think that kind of thing renders the software "non-free", but I'm not a lawyer. See also http://lists.debian.org/debian-legal/2005/02/msg00178.html - J< From ssorce at redhat.com Wed Mar 28 20:50:48 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2007 16:50:48 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: References: <460AC5BD.6090107@redhat.com> Message-ID: <1175115048.32396.36.camel@willson> On Wed, 2007-03-28 at 15:09 -0500, Jason L Tibbitts III wrote: > >>>>> "JW" == Jarod Wilson writes: > > JW> I'd like to package up Maia Mailguard, and the license appears to > JW> be original BSD (advertising clause included) with a branding > JW> extension added. Thoughts? > > In a way it's sort of like the GFDL with its invariant section. I > personally think that kind of thing renders the software "non-free", > but I'm not a lawyer. Not sure if that license is free, to me it stinks, but in any case the GFDL is a Documentation License, not a Software License, let's keep apples to apples comparisons, and let's try to not get infected by the Debian disease about defining what is software. Simo. From tibbs at math.uh.edu Wed Mar 28 21:23:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Mar 2007 16:23:12 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <1175115048.32396.36.camel@willson> References: <460AC5BD.6090107@redhat.com> <1175115048.32396.36.camel@willson> Message-ID: >>>>> "SS" == Simo Sorce writes: SS> Not sure if that license is free, to me it stinks, but in any case SS> the GFDL is a Documentation License, not a Software License, I haven't written otherwise. SS> let's keep apples to apples comparisons, and let's try to not get SS> infected by the Debian disease about defining what is software. We frequently make use of research that the Debian folks have done, and anything which is not acceptable to them bears strong scrutiny before we consider it acceptable for Fedora. If you wish to characterize their efforts as some sort of illness then that's your business but please concentrate on reasonable discourse here. - J< From jwilson at redhat.com Wed Mar 28 21:53:31 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Mar 2007 17:53:31 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: References: <460AC5BD.6090107@redhat.com> <1175115048.32396.36.camel@willson> Message-ID: <460AE3DB.2040708@redhat.com> Jason L Tibbitts III wrote: >>>>>> "SS" == Simo Sorce writes: > > SS> Not sure if that license is free, to me it stinks, but in any case > SS> the GFDL is a Documentation License, not a Software License, > > I haven't written otherwise. > > SS> let's keep apples to apples comparisons, and let's try to not get > SS> infected by the Debian disease about defining what is software. > > We frequently make use of research that the Debian folks have done, > and anything which is not acceptable to them bears strong scrutiny > before we consider it acceptable for Fedora. If you wish to > characterize their efforts as some sort of illness then that's your > business but please concentrate on reasonable discourse here. Yeah, I figured section 4 might be an issue... I'm definitely not a lawyer either, and the license isn't optimal, but what exactly stops us from packaging it? (Not trying to be difficult, just trying to understand). We'd be packaging it in a way that satisfies 4a, and users are welcome to modify it once its installed on their system. Or is the fact that you couldn't change the branding for redistribution if you wanted to enough to give it the boot? -- 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 jwilson at redhat.com Wed Mar 28 21:55:50 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Mar 2007 17:55:50 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460AE3DB.2040708@redhat.com> References: <460AC5BD.6090107@redhat.com> <1175115048.32396.36.camel@willson> <460AE3DB.2040708@redhat.com> Message-ID: <460AE466.9030406@redhat.com> Jarod Wilson wrote: > Jason L Tibbitts III wrote: >>>>>>> "SS" == Simo Sorce writes: >> SS> Not sure if that license is free, to me it stinks, but in any case >> SS> the GFDL is a Documentation License, not a Software License, >> >> I haven't written otherwise. >> >> SS> let's keep apples to apples comparisons, and let's try to not get >> SS> infected by the Debian disease about defining what is software. >> >> We frequently make use of research that the Debian folks have done, >> and anything which is not acceptable to them bears strong scrutiny >> before we consider it acceptable for Fedora. If you wish to >> characterize their efforts as some sort of illness then that's your >> business but please concentrate on reasonable discourse here. > > Yeah, I figured section 4 might be an issue... > > I'm definitely not a lawyer either, and the license isn't optimal, but > what exactly stops us from packaging it? (Not trying to be difficult, > just trying to understand). We'd be packaging it in a way that satisfies > 4a, and users are welcome to modify it once its installed on their > system. Or is the fact that you couldn't change the branding for > redistribution if you wanted to enough to give it the boot? Another thing to consider... How different is this from the Firefox case? -- 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 tibbs at math.uh.edu Wed Mar 28 22:55:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Mar 2007 17:55:01 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460AE466.9030406@redhat.com> References: <460AC5BD.6090107@redhat.com> <1175115048.32396.36.camel@willson> <460AE3DB.2040708@redhat.com> <460AE466.9030406@redhat.com> Message-ID: >>>>> "JW" == Jarod Wilson writes: JW> Another thing to consider... How different is this from the JW> Firefox case? Firefox has no requirement that it carry any display or notice as far as I know. In fact, Debian removes these completely. The license in question explicitly prohibits this. It seems to be in fact the polar opposite from the Firefox case. - J< From tcallawa at redhat.com Thu Mar 29 00:19:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Mar 2007 19:19:44 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460AC5BD.6090107@redhat.com> References: <460AC5BD.6090107@redhat.com> Message-ID: <1175127584.3741.7.camel@localhost.localdomain> On Wed, 2007-03-28 at 15:45 -0400, Jarod Wilson wrote: > I'd like to package up Maia Mailguard, and the license appears to be > original BSD (advertising clause included) with a branding extension > added. Thoughts? > > http://www.maiamailguard.org/license.php Sent to the FSF for feedback. We'll see what they say. ~spot From jwilson at redhat.com Thu Mar 29 02:47:03 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Mar 2007 22:47:03 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: References: <460AC5BD.6090107@redhat.com> <1175115048.32396.36.camel@willson> <460AE3DB.2040708@redhat.com> <460AE466.9030406@redhat.com> Message-ID: <460B28A7.2020608@redhat.com> Jason L Tibbitts III wrote: >>>>>> "JW" == Jarod Wilson writes: > > JW> Another thing to consider... How different is this from the > JW> Firefox case? > > Firefox has no requirement that it carry any display or notice as far > as I know. In fact, Debian removes these completely. The license in > question explicitly prohibits this. It seems to be in fact the polar > opposite from the Firefox case. I think I was somehow abstractly attempting to tie them together via "mostly free, but has some sort of restriction relating to included graphics, which is what made debian give it the boot". Or something. Okay, just ignore that thought. -- Jarod Wilson jwilson at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Thu Mar 29 14:13:19 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 29 Mar 2007 23:13:19 +0900 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> Message-ID: <460BC97F.106@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote: > I have added a draft for handling Post Release packages. > > http://fedoraproject.org/wiki/PackagingDrafts/PostRelease > > Comments are always welcomed. > > ~spot I would appreciate it if you would argue the case in which upstream uses the tarball like --.tar.gz. One case is ImageMagick, and the other case is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560 Mamoru From rc040203 at freenet.de Thu Mar 29 14:17:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Mar 2007 16:17:04 +0200 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <460BC97F.106@ioa.s.u-tokyo.ac.jp> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> Message-ID: <1175177824.24401.177.camel@mccallum.corsepiu.local> On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote: > Tom "spot" Callaway wrote: > > I have added a draft for handling Post Release packages. > > > > http://fedoraproject.org/wiki/PackagingDrafts/PostRelease > > > > Comments are always welcomed. > > > > ~spot > > I would appreciate it if you would argue the case > in which upstream uses the tarball like > > --.tar.gz. > > One case is ImageMagick, and the other case is: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560 IMO, in such cases the upstream "version-release" should be treated as rpm's "version" Ralf From tibbs at math.uh.edu Thu Mar 29 18:19:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Mar 2007 13:19:09 -0500 Subject: [Fedora-packaging] FESCO responses to PC drafts 2007-03-29 Message-ID: I figure it's worth writing this up. PackagingDrafts/PostRelease FESCO approves, but Warren would like a comment added to the effect that packagers should document in the specfile any weird upstream versioning conventions which they're trying to massage into a sortable RPM EVR. I indicated that I did not believe that the PC would have any issue with adding such a comment. PackagingDrafts/ExtraDistTagConditionalMacros FESCO is onboard here, but the issue is down to implementation. And of course there's an ongoing thread in fedora-devel. PackagingDrafts/Utf8Filenames FESCO approves. - J< From pcheung at redhat.com Fri Mar 30 02:08:16 2007 From: pcheung at redhat.com (Permaine Cheung) Date: Thu, 29 Mar 2007 22:08:16 -0400 Subject: [Fedora-packaging] license for concurrent package Message-ID: <460C7110.2000508@redhat.com> Hi, The concurrent package in core has stated the following (under the Notes section of its URL http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html): 'All classes are released to the public domain and may be used for any purpose whatsoever without permission or acknowledgment. Portions of the CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted from Sun JDK source code. These are copyright of Sun Microsystems, Inc, and are used with their kind permission,' (link is http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.pdf) And further down from that page it states: 'Do I need a license to use it? Can I get one? No!' Is this okay? Thanks, Permaine From dlutter at redhat.com Fri Mar 30 02:45:15 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 29 Mar 2007 19:45:15 -0700 Subject: [Fedora-packaging] Missing meeting on 2007-04-02 Message-ID: <1175222715.29210.96.camel@localhost.localdomain> Hi guys, I will have to miss the next meeting since I will be locked all day in a conference room somewhere. sorry, David From dlutter at redhat.com Fri Mar 30 02:55:12 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 29 Mar 2007 19:55:12 -0700 Subject: [Fedora-packaging] Packaging of ruby gems In-Reply-To: <20070328170502.GA4034@hinegardner.org> References: <1173404848.3331.53.camel@localhost.localdomain> <20070328170502.GA4034@hinegardner.org> Message-ID: <1175223312.29210.107.camel@localhost.localdomain> On Wed, 2007-03-28 at 11:05 -0600, Jeremy Hinegardner wrote: > On Thu, Mar 08, 2007 at 05:47:28PM -0800, David Lutterkort wrote: > > At long last, I wrote up a guideline [1] for packaging ruby gems, ruby's > > own packaging format; since almost any ruby library is packaged as a > > gem, and some of them provide no other way of installation, it becomes > > increasingly important to enable packaging of gems for Fedora. > > > > At the same time, it is fairly easy to automate most of this process[2], > > which hopefully means that lots of people will submit packages of ruby > > gems. > > > > You can find some examples of ruby gems packaged as rpm's on my people > > page [3] - look for specfiles called 'rubygem-*' > > I just became a packager and am very interested in making sure Fedora > and rubygems work well together. I'll try packaging up a couple of gems > with your guidelines in the next week or so and see how it goes. I may > have comments or suggestions afterwards. Excellent .. the rubygems proposal right now is stalled since I need to try out how/whether we could package the same ruby library as a gem and non-gem. Assum that we have rubygem-activerecord, which just installs the gem, and that somebody needs to have ruby-activerecord since they don't want to use gems for their application (it's somewhat remote but possible as long as gems aren't a completely official part of the ruby) What I need to try is if we can get away for the ruby-activerecord package to just contain symlinks that go from /usr/lib/ruby/site_ruby/1.8/* to /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/* so that we don't really install the same bits twice > Have you given thought to gems that are also applications? I have an > application 'keybox' that is a gem, but it is really a command line > application, at what point would we want to draw the line between saying > package this as a rubygems-* vs. a normal package that just Requires: > ruby and maybe some rubygems-*. I would use hte same rule as for general ruby packages here: if the main purpose of the gem is a library, it should be called rubygem-*; if the main purpose of the gem is as an application and users don't really care what language it is written in, I would call it just the name of the application, i.e. 'keybox' in that case > Or would you rather think of rubygems-* as being packaged from the gem > and anything that was self contained be packaged from the .tgz or the > original source? That should be up to the packager, though I would guess that once we have rubygems guidelines, the lion's share of ruby code will be packaged from the gems, not from tarballs, since that is the normal, tested way of installation for a lot of upstream projects. David From mefoster at gmail.com Fri Mar 30 09:45:30 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Fri, 30 Mar 2007 11:45:30 +0200 Subject: [Fedora-packaging] Building a set of packages where some BuildRequire others Message-ID: I'm currently trying to create Fedora-compliant packages of the Internet Communications Engine (Ice) -- object-oriented middleware, see http://www.zeroc.com/ for details. They used to provide a yum repository for Fedora, but with the new version they've stopped. I'm now working on adapt their SRPMS to Fedora packaging standards. (If anyone else has done / is doing this, let me know!) I've managed to create a few packages, in the process learning a lot more about RPM tricks and so on. One issue I'm having -- and I'm pretty sure it's unavoidable -- is that many of the packages have build-time requirements on other packages. For example, the tool to translate ice interfaces into Java code is called "slice2java" and is part of the ice-java-devel package; this tool is then needed to build the ice-java runtime package. What's the accepted way of building something with this type of constraints in mock? Should I just build temporary versions of the necessary tools as needed (e.g., let ice-java compile its own version of "slice2java" just for use in the build process)? I'd rather not do that, but if it's necessary I can do things that way. Thanks for any suggestions! MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From Axel.Thimm at ATrpms.net Fri Mar 30 10:37:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Mar 2007 12:37:05 +0200 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: References: Message-ID: <20070330103705.GD30970@neu.nirvana> On Fri, Mar 30, 2007 at 11:45:30AM +0200, Mary Ellen Foster wrote: > I'm currently trying to create Fedora-compliant packages of the > Internet Communications Engine (Ice) -- object-oriented middleware, > see http://www.zeroc.com/ for details. They used to provide a yum > repository for Fedora, but with the new version they've stopped. I'm > now working on adapt their SRPMS to Fedora packaging standards. (If > anyone else has done / is doing this, let me know!) > > I've managed to create a few packages, in the process learning a lot > more about RPM tricks and so on. One issue I'm having -- and I'm > pretty sure it's unavoidable -- is that many of the packages have > build-time requirements on other packages. For example, the tool to > translate ice interfaces into Java code is called "slice2java" and is > part of the ice-java-devel package; this tool is then needed to build > the ice-java runtime package. Are ice-java-devel and ice-java subpackages of the same build? If yes, you can use slice2java within one specfile. If not, then the naming is a bit awkward, but what would stop you from using BuildRequires: ice-java-devel in ice-java? Or is ice-java-devel dependent on ice-java, e.g. you have a circular build dependency, e.g. a bootstraping problem? > What's the accepted way of building something with this type of > constraints in mock? Should I just build temporary versions of the > necessary tools as needed (e.g., let ice-java compile its own version > of "slice2java" just for use in the build process)? I'd rather not do > that, but if it's necessary I can do things that way. If it's a bootstraping problem, either do ice-java and ice-java-devel in one source package, so no build dependencies to external packages arise, or if that's not an option you need some special bootstraping attendance by both the FPC and the build admins. -- 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 rc040203 at freenet.de Fri Mar 30 10:42:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 30 Mar 2007 12:42:55 +0200 Subject: [Fedora-packaging] Building a set of packages where some BuildRequire others In-Reply-To: References: Message-ID: <1175251376.24401.258.camel@mccallum.corsepiu.local> On Fri, 2007-03-30 at 11:45 +0200, Mary Ellen Foster wrote: > I've managed to create a few packages, in the process learning a lot > more about RPM tricks and so on. One issue I'm having -- and I'm > pretty sure it's unavoidable Well, it must be avoidable, ... ;) > -- is that many of the packages have > build-time requirements on other packages. For example, the tool to > translate ice interfaces into Java code is called "slice2java" and is > part of the ice-java-devel package; this tool is then needed to build > the ice-java runtime package. This problem is commonly known as "circular package dependencies" and as "bootstrapping". Unfortunately, there is no general recipe to resolve such kind of problems. > What's the accepted way of building something with this type of > constraints in mock? Should I just build temporary versions of the > necessary tools as needed (e.g., let ice-java compile its own version > of "slice2java" just for use in the build process)? I'd rather not do > that, but if it's necessary I can do things that way. This would be a means of least resort. The problem you describe sounds like the classical "using built-tool generated sources" to me. Normally such issues can be resolved by one of the steps below: - Serialize building: First build the tool's minial infrastructure, then the tool, then the final package. If this isn't possible, upstream suffers from a severe design flaw. - Ship pregenerated versions instead of building them on the fly: I.e. add a patch containing all those files which should be generated by a tool, then don't use this tool. This is the approach commonly applied to yacc/lex sources. - Incremental building: Build the package using the "-1" version as tools. This is error prone and risky (This approach will break should a package change significantly between version) - Include a prebuild binary of the tool into the sources. Very hard to handle in practice. Fortunately, in most cases, circular deps indicate packaging bugs, which can be circumvented by changing a package's sub-package split and applying the first 2 steps from my list above. > Thanks for any suggestions! I'd suggest you to submit your package for review, such that others can actively assist you. Ralf From mefoster at gmail.com Fri Mar 30 11:07:07 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Fri, 30 Mar 2007 13:07:07 +0200 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: <20070330103705.GD30970@neu.nirvana> References: <20070330103705.GD30970@neu.nirvana> Message-ID: On 30/03/07, Axel Thimm wrote: > Are ice-java-devel and ice-java subpackages of the same build? If yes, > you can use slice2java within one specfile. If not, then the naming is > a bit awkward, but what would stop you from using BuildRequires: > ice-java-devel in ice-java? Or is ice-java-devel dependent on > ice-java, e.g. you have a circular build dependency, e.g. a > bootstraping problem? I'm using the upstream package names for now; maybe I should rename them to "ice-java" and "ice-java-runtime" or something like that. Unfortunately, these two packages can't be built from the same SRPM, because the runtime is noarch (only jar files) while the development stuff contains binaries (a translator written in C++ to convert ice files into Java source). Or is it possible to use the same SRPM to generate both arch and noarch packages simultaneously? If so, that would make my life simpler ... I'll try to put up some packages for review in the next day or two. MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From Axel.Thimm at ATrpms.net Fri Mar 30 11:31:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Mar 2007 13:31:06 +0200 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: References: <20070330103705.GD30970@neu.nirvana> Message-ID: <20070330113106.GI30970@neu.nirvana> On Fri, Mar 30, 2007 at 01:07:07PM +0200, Mary Ellen Foster wrote: > On 30/03/07, Axel Thimm wrote: > >Are ice-java-devel and ice-java subpackages of the same build? If yes, > >you can use slice2java within one specfile. If not, then the naming is > >a bit awkward, but what would stop you from using BuildRequires: > >ice-java-devel in ice-java? Or is ice-java-devel dependent on > >ice-java, e.g. you have a circular build dependency, e.g. a > >bootstraping problem? > > I'm using the upstream package names for now; maybe I should rename > them to "ice-java" and "ice-java-runtime" or something like that. > Unfortunately, these two packages can't be built from the same SRPM, > because the runtime is noarch (only jar files) while the development > stuff contains binaries (a translator written in C++ to convert ice > files into Java source). > > Or is it possible to use the same SRPM to generate both arch and > noarch packages simultaneously? If so, that would make my life simpler > ... No, not in the same build. The question is now, do "ice-java" and "ice-java-runtime" both require each other at build-time? -- 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 foster at in.tum.de Fri Mar 30 12:09:53 2007 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Mar 2007 14:09:53 +0200 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: <20070330113106.GI30970@neu.nirvana> References: <20070330103705.GD30970@neu.nirvana> <20070330113106.GI30970@neu.nirvana> Message-ID: On 30/03/07, Axel Thimm wrote: > > Or is it possible to use the same SRPM to generate both arch and > > noarch packages simultaneously? If so, that would make my life simpler > > ... > > No, not in the same build. > > The question is now, do "ice-java" and "ice-java-runtime" both require > each other at build-time? No; the runtime requires the development stuff, but not vice versa. I'm making packages right now in which the runtime builds its own private copy of slice2java and uses it in the build process. This seems to be easier as a first step than enforcing a particular build and installation order. MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From tcallawa at redhat.com Fri Mar 30 13:19:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Mar 2007 08:19:27 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <1175127584.3741.7.camel@localhost.localdomain> References: <460AC5BD.6090107@redhat.com> <1175127584.3741.7.camel@localhost.localdomain> Message-ID: <1175260767.7124.8.camel@localhost.localdomain> On Wed, 2007-03-28 at 19:19 -0500, Tom "spot" Callaway wrote: > On Wed, 2007-03-28 at 15:45 -0400, Jarod Wilson wrote: > > I'd like to package up Maia Mailguard, and the license appears to be > > original BSD (advertising clause included) with a branding extension > > added. Thoughts? > > > > http://www.maiamailguard.org/license.php > > Sent to the FSF for feedback. We'll see what they say. The FSF says: The branding constitutes a restriction on people's rights to adapt the software for their own purposes. It doesn't just affect source comments or documentation (like the advertising clause does). So I believe this makes it nonfree. I can submit it to the OSI for approval, but I'm less and less comfortable with it at this time. ~spot From tcallawa at redhat.com Fri Mar 30 13:20:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Mar 2007 08:20:04 -0500 Subject: [Fedora-packaging] FESCO responses to PC drafts 2007-03-29 In-Reply-To: References: Message-ID: <1175260804.7124.10.camel@localhost.localdomain> On Thu, 2007-03-29 at 13:19 -0500, Jason L Tibbitts III wrote: > I figure it's worth writing this up. > > PackagingDrafts/PostRelease > FESCO approves, but Warren would like a comment added to the effect > that packagers should document in the specfile any weird upstream > versioning conventions which they're trying to massage into a > sortable RPM EVR. > > I indicated that I did not believe that the PC would have any issue > with adding such a comment. > > PackagingDrafts/ExtraDistTagConditionalMacros > FESCO is onboard here, but the issue is down to implementation. And > of course there's an ongoing thread in fedora-devel. > > PackagingDrafts/Utf8Filenames > FESCO approves. Thanks tibbs. :) ~spot From tcallawa at redhat.com Fri Mar 30 13:20:30 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Mar 2007 08:20:30 -0500 Subject: [Fedora-packaging] license for concurrent package In-Reply-To: <460C7110.2000508@redhat.com> References: <460C7110.2000508@redhat.com> Message-ID: <1175260830.7124.12.camel@localhost.localdomain> On Thu, 2007-03-29 at 22:08 -0400, Permaine Cheung wrote: > Hi, > > The concurrent package in core has stated the following (under the Notes > section of its URL > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html): > > > 'All classes are released to the public domain and may be used for any > purpose whatsoever without permission or acknowledgment. Portions of the > CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted > from Sun JDK source code. These are copyright of Sun Microsystems, Inc, > and are used with their kind permission,' (link is > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.pdf) > > And further down from that page it states: > 'Do I need a license to use it? Can I get one? No!' > > Is this okay? Yes. Public Domain is acceptable. ~spot From nicolas.mailhot at laposte.net Fri Mar 30 13:26:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 30 Mar 2007 15:26:41 +0200 (CEST) Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: References: <20070330103705.GD30970@neu.nirvana> <20070330113106.GI30970@neu.nirvana> Message-ID: <31764.192.54.193.51.1175261201.squirrel@rousalka.dyndns.org> Le Ven 30 mars 2007 14:09, Mary Ellen Foster a ?crit : > On 30/03/07, Axel Thimm wrote: >> > Or is it possible to use the same SRPM to generate both arch and >> > noarch packages simultaneously? If so, that would make my life simpler >> > ... >> >> No, not in the same build. >> >> The question is now, do "ice-java" and "ice-java-runtime" both require >> each other at build-time? > > No; the runtime requires the development stuff, but not vice versa. So what's the problem with building devel first ? That's trivially expressed with buildrequires. -- Nicolas Mailhot From foster at in.tum.de Fri Mar 30 13:32:09 2007 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Mar 2007 15:32:09 +0200 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: <31764.192.54.193.51.1175261201.squirrel@rousalka.dyndns.org> References: <20070330103705.GD30970@neu.nirvana> <20070330113106.GI30970@neu.nirvana> <31764.192.54.193.51.1175261201.squirrel@rousalka.dyndns.org> Message-ID: On 30/03/07, Nicolas Mailhot wrote: > So what's the problem with building devel first ? That's trivially > expressed with buildrequires. Building in mock, I think ... or is there a trick to make that work? MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From paul at city-fan.org Fri Mar 30 13:48:35 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 30 Mar 2007 14:48:35 +0100 Subject: [Fedora-packaging] Re: Building a set of packages where some BuildRequire others In-Reply-To: References: <20070330103705.GD30970@neu.nirvana> <20070330113106.GI30970@neu.nirvana> <31764.192.54.193.51.1175261201.squirrel@rousalka.dyndns.org> Message-ID: <460D1533.5070600@city-fan.org> Mary Ellen Foster wrote: > On 30/03/07, Nicolas Mailhot wrote: >> So what's the problem with building devel first ? That's trivially >> expressed with buildrequires. > > Building in mock, I think ... or is there a trick to make that work? Create a local repository for your development activities, and add it to your mock configuration. Build the devel package and put it in your local repository. It will then be available in mock for your subsequent runtime build, which will have the devel package as a buildrequire. Paul. From giallu at gmail.com Fri Mar 30 14:16:26 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 30 Mar 2007 16:16:26 +0200 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: References: Message-ID: sorry for the duplicate post, but I am afraid fedora-extras-list was not the best place for this... ---------- Forwarded message ---------- From: Gianluca Sforna Date: Mar 30, 2007 10:41 AM Subject: Licensing issue in mantis To: Discussion related to Fedora Extras Mantis (php) codebase includes a module which comes from a 3rd party project and is licensed with a "free for non commercial use" style clause which is, AFAICT, incompatible with the GPL. Is removing the offending file from the rpm package during %install enough? Is upstream compelled to remove it as well? From rdieter at math.unl.edu Fri Mar 30 14:23:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Mar 2007 09:23:12 -0500 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: References: Message-ID: <460D1D50.8000804@math.unl.edu> Gianluca Sforna wrote: > sorry for the duplicate post, but I am afraid fedora-extras-list was > not the best place for this... > > ---------- Forwarded message ---------- > From: Gianluca Sforna > Date: Mar 30, 2007 10:41 AM > Subject: Licensing issue in mantis > To: Discussion related to Fedora Extras > > > Mantis (php) codebase includes a module which comes from a 3rd party > project and is licensed with a "free for non commercial use" style > clause which is, AFAICT, incompatible with the GPL. > Is removing the offending file from the rpm package during %install enough? Yes (imo). -- Rex From rdieter at math.unl.edu Fri Mar 30 14:25:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Mar 2007 09:25:44 -0500 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: <460D1D50.8000804@math.unl.edu> References: <460D1D50.8000804@math.unl.edu> Message-ID: <460D1DE8.4060802@math.unl.edu> Rex Dieter wrote: > Gianluca Sforna wrote: >> sorry for the duplicate post, but I am afraid fedora-extras-list was >> not the best place for this... >> >> ---------- Forwarded message ---------- >> From: Gianluca Sforna >> Date: Mar 30, 2007 10:41 AM >> Subject: Licensing issue in mantis >> To: Discussion related to Fedora Extras >> >> >> Mantis (php) codebase includes a module which comes from a 3rd party >> project and is licensed with a "free for non commercial use" style >> clause which is, AFAICT, incompatible with the GPL. >> Is removing the offending file from the rpm package during %install >> enough? > > Yes (imo). On second thought, it probably ought to be removed from the source tarball, on the chance that possible commercial use makes the srpm non-re-distributable (depends on the exactly licensing terms, I guess). -- Rex From tcallawa at redhat.com Fri Mar 30 14:33:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Mar 2007 09:33:56 -0500 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: <460D1DE8.4060802@math.unl.edu> References: <460D1D50.8000804@math.unl.edu> <460D1DE8.4060802@math.unl.edu> Message-ID: <1175265236.7124.17.camel@localhost.localdomain> On Fri, 2007-03-30 at 09:25 -0500, Rex Dieter wrote: > Rex Dieter wrote: > > Gianluca Sforna wrote: > >> sorry for the duplicate post, but I am afraid fedora-extras-list was > >> not the best place for this... > >> > >> ---------- Forwarded message ---------- > >> From: Gianluca Sforna > >> Date: Mar 30, 2007 10:41 AM > >> Subject: Licensing issue in mantis > >> To: Discussion related to Fedora Extras > >> > >> > >> Mantis (php) codebase includes a module which comes from a 3rd party > >> project and is licensed with a "free for non commercial use" style > >> clause which is, AFAICT, incompatible with the GPL. > >> Is removing the offending file from the rpm package during %install > >> enough? > > > > Yes (imo). > > On second thought, it probably ought to be removed from the source > tarball, on the chance that possible commercial use makes the srpm > non-re-distributable (depends on the exactly licensing terms, I guess). Yeah, you'll need to remove it from the Source tarball. Just take it out of the Source tarball, rename it to note that it is modified, and make a comment in the spec file explaining why. ~spot From giallu at gmail.com Fri Mar 30 14:57:30 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 30 Mar 2007 16:57:30 +0200 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: <1175265236.7124.17.camel@localhost.localdomain> References: <460D1D50.8000804@math.unl.edu> <460D1DE8.4060802@math.unl.edu> <1175265236.7124.17.camel@localhost.localdomain> Message-ID: On 3/30/07, Tom spot Callaway wrote: > On Fri, 2007-03-30 at 09:25 -0500, Rex Dieter wrote: > > Rex Dieter wrote: > > > Gianluca Sforna wrote: > > >> sorry for the duplicate post, but I am afraid fedora-extras-list was > > >> not the best place for this... > > >> > > >> ---------- Forwarded message ---------- > > >> From: Gianluca Sforna > > >> Date: Mar 30, 2007 10:41 AM > > >> Subject: Licensing issue in mantis > > >> To: Discussion related to Fedora Extras > > >> > > >> > > >> Mantis (php) codebase includes a module which comes from a 3rd party > > >> project and is licensed with a "free for non commercial use" style > > >> clause which is, AFAICT, incompatible with the GPL. > > >> Is removing the offending file from the rpm package during %install > > >> enough? > > > > > > Yes (imo). > > > > On second thought, it probably ought to be removed from the source > > tarball, on the chance that possible commercial use makes the srpm > > non-re-distributable (depends on the exactly licensing terms, I guess). > > Yeah, you'll need to remove it from the Source tarball. Just take it out > of the Source tarball, rename it to note that it is modified, and make a > comment in the spec file explaining why. Ok. I assume this is to be done also upstream, that is, they can not continue shipping it in the same tarball? From tcallawa at redhat.com Fri Mar 30 15:16:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Mar 2007 10:16:02 -0500 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: References: <460D1D50.8000804@math.unl.edu> <460D1DE8.4060802@math.unl.edu> <1175265236.7124.17.camel@localhost.localdomain> Message-ID: <1175267762.7124.22.camel@localhost.localdomain> On Fri, 2007-03-30 at 16:57 +0200, Gianluca Sforna wrote: > On 3/30/07, Tom spot Callaway wrote: > > On Fri, 2007-03-30 at 09:25 -0500, Rex Dieter wrote: > > > Rex Dieter wrote: > > > > Gianluca Sforna wrote: > > > >> sorry for the duplicate post, but I am afraid fedora-extras-list was > > > >> not the best place for this... > > > >> > > > >> ---------- Forwarded message ---------- > > > >> From: Gianluca Sforna > > > >> Date: Mar 30, 2007 10:41 AM > > > >> Subject: Licensing issue in mantis > > > >> To: Discussion related to Fedora Extras > > > >> > > > >> > > > >> Mantis (php) codebase includes a module which comes from a 3rd party > > > >> project and is licensed with a "free for non commercial use" style > > > >> clause which is, AFAICT, incompatible with the GPL. > > > >> Is removing the offending file from the rpm package during %install > > > >> enough? > > > > > > > > Yes (imo). > > > > > > On second thought, it probably ought to be removed from the source > > > tarball, on the chance that possible commercial use makes the srpm > > > non-re-distributable (depends on the exactly licensing terms, I guess). > > > > Yeah, you'll need to remove it from the Source tarball. Just take it out > > of the Source tarball, rename it to note that it is modified, and make a > > comment in the spec file explaining why. > > Ok. I assume this is to be done also upstream, that is, they can not > continue shipping it in the same tarball? While this is something that we would like to encourage upstream to do (either relicense it without the commercial use restriction or pull the code out entirely), it is not required. You only need to do this to meet Fedora requirements. ~spot From giallu at gmail.com Fri Mar 30 15:21:37 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 30 Mar 2007 17:21:37 +0200 Subject: [Fedora-packaging] Licensing issue in mantis In-Reply-To: <1175267762.7124.22.camel@localhost.localdomain> References: <460D1D50.8000804@math.unl.edu> <460D1DE8.4060802@math.unl.edu> <1175265236.7124.17.camel@localhost.localdomain> <1175267762.7124.22.camel@localhost.localdomain> Message-ID: On 3/30/07, Tom spot Callaway wrote: > > > > Ok. I assume this is to be done also upstream, that is, they can not > > continue shipping it in the same tarball? > > While this is something that we would like to encourage upstream to do > (either relicense it without the commercial use restriction or pull the > code out entirely), it is not required. You only need to do this to meet > Fedora requirements. Well. They can not relicense it because it's not under their copyright, but it comes from a 3rd party project (http://php-flp.sourceforge.net/); I'll ask them to try replacing it with something providing the same functionality (it's a rss feed generator php class) thanks for your help From foster at in.tum.de Fri Mar 30 15:56:10 2007 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Mar 2007 17:56:10 +0200 Subject: [Fedora-packaging] Building a set of packages where some BuildRequire others In-Reply-To: <1175251376.24401.258.camel@mccallum.corsepiu.local> References: <1175251376.24401.258.camel@mccallum.corsepiu.local> Message-ID: On 30/03/07, Ralf Corsepius wrote: > I'd suggest you to submit your package for review, such that others can > actively assist you. I've just submitted initial packages for review here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234612 I'd be glad for any suggestions! :) MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From caillon at redhat.com Fri Mar 30 21:31:02 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 30 Mar 2007 17:31:02 -0400 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1175177824.24401.177.camel@mccallum.corsepiu.local> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> Message-ID: <460D8196.7000002@redhat.com> Ralf Corsepius wrote: > On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote: >> Tom "spot" Callaway wrote: >>> I have added a draft for handling Post Release packages. >>> >>> http://fedoraproject.org/wiki/PackagingDrafts/PostRelease >>> >>> Comments are always welcomed. >>> >>> ~spot >> I would appreciate it if you would argue the case >> in which upstream uses the tarball like >> >> --.tar.gz. >> >> One case is ImageMagick, and the other case is: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560 > IMO, in such cases the upstream "version-release" should be treated as > rpm's "version" '-' is not a valid character in an rpm version. From rc040203 at freenet.de Sat Mar 31 02:05:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 31 Mar 2007 04:05:30 +0200 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <460D8196.7000002@redhat.com> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> Message-ID: <1175306731.24401.309.camel@mccallum.corsepiu.local> On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > > On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote: > >> Tom "spot" Callaway wrote: > >>> I have added a draft for handling Post Release packages. > >>> > >>> http://fedoraproject.org/wiki/PackagingDrafts/PostRelease > >>> > >>> Comments are always welcomed. > >>> > >>> ~spot > >> I would appreciate it if you would argue the case > >> in which upstream uses the tarball like > >> > >> --.tar.gz. > >> > >> One case is ImageMagick, and the other case is: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560 > > IMO, in such cases the upstream "version-release" should be treated as > > rpm's "version" > > '-' is not a valid character in an rpm version. man tr %define tarvers 1.2.3-4.5.6 %define rpmvers %{expand:%(echo %tarver | tr - _)} Version: %rpmvers The real issue however is elsewhere: What is the next "upstream version" of a package, after this "version-release"? Are we talking about snapshots? E.g. gcc-4.1.2-20070123 -> final version: gcc-4.1.2 In this case, using "4.1.2-20070123" as rpmversion would be a mistake. Or are we just talking about "upstream" using versioning which doesn't fit into rpm's expectations, e.g. xxx-1-20070123 xxx-1-20070210 ... In this case, what I said above would work. Ralf From caillon at redhat.com Sat Mar 31 15:08:31 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 31 Mar 2007 11:08:31 -0400 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1175306731.24401.309.camel@mccallum.corsepiu.local> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> <1175306731.24401.309.camel@mccallum.corsepiu.local> Message-ID: <460E796F.3070804@redhat.com> Ralf Corsepius wrote: > On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote: >> Ralf Corsepius wrote: >>> IMO, in such cases the upstream "version-release" should be treated as >>> rpm's "version" >> >> '-' is not a valid character in an rpm version. > > man tr > > %define tarvers 1.2.3-4.5.6 > %define rpmvers %{expand:%(echo %tarver | tr - _)} > Version: %rpmvers At which point you're no longer using the exact upstream version. You're using something close to it. There are lots of ways to do something close to something. If the tarball is x.y-z, we could do x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) and they'd all look valid. But none of them follow upstream. I'd argue that using the latter scheme makes it look closest to upstream, which to me is very important if I want to search for a package by version number. I'd still be able to do find -name abc-x.y-z* or a yum search abc-x.y-z and have it work. From nicolas.mailhot at laposte.net Sat Mar 31 15:54:16 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 31 Mar 2007 17:54:16 +0200 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <460E796F.3070804@redhat.com> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> <1175306731.24401.309.camel@mccallum.corsepiu.local> <460E796F.3070804@redhat.com> Message-ID: <1175356456.4252.12.camel@rousalka.dyndns.org> Le samedi 31 mars 2007 ? 11:08 -0400, Christopher Aillon a ?crit : > Ralf Corsepius wrote: > > On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote: > >> Ralf Corsepius wrote: > >>> IMO, in such cases the upstream "version-release" should be treated as > >>> rpm's "version" > >> > >> '-' is not a valid character in an rpm version. > > > > man tr > > > > %define tarvers 1.2.3-4.5.6 > > %define rpmvers %{expand:%(echo %tarver | tr - _)} > > Version: %rpmvers > > At which point you're no longer using the exact upstream version. > You're using something close to it. There are lots of ways to do > something close to something. If the tarball is x.y-z, we could do > x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) > and they'd all look valid. But none of them follow upstream. Please no underscores I dearly hate underscores in versions. Use a dot it you need to (this is actually the right subversion separator) > I'd argue that using the latter scheme makes it look closest to > upstream, which to me is very important if I want to search for a > package by version number. I'd still be able to do find -name > abc-x.y-z* or a yum search abc-x.y-z and have it work. There are many way we mangle upstream names & versions, you can't expect yum search abc-x.y-z to work anyway. Following upstream is well and good but following distro conventions comes first. Take ConsoleKit-libs for example. Someone blindly matched upstream. So it's a one-of-a-kind: - people don't find it easily since it's lot matching usual packagename lowercasing (same for the service btw) - it's a pam package but it's not a pam_foo package like the others (and it's totally broken on x86_64 right now because it's not putting its stuff in /lib64 as it should) Don't let upstream quirks creep in distro naming please. Regards, -- 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 Axel.Thimm at ATrpms.net Sat Mar 31 18:27:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Mar 2007 20:27:39 +0200 Subject: [Fedora-packaging] Re: Post Release Naming/Tags In-Reply-To: <460E796F.3070804@redhat.com> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> <1175306731.24401.309.camel@mccallum.corsepiu.local> <460E796F.3070804@redhat.com> Message-ID: <20070331182739.GA24044@neu.nirvana> On Sat, Mar 31, 2007 at 11:08:31AM -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > >On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote: > >>Ralf Corsepius wrote: > >>>IMO, in such cases the upstream "version-release" should be treated as > >>>rpm's "version" > >> > >>'-' is not a valid character in an rpm version. > > > >man tr > > > >%define tarvers 1.2.3-4.5.6 > >%define rpmvers %{expand:%(echo %tarver | tr - _)} > >Version: %rpmvers > > At which point you're no longer using the exact upstream version. > You're using something close to it. There are lots of ways to do > something close to something. If the tarball is x.y-z, we could do > x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) > and they'd all look valid. But none of them follow upstream. > > I'd argue that using the latter scheme makes it look closest to > upstream, Yes, but that's already all there is to it. rpm dependencies on minimal/maximal versions get busted or you start polluting the dependencies by parts of the %release tag. It is better to leave the version semantics as far as possible in the %version field. We only deviate from this when the version ordering would get out of place like 1.0rc5 to 1.0 and we don't have a better way to do that in the %version field alone (and epochs != better by definition ;). For upstream not using proper separators, e.g. using a hyphen, we can and should always embed our own, be it dots or underscores. -- 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 Sat Mar 31 20:02:30 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 31 Mar 2007 16:02:30 -0400 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1175356456.4252.12.camel@rousalka.dyndns.org> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> <1175306731.24401.309.camel@mccallum.corsepiu.local> <460E796F.3070804@redhat.com> <1175356456.4252.12.camel@rousalka.dyndns.org> Message-ID: <1175371350.3761.4.camel@localhost.localdomain> On Sat, 2007-03-31 at 17:54 +0200, Nicolas Mailhot wrote: > Take ConsoleKit-libs for example. Someone blindly matched upstream. So > it's a one-of-a-kind: You cannot have it both ways. Either you want us to follow the guidelines ("When naming a package, the name should match the upstream tarball or project name from which this software came.") or you want some other rule ("everything lowercase"). Also, if you have a problem with the way David and I packaged ConsoleKit, why don't you talk to us directly, rather than complaining about "somebody" ? > (and it's totally broken on x86_64 right now because it's not putting > its stuff in /lib64 as it should) Which is totally unrelated to the current discussion, no ? From nicolas.mailhot at laposte.net Sat Mar 31 21:06:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 31 Mar 2007 23:06:04 +0200 Subject: [Fedora-packaging] [DRAFT] Post Release Naming/Tags In-Reply-To: <1175371350.3761.4.camel@localhost.localdomain> References: <1174678735.5072.28.camel@1cc-dhcp-162.media.mit.edu> <460BC97F.106@ioa.s.u-tokyo.ac.jp> <1175177824.24401.177.camel@mccallum.corsepiu.local> <460D8196.7000002@redhat.com> <1175306731.24401.309.camel@mccallum.corsepiu.local> <460E796F.3070804@redhat.com> <1175356456.4252.12.camel@rousalka.dyndns.org> <1175371350.3761.4.camel@localhost.localdomain> Message-ID: <1175375164.9643.13.camel@rousalka.dyndns.org> Le samedi 31 mars 2007 ? 16:02 -0400, Matthias Clasen a ?crit : > On Sat, 2007-03-31 at 17:54 +0200, Nicolas Mailhot wrote: > > > Take ConsoleKit-libs for example. Someone blindly matched upstream. So > > it's a one-of-a-kind: > > You cannot have it both ways. Either you want us to follow the > guidelines ("When naming a package, the name should match the upstream > tarball or project name from which this software came.") or you want > some other rule ("everything lowercase") I don't read this as including random casing, and it seems most others packagers didn't. Most projects will uppercase their project name (or even write it all in uppercase) but most packages names are lowercase-only. Do you want this guideline point clarified? > Also, if you have a problem > with the way David and I packaged ConsoleKit, why don't you talk to us > directly, rather than complaining about "somebody" ? The casing is hugely annoying but not bug material IMHO. It's a good example of what happens when blindly following upstream quirks though > > (and it's totally broken on x86_64 right now because it's not putting > > its stuff in /lib64 as it should) > > Which is totally unrelated to the current discussion, no ? That was a random grumbling because I'm too cheap to open a bug today, and I could not raise people on IRC ;) (though it's not totally unrelated ? another example where deviating from the norm in seemingly harmless ways breaks stuff) -- 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 steve at silug.org Sat Mar 31 23:20:07 2007 From: steve at silug.org (Steven Pritchard) Date: Sat, 31 Mar 2007 18:20:07 -0500 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460AC5BD.6090107@redhat.com> References: <460AC5BD.6090107@redhat.com> Message-ID: <20070331232007.GA9963@osiris.silug.org> On Wed, Mar 28, 2007 at 03:45:01PM -0400, Jarod Wilson wrote: > I'd like to package up Maia Mailguard, and the license appears to be > original BSD (advertising clause included) with a branding extension > added. Thoughts? > > http://www.maiamailguard.org/license.php Isn't Maia a fork of amavisd-new? If so, how can its license be anything other than than GPL? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320