From Axel.Thimm at ATrpms.net Mon Jul 2 20:23:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Jul 2007 22:23:25 +0200 Subject: [Fedora-packaging] smp_flags considered dangerous? Message-ID: <20070702202325.GB1655@puariko.nirvana> Well, we know smp_flags lead to undeterministic builds that lead to o uncomparable build logs o difficult to trace bugs in the the build output o undeterministic triggering of build system bugs I had vtk [1] in the queue for a year, and one of the reviewers' demand was to add smp_flags, since "it worked that well". I added this for the sake of getting it reviewed and once the package was reviewed it wouldn't build on Fedora builders. And it was quite non-reproducible on my 4-way system, probably due to different number of make threads, different timings etc. It was also non-reproducable on the Fedora builders - it would fail but at different build stages, so I started to check what BR changed between invocations and the like. The benefits of smp_flags is that some very big builds are taking less time. So if say openoffice uses them (I have no idea) it would make no sense to forbid them for these packages. But for most packages that usually build under 15 minutes on a serial invocation the drawbacks are higher than the benefits (like package rebuilds simply breaking for no apparent reason like vtk did). But as *recommendation* we should switch from endorsing it to questioning it and recommending not to use it. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199405 -- 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 Mon Jul 2 20:58:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jul 2007 15:58:48 -0500 Subject: [Fedora-packaging] smp_flags considered dangerous? In-Reply-To: <20070702202325.GB1655@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> Message-ID: <1183409928.4103.17.camel@localhost.localdomain> On Mon, 2007-07-02 at 22:23 +0200, Axel Thimm wrote: > But as *recommendation* we should switch from endorsing it to > questioning it and recommending not to use it. I disagree. Well written code almost never has problems with smp flags. In the uncommon case (aka, corner cases) where a piece of code doesn't build properly or predictably with smp_mflags, it can be removed, but a comment needs to be added. # This code won't build properly with smp_mflags ... ~spot From giallu at gmail.com Mon Jul 2 22:32:49 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 3 Jul 2007 00:32:49 +0200 Subject: [Fedora-packaging] smp_flags considered dangerous? In-Reply-To: <1183409928.4103.17.camel@localhost.localdomain> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> Message-ID: On 7/2/07, Tom spot Callaway wrote: > In the uncommon case (aka, corner cases) where a piece of code doesn't > build properly or predictably with smp_mflags, it can be removed, but a > comment needs to be added. > > # This code won't build properly with smp_mflags ... And maybe a bug filed upstream ? From Axel.Thimm at ATrpms.net Mon Jul 2 22:34:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 00:34:43 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <1183409928.4103.17.camel@localhost.localdomain> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> Message-ID: <20070702223443.GA10319@puariko.nirvana> On Mon, Jul 02, 2007 at 03:58:48PM -0500, Tom spot Callaway wrote: > On Mon, 2007-07-02 at 22:23 +0200, Axel Thimm wrote: > > > But as *recommendation* we should switch from endorsing it to > > questioning it and recommending not to use it. > > I disagree. Well written code almost never has problems with smp flags. Well, not "well written", but "trivial". Once you start messing with non-conventional, non-linear builds (just think tex) you start leaving the safe harbour, and you can reverse the above: "complex Makefiles almost never wokr wit hsmpt flags". So, keeping smp_flags will create pain and detcet such issues, that can be considered a good thing. Only I don't think the pain is worth it. I for one will not start hunting down java Makefile issues which only exhibit on parallel builds. Make smpt_flags and opt-in instead of opt-out. -- 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 Mon Jul 2 22:40:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jul 2007 17:40:43 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070702223443.GA10319@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> <20070702223443.GA10319@puariko.nirvana> Message-ID: <1183416043.4103.23.camel@localhost.localdomain> On Tue, 2007-07-03 at 00:34 +0200, Axel Thimm wrote: > Well, not "well written", but "trivial". Once you start messing with > non-conventional, non-linear builds (just think tex) you start leaving > the safe harbour, and you can reverse the above: "complex Makefiles > almost never wokr wit hsmpt flags". Out of 130+ packages I maintain, only 3 of them fail to build with smp_mflags. That's roughly 2%. IMHO, the guidelines should be for the most common cases. If smp_mflags doesn't work with your package, no sweat, take it out and document it. But it should be the default, and all packages should try to use it whenever possible. ~spot From Axel.Thimm at ATrpms.net Mon Jul 2 22:47:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 00:47:00 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <1183416043.4103.23.camel@localhost.localdomain> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> <20070702223443.GA10319@puariko.nirvana> <1183416043.4103.23.camel@localhost.localdomain> Message-ID: <20070702224700.GC10319@puariko.nirvana> On Mon, Jul 02, 2007 at 05:40:43PM -0500, Tom spot Callaway wrote: > On Tue, 2007-07-03 at 00:34 +0200, Axel Thimm wrote: > > Well, not "well written", but "trivial". Once you start messing with > > non-conventional, non-linear builds (just think tex) you start leaving > > the safe harbour, and you can reverse the above: "complex Makefiles > > almost never wokr wit hsmpt flags". > > Out of 130+ packages I maintain, only 3 of them fail to build with > smp_mflags. That's the package you know about. The ugly thing about smp_flags is that bugs may not exhibit at all, or only on every Nth build. The submission of vtk was stalled for over a month due to that and I wouldn't count myself as a greenhorn. Imagine Joe Average Packager hitting this on every 40th package (or every 40th first time submitter being killed that way). > That's roughly 2%. IMHO, the guidelines should be for the most common > cases. If the 2% + dark factor are causing too much pain, then the picture changes. > If smp_mflags doesn't work with your package, no sweat, take it out and > document it. But it should be the default, and all packages should try > to use it whenever possible. OK, we just disagree on the default policy, this is something we can vote on. -- 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 Mon Jul 2 22:50:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jul 2007 17:50:17 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070702224700.GC10319@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> <20070702223443.GA10319@puariko.nirvana> <1183416043.4103.23.camel@localhost.localdomain> <20070702224700.GC10319@puariko.nirvana> Message-ID: <1183416617.4103.25.camel@localhost.localdomain> On Tue, 2007-07-03 at 00:47 +0200, Axel Thimm wrote: > If the 2% + dark factor are causing too much pain, then the picture > changes. I'm not sure how much pain they could be causing. If it breaks, take it out and document it. If code is actually miscompiling due to smp_mflags, you've either found a gcc bug or you've got some really, really broken code. ~spot From Axel.Thimm at ATrpms.net Mon Jul 2 23:02:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 01:02:02 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <1183416617.4103.25.camel@localhost.localdomain> References: <20070702202325.GB1655@puariko.nirvana> <1183409928.4103.17.camel@localhost.localdomain> <20070702223443.GA10319@puariko.nirvana> <1183416043.4103.23.camel@localhost.localdomain> <20070702224700.GC10319@puariko.nirvana> <1183416617.4103.25.camel@localhost.localdomain> Message-ID: <20070702230202.GD10319@puariko.nirvana> On Mon, Jul 02, 2007 at 05:50:17PM -0500, Tom spot Callaway wrote: > On Tue, 2007-07-03 at 00:47 +0200, Axel Thimm wrote: > > If the 2% + dark factor are causing too much pain, then the picture > > changes. > > I'm not sure how much pain they could be causing. Like stalling a package entering Fedora for over a month due to the failures not being reproducible on neither the submitter's nor the reviewer's systems? Not to mention the lost man power? We don't gain much by triggering Makefile bugs. Most upstream projects don't design their Makefiles for -j usage, it just happens to work 98% or less of the times. -- 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 jkeating at redhat.com Tue Jul 3 11:01:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 07:01:01 -0400 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070702230202.GD10319@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <1183416617.4103.25.camel@localhost.localdomain> <20070702230202.GD10319@puariko.nirvana> Message-ID: <200707030701.01740.jkeating@redhat.com> On Monday 02 July 2007 19:02:02 Axel Thimm wrote: > Like stalling a package entering Fedora for over a month due to the > failures not being reproducible on neither the submitter's nor the > reviewer's systems? Not to mention the lost man power? > > We don't gain much by triggering Makefile bugs. Most upstream projects > don't design their Makefiles for -j usage, it just happens to work 98% > or less of the times. This sounds like "tribal knowledge". This has come up enough for me that when I have strange compile issues one of the first things I do is strip down the compile flags and start adding them back in one by one until I reproduce the problem where it happened in the first place. Often times I even seek out the smp flags and drop them. So it would be good to have this "tribal knowledge" documented somewhere for people to follow if they're seeing this type of issue, and then we can cut down that month to something /far/ more reasonable. -- 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 Axel.Thimm at ATrpms.net Tue Jul 3 11:47:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 13:47:26 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <200707030701.01740.jkeating@redhat.com> References: <20070702202325.GB1655@puariko.nirvana> <1183416617.4103.25.camel@localhost.localdomain> <20070702230202.GD10319@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> Message-ID: <20070703114726.GD26061@puariko.nirvana> On Tue, Jul 03, 2007 at 07:01:01AM -0400, Jesse Keating wrote: > On Monday 02 July 2007 19:02:02 Axel Thimm wrote: > > Like stalling a package entering Fedora for over a month due to the > > failures not being reproducible on neither the submitter's nor the > > reviewer's systems? Not to mention the lost man power? > > > > We don't gain much by triggering Makefile bugs. Most upstream projects > > don't design their Makefiles for -j usage, it just happens to work 98% > > or less of the times. > > This sounds like "tribal knowledge". This has come up enough for me that when > I have strange compile issues one of the first things I do is strip down the > compile flags and start adding them back in one by one until I reproduce the > problem where it happened in the first place. Often times I even seek out > the smp flags and drop them. So it would be good to have this "tribal > knowledge" documented somewhere for people to follow if they're seeing this > type of issue, and then we can cut down that month to something /far/ more > reasonable. But you understand that the month of trials is about buildon the Fedora builders, not on your own server or workstation? It isn't really a sensible turnover to edit, submit, wait for being queued in, wait for being built on all archs, get the response on failure, dig trhough a web interface, find the logs, donwload them, comaper them to local logs etc. Now add the fact to it that if someone else than the submitter has some suggestion it needs first to get piped through the submitter, who needs to . It's different if the problem is actually reproducable on your own system. What's the drawback of a general discommendation of smp_flags (not talking about openoffice and friends)? A submitter waiting twice as long in build time? Is that really a big drawback in comparison to having packages break out of the blue? No Makefile project not intended/tested by upstream for parallel builds is smp_flags safe, the race may just not have been triggered yet (as in the case of vtk). And if your build succeeds on F7 and start to mysteriously fail on F8 will the first thought be that the hidden make -jX bug hit you or that something in the build environment is screwed? -- 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 Jul 3 11:49:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 13:49:27 +0200 Subject: [Fedora-packaging] Meeting today Message-ID: <20070703114927.GE26061@puariko.nirvana> I will probably not make it to the meeting, but I'd like to propose to reverse the recommendation to use smp_flags with the opposite (make the opt-out an opt-in) for the reasons outlined. Count my +1 for that. -- 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 jkeating at redhat.com Tue Jul 3 12:25:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 08:25:59 -0400 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070703114726.GD26061@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> Message-ID: <200707030825.59807.jkeating@redhat.com> On Tuesday 03 July 2007 07:47:26 Axel Thimm wrote: > But you understand that the month of trials is about buildon the > Fedora builders, not on your own server or workstation? It isn't > really a sensible turnover to edit, submit, wait for being queued in, > wait for being built on all archs, get the response on failure, dig > trhough a web interface, find the logs, donwload them, comaper them to > local logs etc. Now add the fact to it that if someone else than the > submitter has some suggestion it needs first to get piped through the > submitter, who needs to . Scratch builds are your friend. You can target a single arch, build any srpm you want, etc... No need for the hyperbole of above. > It's different if the problem is actually reproducable on your own > system. > > What's the drawback of a general discommendation of smp_flags (not > talking about openoffice and friends)? A submitter waiting twice as > long in build time? Is that really a big drawback in comparison to > having packages break out of the blue? No Makefile project not > intended/tested by upstream for parallel builds is smp_flags safe, the > race may just not have been triggered yet (as in the case of vtk). > > And if your build succeeds on F7 and start to mysteriously fail on F8 > will the first thought be that the hidden make -jX bug hit you or that > something in the build environment is screwed? To use somebody else's argument it can be useful to /find/ these bugs. If the software doesn't compile right due to smp often it is an upstream bug that needs to be addressed. Maybe the upstream doesn't have access to smp, and we can get them into Fedora and give them access to our build farm so that they can make better code. And yes, things are faster. The faster they get through the build system, the faster the next job can start, and so on and so forth. -- 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 Axel.Thimm at ATrpms.net Tue Jul 3 16:07:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Jul 2007 18:07:55 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <200707030825.59807.jkeating@redhat.com> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> Message-ID: <20070703160755.GA4785@puariko.nirvana> On Tue, Jul 03, 2007 at 08:25:59AM -0400, Jesse Keating wrote: > On Tuesday 03 July 2007 07:47:26 Axel Thimm wrote: > > But you understand that the month of trials is about buildon the > > Fedora builders, not on your own server or workstation? It isn't > > really a sensible turnover to edit, submit, wait for being queued in, > > wait for being built on all archs, get the response on failure, dig > > trhough a web interface, find the logs, donwload them, comaper them to > > local logs etc. Now add the fact to it that if someone else than the > > submitter has some suggestion it needs first to get piped through the > > submitter, who needs to . > > Scratch builds are your friend. You can target a single arch, build any srpm > you want, etc... No need for the hyperbole of above. So with scratch builds there is no need to commit in CVS, queue the build, wait for the queue to reach the job, and it really allows everyone and his cat to do it, not only the submitter? Where's that hyperbole again? > > It's different if the problem is actually reproducable on your own > > system. > > > > What's the drawback of a general discommendation of smp_flags (not > > talking about openoffice and friends)? A submitter waiting twice as > > long in build time? Is that really a big drawback in comparison to > > having packages break out of the blue? No Makefile project not > > intended/tested by upstream for parallel builds is smp_flags safe, the > > race may just not have been triggered yet (as in the case of vtk). > > > > And if your build succeeds on F7 and start to mysteriously fail on F8 > > will the first thought be that the hidden make -jX bug hit you or that > > something in the build environment is screwed? > > To use somebody else's argument it can be useful to /find/ these > bugs. If the software doesn't compile right due to smp often it is > an upstream bug that needs to be addressed. Unless upstream never advertized a parallel make feature (which one really does?) and upstream cares more about fixing real code bugs than spurious Makefile racings on an 8-way system. -- 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 Tue Jul 3 17:42:30 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Jul 2007 12:42:30 -0500 Subject: [Fedora-packaging] Multiple version naming overly restrictive? In-Reply-To: <1183143092.21296.71.camel@localhost.localdomain> References: <1183143092.21296.71.camel@localhost.localdomain> Message-ID: <1183484550.3404.6.camel@dhcp-32-74.ord.redhat.com> On Fri, 2007-06-29 at 11:51 -0700, Toshio Kuratomi wrote: > If not, we could amend the text like this: > ''' > One package should use the base name with no versions and all other > addons should note their version in the name. +1 to this. I'll probably work up a draft around compat-* soon, but it won't contradict this. ~spot From a.badger at gmail.com Tue Jul 3 18:16:43 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Jul 2007 11:16:43 -0700 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive Message-ID: <1183486603.5355.62.camel@localhost.localdomain> We didn't have quorum in the Fedora Packaging Meeting but we did discuss the proposal[1]_ to relax the guidelines for packages with multiple versions. After some discussion it was decided that restricting the maintainer too much is not desirable. Some points: * Guideline was written in the present manner to avoid confusion * Using compat-* as a namespace for all less than current libraries has the following disadvantages over [name][version]: * cvs history won't follow the compat-* even though it is arguably closer to the original package than the upgraded one. * BuildRequires would have to be changed between branches to accommodate the compat-* on the newer branch. I'd like to have votes on relaxing the guidelines as follows: ''' For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name should reflect this fact. One package should use the base name with no versions and all other addons should note their version in the name. ''' This gives the maintainer the leeway to choose whether the package is best served by having the latest version carry the unadorned name forward or the previous version. [1]_: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html -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 Tue Jul 3 18:24:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 14:24:40 -0400 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183486603.5355.62.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> Message-ID: <200707031424.40960.jkeating@redhat.com> On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote: > ''' > For many reasons, it is sometimes advantageous to keep multiple versions > of a package in Fedora to be installed simultaneously. When doing so, > the package name should reflect this fact. One package should use the > base name with no versions and all other addons should note their > version in the name. > ''' > > This gives the maintainer the leeway to choose whether the package is > best served by having the latest version carry the unadorned name > forward or the previous version. +1 -- 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 cra at WPI.EDU Tue Jul 3 19:30:24 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 3 Jul 2007 15:30:24 -0400 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183486603.5355.62.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> Message-ID: <20070703193024.GB15305@angus.ind.WPI.EDU> On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote: > For many reasons, it is sometimes advantageous to keep multiple versions > of a package in Fedora to be installed simultaneously. When doing so, > the package name should reflect this fact. One package should use the > base name with no versions and all other addons should note their > version in the name. > ''' > > This gives the maintainer the leeway to choose whether the package is > best served by having the latest version carry the unadorned name > forward or the previous version. How does this proposal relate to the kernel package? From jkeating at redhat.com Tue Jul 3 19:31:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 15:31:22 -0400 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <20070703193024.GB15305@angus.ind.WPI.EDU> References: <1183486603.5355.62.camel@localhost.localdomain> <20070703193024.GB15305@angus.ind.WPI.EDU> Message-ID: <200707031531.22279.jkeating@redhat.com> On Tuesday 03 July 2007 15:30:24 Chuck Anderson wrote: > How does this proposal relate to the kernel package? The kernel package succeeds in being able to have multiple versions of it installed without changing the name. None of the files should conflict. -- 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 nicolas.mailhot at laposte.net Tue Jul 3 19:35:23 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Jul 2007 21:35:23 +0200 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <200707031424.40960.jkeating@redhat.com> References: <1183486603.5355.62.camel@localhost.localdomain> <200707031424.40960.jkeating@redhat.com> Message-ID: <1183491324.12567.4.camel@rousalka.dyndns.org> Le mardi 03 juillet 2007 ? 14:24 -0400, Jesse Keating a ?crit : > On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote: > > ''' > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > > > > This gives the maintainer the leeway to choose whether the package is > > best served by having the latest version carry the unadorned name > > forward or the previous version. > > +1 -1 The compat convention is awkward precisely to incite people to converge on a common version. Making multi-versioning easy is a win short term and a heavy loss long-term, because everyone just hardcodes a particular version hoping for "someone else" to clean up the mess. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Tue Jul 3 19:36:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Jul 2007 14:36:37 -0500 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <20070703193024.GB15305@angus.ind.WPI.EDU> References: <1183486603.5355.62.camel@localhost.localdomain> <20070703193024.GB15305@angus.ind.WPI.EDU> Message-ID: <1183491397.3404.12.camel@dhcp-32-74.ord.redhat.com> On Tue, 2007-07-03 at 15:30 -0400, Chuck Anderson wrote: > On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote: > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > > > > This gives the maintainer the leeway to choose whether the package is > > best served by having the latest version carry the unadorned name > > forward or the previous version. > > How does this proposal relate to the kernel package? fwiw, the kernel is "special" in many ways, but in this case, this would only affect a hypothetical kernel24 vs kernel. ~spot From smooge at gmail.com Tue Jul 3 19:56:23 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 3 Jul 2007 13:56:23 -0600 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183486603.5355.62.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> Message-ID: <80d7e4090707031256y7342da47i180fa947b21aef0d@mail.gmail.com> On 7/3/07, Toshio Kuratomi wrote: > We didn't have quorum in the Fedora Packaging Meeting but we did discuss > the proposal[1]_ to relax the guidelines for packages with multiple > versions. After some discussion it was decided that restricting the > maintainer too much is not desirable. Some points: > > * Guideline was written in the present manner to avoid confusion > * Using compat-* as a namespace for all less than current libraries has > the following disadvantages over [name][version]: > * cvs history won't follow the compat-* even though it is arguably > closer to the original package than the upgraded one. > * BuildRequires would have to be changed between branches to > accommodate the compat-* on the newer branch. > > I'd like to have votes on relaxing the guidelines as follows: > > ''' > For many reasons, it is sometimes advantageous to keep multiple versions > of a package in Fedora to be installed simultaneously. When doing so, > the package name should reflect this fact. One package should use the > base name with no versions and all other addons should note their > version in the name. > ''' > > This gives the maintainer the leeway to choose whether the package is > best served by having the latest version carry the unadorned name > forward or the previous version. So I can see this in my head... this would be like python15 python20 python22 python23 python24 python for something like say EPEL where you might need to have python23/24/30 installed on a system for an app to work since the shipped version is 22. I would say that there would need to be a standardization of how these older items should/would be packaged up so that people do not accidently run one when the other was wanted. Or is this meaning something else? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From a.badger at gmail.com Tue Jul 3 19:56:46 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Jul 2007 12:56:46 -0700 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <20070703193024.GB15305@angus.ind.WPI.EDU> References: <1183486603.5355.62.camel@localhost.localdomain> <20070703193024.GB15305@angus.ind.WPI.EDU> Message-ID: <1183492606.5355.72.camel@localhost.localdomain> On Tue, 2007-07-03 at 15:30 -0400, Chuck Anderson wrote: > On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote: > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > > > > This gives the maintainer the leeway to choose whether the package is > > best served by having the latest version carry the unadorned name > > forward or the previous version. > > How does this proposal relate to the kernel package? > It shouldn't. This proposal deals with package names. The kernel doesn't place a version in the package name. -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 a.badger at gmail.com Tue Jul 3 20:04:26 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Jul 2007 13:04:26 -0700 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183491324.12567.4.camel@rousalka.dyndns.org> References: <1183486603.5355.62.camel@localhost.localdomain> <200707031424.40960.jkeating@redhat.com> <1183491324.12567.4.camel@rousalka.dyndns.org> Message-ID: <1183493066.5355.79.camel@localhost.localdomain> On Tue, 2007-07-03 at 21:35 +0200, Nicolas Mailhot wrote: > Le mardi 03 juillet 2007 ? 14:24 -0400, Jesse Keating a ?crit : > > On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote: > > > ''' > > > For many reasons, it is sometimes advantageous to keep multiple versions > > > of a package in Fedora to be installed simultaneously. When doing so, > > > the package name should reflect this fact. One package should use the > > > base name with no versions and all other addons should note their > > > version in the name. > > > ''' > > > > > > This gives the maintainer the leeway to choose whether the package is > > > best served by having the latest version carry the unadorned name > > > forward or the previous version. > > > > +1 > > -1 > > The compat convention is awkward precisely to incite people to converge > on a common version. Making multi-versioning easy is a win short term > and a heavy loss long-term, because everyone just hardcodes a particular > version hoping for "someone else" to clean up the mess. > Possibly. Note that the current text of the guideline isn't any better. There is no current guideline to tell when to use (compat-libfoo1 && libfoo) vs (libfoo1 && libfoo). This change just opens up the possibility of libfoo (1.x) and libfoo2 (2.x) being legal. -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 a.badger at gmail.com Tue Jul 3 20:14:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Jul 2007 13:14:34 -0700 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <80d7e4090707031256y7342da47i180fa947b21aef0d@mail.gmail.com> References: <1183486603.5355.62.camel@localhost.localdomain> <80d7e4090707031256y7342da47i180fa947b21aef0d@mail.gmail.com> Message-ID: <1183493674.5355.90.camel@localhost.localdomain> On Tue, 2007-07-03 at 13:56 -0600, Stephen John Smoogen wrote: > On 7/3/07, Toshio Kuratomi wrote: > > We didn't have quorum in the Fedora Packaging Meeting but we did discuss > > the proposal[1]_ to relax the guidelines for packages with multiple > > versions. After some discussion it was decided that restricting the > > maintainer too much is not desirable. Some points: > > > > * Guideline was written in the present manner to avoid confusion > > * Using compat-* as a namespace for all less than current libraries has > > the following disadvantages over [name][version]: > > * cvs history won't follow the compat-* even though it is arguably > > closer to the original package than the upgraded one. > > * BuildRequires would have to be changed between branches to > > accommodate the compat-* on the newer branch. > > > > I'd like to have votes on relaxing the guidelines as follows: > > > > ''' > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > > > > This gives the maintainer the leeway to choose whether the package is > > best served by having the latest version carry the unadorned name > > forward or the previous version. > > So I can see this in my head... this would be like > > python15 > python20 > python22 > python23 > python24 > python > > for something like say EPEL where you might need to have > python23/24/30 installed on a system for an app to work since the > shipped version is 22. I would say that there would need to be a > standardization of how these older items should/would be packaged up > so that people do not accidently run one when the other was wanted. > > Or is this meaning something else? > This change only addresses the naming of such a package, not the contents. Your EPEL example is a bit problematic under the old guidelines because, following the letter of the guideline, [basename][version] that is newer than [basename] would not be allowed. So with python-2.3 in RHEL4 a python15 package would be named appropriately. python24 would not. With the new proposal the name python24 would be legal. -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 jorton at redhat.com Tue Jul 3 20:33:04 2007 From: jorton at redhat.com (Joe Orton) Date: Tue, 3 Jul 2007 21:33:04 +0100 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070703160755.GA4785@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> Message-ID: <20070703203303.GA6600@redhat.com> On Tue, Jul 03, 2007 at 06:07:55PM +0200, Axel Thimm wrote: > Unless upstream never advertized a parallel make feature (which one > really does?) and upstream cares more about fixing real code bugs than > spurious Makefile racings on an 8-way system. Sometimes these discussions astound me. "Hey, broken Makefiles exist! Let's stop using smp_mflags everywhere." Can common sense not apply here? If the Makefile is trivially broken, fix it, send patches upstream, move on. If the Makefile is broken in some overwhelmingly complex manner, ignore it, file bug upstream, document the fact in %build, move on. joe From roland at redhat.com Tue Jul 3 22:03:08 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Jul 2007 15:03:08 -0700 (PDT) Subject: [Fedora-packaging] build ID -debuginfo rpm convention Message-ID: <20070703220308.E1D094D0435@magilla.localdomain> Hi folks. Please see http://fedoraproject.org/wiki/Releases/FeatureBuildId for background (and read through all that before asking any technical questions on the details aside from the rpm packaging convention). The upshot is that with F8 tools each binary linked will contain something akin to a UUID, and core dumps will include the IDs of the executable and DSOs in the crashed process. Married with some conventions about storing and looking up ID bits, this enables nice automagic debuggability things including e.g. yum install foo-debuginfo for all the foos in your core file. For rpm builds, the final ID bits are chosen by debugedit. BZ 246404 tracks the debugedit change, which has not gone in yet (just went into rpm5.org though ;-) http://people.redhat.com/roland/build-id/ has all the patches. Here I want to talk about those conventions. This will be an upstream convention that the consuming tools (debuggers et al) will have as default behavior, not just a convention for Fedora or rpm. But I want to reach consensus on the integrated plan for Fedora repos before proposing a particular convention upstream. See http://fedoraproject.org/wiki/RolandMcGrath/BuildID#symlinks for the details of my initial proposal. In short, the debuginfo rpm covering /usr/bin/debug would include two symlinks like these: /usr/lib/debug/.build-id/7c/763b567137492087bc1e50809b1218 -> ../../../bin/foo /usr/lib/debug/.build-id/7c/763b567137492087bc1e50809b1218.debug -> ../../usr/bin/foo Consumers will use the .build-id/xx/x... convention to find the binaries with ID bits xxx... Fancy consumers will do: yum install /usr/lib/debug/.build-id/7c/763b567137492087bc1e50809b1218.debug The basic filesystem part of this is simple and efficient to have as the new standard convention in upstream consumers. This will wind up with two symlinks per binary installed in /usr/{bin,sbin,lib} etc., which seems reasonable enough for the maximum size of /usr/lib/debug/.build-id/ directories in an installed system. Is this reasonable for the packaging in the whole-distro perspective? The issues I can imagine might be problems are: * adds two (long) file names per installed binary to debuginfo repo Is this going to be an unreasonable bloat on the filelist metadata? * danglink symlink from foo-debuginfo rpm to file in foo rpm Is this kosher? The big benefit of this particular convention is that it requires no new infrastructure work. The extent of the implementation work in the packaging sphere is a patch to find-debuginfo.sh (below). Please let me know ASAP what you think about this plan. Thanks, Roland diff -r 4178c07c98c8 scripts/find-debuginfo.sh --- a/scripts/find-debuginfo.sh Fri Jun 29 14:12:44 2007 +0300 +++ b/scripts/find-debuginfo.sh Sun Jul 01 16:11:35 2007 -0700 @@ -11,16 +11,30 @@ SOURCEFILE=$BUILDDIR/debugsources.list debugdir="${RPM_BUILD_ROOT}/usr/lib/debug" -echo -n > $SOURCEFILE +> $SOURCEFILE +> $LISTFILE strip_to_debug() { eu-strip --remove-comment -f "$1" "$2" || : } +debug_link() +{ + tgt="$1" + tgt="${tgt/#..\/..\/..\/..\/..\/usr\//../../../../}" + tgt="${tgt/#..\/..\/..\/..\/lib\//../../../}" + tgt="${1/#..\/..\/..\/debug\//../../}" + ln -snf "$tgt" "${debugdir}/$2" + echo >> $LISTFILE "/usr/lib/debug/$2" +} + # Strip ELF binaries -for f in `find $RPM_BUILD_ROOT ! -path "${debugdir}/*.debug" -type f \( -perm -0100 -or -perm -0010 -or -perm -0001 \) -exec file {} \; | \ - sed -n -e 's/^\(.*\):[ ]*.*ELF.*, not stripped/\1/p'` +find $RPM_BUILD_ROOT ! -path "${debugdir}/*.debug" -type f \ + \( -perm -0100 -or -perm -0010 -or -perm -0001 \) \ + -print | +file -N -f - | sed -n -e 's/^\(.*\):[ ]*.*ELF.*, not stripped/\1/p' | +while read f do dn=$(dirname $f | sed -n -e "s#^$RPM_BUILD_ROOT##p") bn=$(basename $f .debug).debug @@ -30,12 +44,23 @@ do [ -f "${debugfn}" ] && continue echo extracting debug info from $f - /usr/lib/rpm/debugedit -b "$RPM_BUILD_DIR" -d /usr/src/debug -l "$SOURCEFILE" "$f" + id=`/usr/lib/rpm/debugedit -b "$RPM_BUILD_DIR" -d /usr/src/debug \ + -i -l "$SOURCEFILE" "$f"` || exit + if [ -z "$id" ]; then + echo >&2 "No build ID note found in $f" + # Demand build IDs in all binaries for Fedora rebuild. + # Comment out this exit to be less anal about it. + exit 2 + else + id="${id:0:2}/${id:2}" + debug_link "../../../../..$dn/$(basename $f)" ".build-id/${id}" + fi # A binary already copied into /usr/lib/debug doesn't get stripped, # just has its file names collected and adjusted. case "$dn" in - /usr/lib/debug/*) continue ;; + /usr/lib/debug/*) + continue ;; esac mkdir -p "${debugdn}" @@ -46,12 +71,15 @@ do strip_to_debug "${debugfn}" "$f" chmod u-w "$f" fi + + [ -z "$id" ] || debug_link "../..$dn/$bn" ".build-id/${id}.debug" done mkdir -p ${RPM_BUILD_ROOT}/usr/src/debug -cat $SOURCEFILE | (cd $RPM_BUILD_DIR; LANG=C sort -z -u | cpio -pd0mL ${RPM_BUILD_ROOT}/usr/src/debug) +LANG=C sort -z -u $SOURCEFILE | +(cd $RPM_BUILD_DIR; cpio -pd0mL ${RPM_BUILD_ROOT}/usr/src/debug) # stupid cpio creates new directories in mode 0700, fixup find ${RPM_BUILD_ROOT}/usr/src/debug -type d -print0 | xargs -0 chmod a+rx -find ${RPM_BUILD_ROOT}/usr/lib/debug -type f | sed -n -e "s#^$RPM_BUILD_ROOT##p" > $LISTFILE +find ${RPM_BUILD_ROOT}/usr/lib/debug -type f | sed -n -e "s#^$RPM_BUILD_ROOT##p" >> $LISTFILE find ${RPM_BUILD_ROOT}/usr/src/debug -mindepth 1 -maxdepth 1 | sed -n -e "s#^$RPM_BUILD_ROOT##p" >> $LISTFILE From Axel.Thimm at ATrpms.net Tue Jul 3 22:08:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 00:08:58 +0200 Subject: [Fedora-packaging] Re: Multiple version naming overly restrictive In-Reply-To: <200707031424.40960.jkeating@redhat.com> References: <1183486603.5355.62.camel@localhost.localdomain> <200707031424.40960.jkeating@redhat.com> Message-ID: <20070703220858.GC4785@puariko.nirvana> On Tue, Jul 03, 2007 at 02:24:40PM -0400, Jesse Keating wrote: > On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote: > > ''' > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > +1 +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 skvidal at linux.duke.edu Tue Jul 3 22:13:47 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 03 Jul 2007 18:13:47 -0400 Subject: [Fedora-packaging] build ID -debuginfo rpm convention In-Reply-To: <20070703220308.E1D094D0435@magilla.localdomain> References: <20070703220308.E1D094D0435@magilla.localdomain> Message-ID: <1183500827.31613.63.camel@cutter> On Tue, 2007-07-03 at 15:03 -0700, Roland McGrath wrote: > Hi folks. Please see http://fedoraproject.org/wiki/Releases/FeatureBuildId > for background (and read through all that before asking any technical > questions on the details aside from the rpm packaging convention). > > The upshot is that with F8 tools each binary linked will contain something > akin to a UUID, and core dumps will include the IDs of the executable and > DSOs in the crashed process. Married with some conventions about storing > and looking up ID bits, this enables nice automagic debuggability things > including e.g. yum install foo-debuginfo for all the foos in your core file. > if you know the binaries in the core - why do you need this uuid to find the debuginfos? debuginfo-install in yum-utils can track back from the binary to the debuginfo pkg and install it, and all the dependencies of the originating pkg. What more do we get from what you're describing? -sv From tibbs at math.uh.edu Tue Jul 3 22:19:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2007 17:19:38 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070703203303.GA6600@redhat.com> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> Message-ID: >>>>> "JO" == Joe Orton writes: JO> Sometimes these discussions astound me. "Hey, broken Makefiles JO> exist! Let's stop using smp_mflags everywhere." Can common sense JO> not apply here? Actually it did; the five members of the committee present at the meeting today voted unanimously against this proposal. - J< From Axel.Thimm at ATrpms.net Tue Jul 3 22:31:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 00:31:59 +0200 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> Message-ID: <20070703223159.GD4785@puariko.nirvana> On Tue, Jul 03, 2007 at 05:19:38PM -0500, Jason L Tibbitts III wrote: > >>>>> "JO" == Joe Orton writes: > > JO> Sometimes these discussions astound me. "Hey, broken Makefiles > JO> exist! Let's stop using smp_mflags everywhere." Can common sense > JO> not apply here? > > Actually it did; the five members of the committee present at the > meeting today voted unanimously against this proposal. I thought there was no quorum. And how does that fit in comon sense? ;) OK, I got it, another one 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 tibbs at math.uh.edu Tue Jul 3 22:32:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2007 17:32:12 -0500 Subject: [Fedora-packaging] build ID -debuginfo rpm convention In-Reply-To: <20070703220308.E1D094D0435@magilla.localdomain> References: <20070703220308.E1D094D0435@magilla.localdomain> Message-ID: >>>>> "RM" == Roland McGrath writes: RM> * danglink symlink from foo-debuginfo rpm to file in foo rpm Is RM> this kosher? It is kosher if the dependencies make it such that there's no way the symlink can be dangling in a running system. (Outside of --nodeps, of course.) Many packages in the distro currently contain symlinks to files in packages they depend on. I'm afraid I can't comment on the plan itself as frankly I don't know what problem is being solved by it. Did I somehow miss that part of the proposal? - J< From tibbs at math.uh.edu Wed Jul 4 00:28:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2007 19:28:33 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <20070703223159.GD4785@puariko.nirvana> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> <20070703223159.GD4785@puariko.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I thought there was no quorum. f13 arrived 44 minutes into the meeting, providing the fifth member and thus a quorum. At that point spot called for a vote. The five members present (tibbs spot f13 abadger1999 scop) all voted against the proposal. (I suppose there were six total votes counting your on-list vote; the minutes will reflect that.) - J< From smooge at gmail.com Wed Jul 4 00:40:01 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 3 Jul 2007 18:40:01 -0600 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> <20070703223159.GD4785@puariko.nirvana> Message-ID: <80d7e4090707031740x6ea4f39dn9ff6c1f0d097fe85@mail.gmail.com> On 03 Jul 2007 19:28:33 -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> I thought there was no quorum. > > f13 arrived 44 minutes into the meeting, providing the fifth member > and thus a quorum. At that point spot called for a vote. The five > members present (tibbs spot f13 abadger1999 scop) all voted against > the proposal. (I suppose there were six total votes counting your > on-list vote; the minutes will reflect that.) > Ok... I would like to say that is very poor political clarity (I expect such from Congress, not from a group that has higher standards). If for some reason people were against this, came to the meeting, and left thinking that there was no quorum... they have been effectively cut out of the process. Not that this was the case this time... but people should be aware that these events lead to the "secret cabal meetings." A quorum should always be called/met within a certain amount of time of a meeting being held. Generally, this is 15-20 minutes of the called time. If quorum is not met, its time to cancel the meeting until the next general listing or if an emergency meeting can be called/advertised/met. Sorry for coming out of the blue here... but I would like to make sure that groups are heard even if the vote goes against their views. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tibbs at math.uh.edu Wed Jul 4 01:12:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2007 20:12:09 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <80d7e4090707031740x6ea4f39dn9ff6c1f0d097fe85@mail.gmail.com> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> <20070703223159.GD4785@puariko.nirvana> <80d7e4090707031740x6ea4f39dn9ff6c1f0d097fe85@mail.gmail.com> Message-ID: >>>>> "SJS" == Stephen John Smoogen writes: SJS> Ok... I would like to say that is very poor political clarity (I SJS> expect such from Congress, not from a group that has higher SJS> standards). Erm, we were informed ahead of time that f13 would be late, and that fact, along with the fact that we would await his arrival before voting, was mentioned in the meeting. - J< From tcallawa at redhat.com Wed Jul 4 13:06:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Jul 2007 08:06:10 -0500 Subject: [Fedora-packaging] Re: smp_flags considered dangerous? In-Reply-To: <80d7e4090707031740x6ea4f39dn9ff6c1f0d097fe85@mail.gmail.com> References: <20070702202325.GB1655@puariko.nirvana> <200707030701.01740.jkeating@redhat.com> <20070703114726.GD26061@puariko.nirvana> <200707030825.59807.jkeating@redhat.com> <20070703160755.GA4785@puariko.nirvana> <20070703203303.GA6600@redhat.com> <20070703223159.GD4785@puariko.nirvana> <80d7e4090707031740x6ea4f39dn9ff6c1f0d097fe85@mail.gmail.com> Message-ID: <1183554370.3497.5.camel@localhost.localdomain> On Tue, 2007-07-03 at 18:40 -0600, Stephen John Smoogen wrote: > A quorum should always be called/met within a certain amount of time > of a meeting being held. Generally, this is 15-20 minutes of the > called time. If quorum is not met, its time to cancel the meeting > until the next general listing or if an emergency meeting can be > called/advertised/met. Indeed this is a valid point, but everyone in attendance was informed at the beginning that f13 was arriving late, and everyone opted to stay. (Several members missed the meeting entirely). ~spot From ville.skytta at iki.fi Wed Jul 4 15:21:40 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 4 Jul 2007 18:21:40 +0300 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183486603.5355.62.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> Message-ID: <200707041821.41533.ville.skytta@iki.fi> On Tuesday 03 July 2007, Toshio Kuratomi wrote: > ''' > For many reasons, it is sometimes advantageous to keep multiple versions > of a package in Fedora to be installed simultaneously. When doing so, > the package name should reflect this fact. One package should use the > base name with no versions and all other addons should note their > version in the name. > ''' +1 From rc040203 at freenet.de Thu Jul 5 09:39:56 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Jul 2007 11:39:56 +0200 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183486603.5355.62.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> Message-ID: <1183628397.22644.14.camel@mccallum.corsepiu.local> On Tue, 2007-07-03 at 11:16 -0700, Toshio Kuratomi wrote: > We didn't have quorum in the Fedora Packaging Meeting but we did discuss > the proposal[1]_ to relax the guidelines for packages with multiple > versions. After some discussion it was decided that restricting the > maintainer too much is not desirable. ACK. > I'd like to have votes on relaxing the guidelines as follows: > > ''' > For many reasons, it is sometimes advantageous to keep multiple versions > of a package in Fedora to be installed simultaneously. When doing so, > the package name should reflect this fact. One package should use the > base name with no versions and all other addons should note their > version in the name. > ''' > This gives the maintainer the leeway to choose whether the package is > best served by having the latest version carry the unadorned name > forward or the previous version. Though consider this proposal to be a step into the correct direction, I don't think it goes far enough. It still recommends "one version package w/ no version". IMO, this recommendation is more confusing than helpful and should also be removed. [Consider "gtk->gtk2"-like cases: in long term, one can expect gtk to die out and gtk2 to remain. The recommendation could be interpreted as recommendation to rename gtk2, then.] => +1, but ... proposal: Let's also remove the "no version recommendation". Ralf From a.badger at gmail.com Thu Jul 5 16:25:19 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 05 Jul 2007 09:25:19 -0700 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183628397.22644.14.camel@mccallum.corsepiu.local> References: <1183486603.5355.62.camel@localhost.localdomain> <1183628397.22644.14.camel@mccallum.corsepiu.local> Message-ID: <1183652719.31594.6.camel@localhost.localdomain> On Thu, 2007-07-05 at 11:39 +0200, Ralf Corsepius wrote: > On Tue, 2007-07-03 at 11:16 -0700, Toshio Kuratomi wrote: > > ''' > > For many reasons, it is sometimes advantageous to keep multiple versions > > of a package in Fedora to be installed simultaneously. When doing so, > > the package name should reflect this fact. One package should use the > > base name with no versions and all other addons should note their > > version in the name. > > ''' > > > This gives the maintainer the leeway to choose whether the package is > > best served by having the latest version carry the unadorned name > > forward or the previous version. > Though consider this proposal to be a step into the correct direction, I > don't think it goes far enough. > > It still recommends "one version package w/ no version". IMO, this > recommendation is more confusing than helpful and should also be > removed. > > [Consider "gtk->gtk2"-like cases: in long term, one can expect gtk to > die out and gtk2 to remain. The recommendation could be interpreted as > recommendation to rename gtk2, then.] > > => +1, but ... proposal: Let's also remove the "no version > recommendation". Okay -- with spot's[1]_ +1 in the earlier thread for the same proposal and my +1 that's six in favor. Tentatively approved but need to send it to FESCo for review now. Ralf's change makes sense as well. spot, if you're working on adding compat-* guidelines, do you want to work this in or should I add it to next week's agenda separately? (There's a review pending on this change so I want to keep the first part moving forward.) .. [1] https://www.redhat.com/archives/fedora-packaging/2007-July/msg00013.html -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 tcallawa at redhat.com Thu Jul 5 16:37:22 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 05 Jul 2007 11:37:22 -0500 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183652719.31594.6.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> <1183628397.22644.14.camel@mccallum.corsepiu.local> <1183652719.31594.6.camel@localhost.localdomain> Message-ID: <1183653442.3497.14.camel@localhost.localdomain> On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote: > Ralf's change makes sense as well. spot, if you're working on adding > compat-* guidelines, do you want to work this in or should I add it to > next week's agenda separately? (There's a review pending on this change > so I want to keep the first part moving forward.) No, go ahead. I don't know when I will get to the compat guidelines. ~spot From rc040203 at freenet.de Thu Jul 5 16:55:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Jul 2007 18:55:10 +0200 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183653442.3497.14.camel@localhost.localdomain> References: <1183486603.5355.62.camel@localhost.localdomain> <1183628397.22644.14.camel@mccallum.corsepiu.local> <1183652719.31594.6.camel@localhost.localdomain> <1183653442.3497.14.camel@localhost.localdomain> Message-ID: <1183654510.22644.32.camel@mccallum.corsepiu.local> On Thu, 2007-07-05 at 11:37 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote: > > > Ralf's change makes sense as well. spot, if you're working on adding > > compat-* guidelines, do you want to work this in or should I add it to > > next week's agenda separately? (There's a review pending on this change > > so I want to keep the first part moving forward.) > > No, go ahead. I don't know when I will get to the compat guidelines. The question to discuss would be: Under which circumstance are they applicable and when should the N approach be preferred. I am inclined to think the N approach to be more versatile and generally applicable (esp. cases of "fully parallel installable packages"), while the compat-* approach is aiming at providing "backward compatible run-time packages" (in particular lib-packages). Ralf From tcallawa at redhat.com Thu Jul 5 17:05:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 05 Jul 2007 12:05:35 -0500 Subject: [Fedora-packaging] [Vote] Multiple version naming overly restrictive In-Reply-To: <1183654510.22644.32.camel@mccallum.corsepiu.local> References: <1183486603.5355.62.camel@localhost.localdomain> <1183628397.22644.14.camel@mccallum.corsepiu.local> <1183652719.31594.6.camel@localhost.localdomain> <1183653442.3497.14.camel@localhost.localdomain> <1183654510.22644.32.camel@mccallum.corsepiu.local> Message-ID: <1183655135.3497.18.camel@localhost.localdomain> On Thu, 2007-07-05 at 18:55 +0200, Ralf Corsepius wrote: > On Thu, 2007-07-05 at 11:37 -0500, Tom "spot" Callaway wrote: > > On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote: > > > > > Ralf's change makes sense as well. spot, if you're working on adding > > > compat-* guidelines, do you want to work this in or should I add it to > > > next week's agenda separately? (There's a review pending on this change > > > so I want to keep the first part moving forward.) > > > > No, go ahead. I don't know when I will get to the compat guidelines. > The question to discuss would be: Under which circumstance are they > applicable and when should the N approach be preferred. > > I am inclined to think the N approach to be more versatile and > generally applicable (esp. cases of "fully parallel installable > packages"), while the compat-* approach is aiming at providing "backward > compatible run-time packages" (in particular lib-packages). Yes, I feel the same way. Feel free to draft up text if you are unwilling to wait for me to get around to it. :) ~spot From a.badger at gmail.com Tue Jul 10 12:20:29 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Jul 2007 05:20:29 -0700 Subject: [Fedora-packaging] Mising today's meeting Message-ID: Hey all, I'm travelling today and most likely will be in the air during today's packaging meeting. -Toshio From roland at redhat.com Tue Jul 10 21:24:08 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 10 Jul 2007 14:24:08 -0700 (PDT) Subject: [Fedora-packaging] build ID -debuginfo rpm convention Message-ID: <20070710212408.77E954D0585@magilla.localdomain> I saw in the archives there were actually a couple of replies, though I received none. I guess the list breaks proper reply-to and cc and so people weren't cc'ing me (I'm not on the list). The two questions made it sound like noone read http://fedoraproject.org/wiki/RolandMcGrath/BuildID where the whole plan is explained in detail. The ID bits are the thing you have from the core file that makes it possible (via the /usr/lib/debug/.build-id/ convention) to figure out which binaries you need. I really am not seeking your advice on the overall plan; please don't take offense when I don't try to convince you it is worthwhile. I am asking this list about the rpm packaging convention, and I would really like some more feedback about that. (The answer about symlinks was very helpful.) Thanks, Roland From rdieter at math.unl.edu Wed Jul 11 12:41:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 07:41:55 -0500 Subject: [Fedora-packaging] Re: rpm installation tests / script tests References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: Florian La Roche wrote: > anything holding back an update of the default snippets we > propose for Fedora until a more permanent solution in > rpm/tools is available? The Snippets wiki has been updated, after getting feedback on the fedora-desktop list. -- Rex > ----- Forwarded message from Rex Dieter ----- > > From: Rex Dieter > Subject: Re: rpm installation tests / script tests > To: fedora-maintainers at redhat.com > Date: Tue, 10 Jul 2007 06:26:41 -0500 > > Alain PORTAL wrote: > > >> This is the same error for the 3 packages >> ERROR: Output running post uninstall script for package >> piklab-0:0.14.2-2.fc7.i386 >> /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such >> file or directory >> >> but >> > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda >> said "Note that no dependencies should be added for this." >> >> So, what we have to do? > > Hrm, looks like an oversight in the guidelines... should probably wrap the > call in something like: > 1. if [ -x /usr/bin/gtk-update-icon-cache ]; then ... > or > 2. redirect output (using something like >& /dev/null > (I use the latter mostly). > > -- Rex From tmz at pobox.com Wed Jul 11 16:44:10 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 11 Jul 2007 12:44:10 -0400 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: <20070711164410.GB32408@psilocybe.teonanacatl.org> Rex Dieter wrote: > The Snippets wiki has been updated, after getting feedback on the > fedora-desktop list. I don't see any change at http://fedoraproject.org/wiki/Packaging/ScriptletSnippets Do I need need special glasses, more sugar, special narcotics, patience, or all of the above? I poked in the desktop list archives and it seems the preference there was to test for gtk-update-icon-cache rather than ignore all output. So the scriptlet should now look like this (correcting any wrapping peoples mail clients do)? if [ -x %{_bindir}/gtk-update-icon-cache ]; then %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hardware: the parts of a computer that can be kicked. -- Jeff Pesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jul 11 16:49:33 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 11:49:33 -0500 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <20070711164410.GB32408@psilocybe.teonanacatl.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> Message-ID: <46950A1D.3080309@math.unl.edu> Todd Zullinger wrote: > Rex Dieter wrote: >> The Snippets wiki has been updated, after getting feedback on the >> fedora-desktop list. > > I don't see any change at > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets > > Do I need need special glasses, more sugar, special narcotics, > patience, or all of the above? Arg, I swear I *did* do it, and I'm not crazy (: , but sure enough, it's not there. I'll go do it (again). -- Rex From nicolas.mailhot at laposte.net Wed Jul 11 16:57:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jul 2007 18:57:51 +0200 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <20070711164410.GB32408@psilocybe.teonanacatl.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> Message-ID: <1184173071.3978.0.camel@rousalka.dyndns.org> Le mercredi 11 juillet 2007 ? 12:44 -0400, Todd Zullinger a ?crit : > So the scriptlet should now look like this (correcting any wrapping > peoples mail clients do)? > > if [ -x %{_bindir}/gtk-update-icon-cache ]; then > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > fi What's the point of || : ? -- 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 rdieter at math.unl.edu Wed Jul 11 17:01:08 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 12:01:08 -0500 Subject: [Fedora-packaging] Re: Re: rpm installation tests / script tests References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <1184173071.3978.0.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le mercredi 11 juillet 2007 ? 12:44 -0400, Todd Zullinger a ?crit : > >> So the scriptlet should now look like this (correcting any wrapping >> peoples mail clients do)? >> >> if [ -x %{_bindir}/gtk-update-icon-cache ]; then >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || >> : >> fi > > > What's the point of || : ? scriptlets failing -> aborted rpm transaction -> harmed kittens. -- Rex From herrold at owlriver.com Wed Jul 11 17:19:31 2007 From: herrold at owlriver.com (R P Herrold) Date: Wed, 11 Jul 2007 13:19:31 -0400 (EDT) Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <1184173071.3978.0.camel@rousalka.dyndns.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <1184173071.3978.0.camel@rousalka.dyndns.org> Message-ID: On Wed, 11 Jul 2007, Nicolas Mailhot wrote: >> if [ -x %{_bindir}/gtk-update-icon-cache ]; then >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : >> fi > What's the point of || : ? to silently hide problems, rather than to fix them, and to return a success error code after the fact of failure -- Russ Herrold From nicolas.mailhot at laposte.net Wed Jul 11 17:27:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jul 2007 19:27:03 +0200 Subject: [Fedora-packaging] Re: Re: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <1184173071.3978.0.camel@rousalka.dyndns.org> Message-ID: <1184174823.3978.3.camel@rousalka.dyndns.org> Le mercredi 11 juillet 2007 ? 12:01 -0500, Rex Dieter a ?crit : > Nicolas Mailhot wrote: > > > Le mercredi 11 juillet 2007 ? 12:44 -0400, Todd Zullinger a ?crit : > > > >> So the scriptlet should now look like this (correcting any wrapping > >> peoples mail clients do)? > >> > >> if [ -x %{_bindir}/gtk-update-icon-cache ]; then > >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || > >> : > >> fi > > > > > > What's the point of || : ? > > scriptlets failing -> aborted rpm transaction -> harmed kittens. But aren't kittens already protected by the if ? fi ? -- 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 rdieter at math.unl.edu Wed Jul 11 17:42:57 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 12:42:57 -0500 Subject: [Fedora-packaging] Re: Re: rpm installation tests / script tests In-Reply-To: <1184174823.3978.3.camel@rousalka.dyndns.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <1184173071.3978.0.camel@rousalka.dyndns.org> <1184174823.3978.3.camel@rousalka.dyndns.org> Message-ID: <469516A1.1050707@math.unl.edu> Nicolas Mailhot wrote: > Le mercredi 11 juillet 2007 ? 12:01 -0500, Rex Dieter a ?crit : >> Nicolas Mailhot wrote: >> >>> Le mercredi 11 juillet 2007 ? 12:44 -0400, Todd Zullinger a ?crit : >>> >>>> So the scriptlet should now look like this (correcting any wrapping >>>> peoples mail clients do)? >>>> >>>> if [ -x %{_bindir}/gtk-update-icon-cache ]; then >>>> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || >>>> : >>>> fi >>> >>> What's the point of || : ? >> scriptlets failing -> aborted rpm transaction -> harmed kittens. > > > But aren't kittens already protected by the if ? fi ? Not if gtk-update-icon-cache crashes, or errors in some other way... -- Rex From rdieter at math.unl.edu Wed Jul 11 17:49:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 12:49:14 -0500 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <20070711164410.GB32408@psilocybe.teonanacatl.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> Message-ID: <4695181A.40000@math.unl.edu> Todd Zullinger wrote: > I poked in the desktop list archives and it seems the preference there > was to test for gtk-update-icon-cache rather than ignore all output. There are a few other examples that currently use >& /dev/null instead of using [ -x ... ] wrapping, I'll go ahead and update those as well, so that these are all consistent. -- Rex From tmz at pobox.com Wed Jul 11 18:02:56 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 11 Jul 2007 14:02:56 -0400 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <4695181A.40000@math.unl.edu> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <4695181A.40000@math.unl.edu> Message-ID: <20070711180256.GC32408@psilocybe.teonanacatl.org> Rex Dieter wrote: > There are a few other examples that currently use>& /dev/null > instead of using [ -x ... ] wrapping, I'll go ahead and update those > as well, so that these are all consistent. I notice that some of the scriptlets use _bindir while others just call the program without a path. Unless a program is installed in some hard-coded location (i.e. /sbin/service, I think) or is not in the standard path, wouldn't it be simpler and more consistent to skip the path (in the program call, not in the -x test of course). One other very minor detail, but since people will often just copy/paste these, could the icon cache run be indented in the if block? I see you already updated the fc-cache scriptlet to use the _bindir macro, I was going to mention that as a little detail. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If a government were put in charge of the Sahara Desert, within five years they'd have a shortage of sand. -- Dr. Milton Friedman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jul 11 21:56:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Jul 2007 23:56:06 +0200 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <1184174823.3978.3.camel@rousalka.dyndns.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711164410.GB32408@psilocybe.teonanacatl.org> <1184173071.3978.0.camel@rousalka.dyndns.org> <1184174823.3978.3.camel@rousalka.dyndns.org> Message-ID: <20070711215606.GN10275@puariko.nirvana> On Wed, Jul 11, 2007 at 07:27:03PM +0200, Nicolas Mailhot wrote: > Le mercredi 11 juillet 2007 ? 12:01 -0500, Rex Dieter a ?crit : > > Nicolas Mailhot wrote: > > > > > Le mercredi 11 juillet 2007 ? 12:44 -0400, Todd Zullinger a ?crit : > > > > > >> So the scriptlet should now look like this (correcting any wrapping > > >> peoples mail clients do)? > > >> > > >> if [ -x %{_bindir}/gtk-update-icon-cache ]; then > > >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || > > >> : > > >> fi > > > > > > > > > What's the point of || : ? > > > > scriptlets failing -> aborted rpm transaction -> harmed kittens. > > > But aren't kittens already protected by the if ? fi ? > $ if /bin/true; then /bin/false; fi || echo no, they are not no, they are not Please stop animal testing. -- 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 Thu Jul 12 16:12:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jul 2007 11:12:16 -0500 Subject: [Fedora-packaging] Re: rpm installation tests / script tests References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070712153328.GA3857@dudweiler.stuttgart.redhat.com> Message-ID: Florian La Roche wrote on fedora-maintainers > On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: >> Florian La Roche wrote: >> > anything holding back an update of the default snippets we >> > propose for Fedora until a more permanent solution in >> > rpm/tools is available? >> The Snippets wiki has been updated, after getting feedback on the >> fedora-desktop list. > it still says that no deps are needed, but should list a dependency > for touch/coreutils in there. At first, I thought http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30-2 applied here, but that's only for BuildRequires. Do we need to come up with a similar list for packages assumed to be present at run-time, stuff like: glibc kernel coreutils ?? -- Rex From pertusus at free.fr Thu Jul 12 16:15:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Jul 2007 18:15:18 +0200 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070712153328.GA3857@dudweiler.stuttgart.redhat.com> Message-ID: <20070712161518.GC3073@free.fr> On Thu, Jul 12, 2007 at 11:12:16AM -0500, Rex Dieter wrote: > Do we need to come up with a similar list for packages assumed to be present > at run-time, stuff like: > glibc kernel coreutils > ?? Unless I'm wrong coreutils shouldn't be assumed to be installed (although it could be assumed that it gets installed) during the prescript run, for example if installing in a chroot. I guess that sh (or /bin/sh) may be assumed to be installed, however. -- Pat From notting at redhat.com Thu Jul 12 21:03:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Jul 2007 17:03:55 -0400 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: <20070712161518.GC3073@free.fr> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070712153328.GA3857@dudweiler.stuttgart.redhat.com> <20070712161518.GC3073@free.fr> Message-ID: <20070712210355.GB10103@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > Unless I'm wrong coreutils shouldn't be assumed to be installed > (although it could be assumed that it gets installed) during the > prescript run, for example if installing in a chroot. I guess that sh > (or /bin/sh) may be assumed to be installed, however. sh is added automatically as a prereq. coreutils would need explicitly listed. Bill From jkeating at redhat.com Tue Jul 17 15:11:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 11:11:46 -0400 Subject: [Fedora-packaging] Absent from meeting today Message-ID: <20070717111146.5a1aa35e@localhost.localdomain> I have a conflict today and won't be able to make the meeting. Spot is traveling and will also not be able to make the meeting. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 17 15:46:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 17 Jul 2007 17:46:40 +0200 Subject: [Fedora-packaging] Absent from meeting today In-Reply-To: <20070717111146.5a1aa35e@localhost.localdomain> References: <20070717111146.5a1aa35e@localhost.localdomain> Message-ID: <1184687200.5613.37.camel@mccallum.corsepiu.local> On Tue, 2007-07-17 at 11:11 -0400, Jesse Keating wrote: > I have a conflict today and won't be able to make the meeting. > > Spot is traveling and will also not be able to make the meeting. I am on vacation this and the following 2 weeks. I.e. it's very likely for me not to be able to join the next 3 meetings. Ralf From petersen at redhat.com Wed Jul 18 00:50:42 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 18 Jul 2007 10:50:42 +1000 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1179838056.6254.266.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> Message-ID: <469D63E2.2090807@redhat.com> Sorry I failed to follow to this thread earlier, rolled off my radar. :/ (I need to find a better way of tracking followups to my posts...) Tom "spot" Callaway ????????: > On Tue, 2007-05-22 at 10:29 +0100, Jonathan Underwood wrote: >> On 22/05/07, Jens Petersen wrote: >>> I still think the emacs-common prefix is confusing with the emacs-common >>> package [...] >> Jens, you're of course right. The fact that emacs-common is a >> subpackage of emacs didn't come up during the discussions a year ago. >> I did try for "emacsen" but people didn't like that so much, am not >> sure why. Well I don't like "emacsen" either... >> Anyway, I'm happy to revisit the package naming guidelines for >> (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have >> strong feelings either way? My suggestion is just to go with emacs-* rather than emacs-common-*. It is a pretty small change and already quite a number of older elisp packages follow it. > I'm not convinced that emacs-common-foo is broken as a naming scheme. IMHO it is too verbose and it makes it hard to read and find emacs packages. > Then again, I'm not an emacs user. I think it would be better if emacs/xemacs users had more say in setting the naming convention. Jens From jonathan.underwood at gmail.com Fri Jul 20 10:06:52 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 11:06:52 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <469D63E2.2090807@redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> Message-ID: <645d17210707200306u2fa51250vf5901ac0d04884e1@mail.gmail.com> On 18/07/07, Jens Petersen wrote: > Well I don't like "emacsen" either... > > >> Anyway, I'm happy to revisit the package naming guidelines for > >> (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have > >> strong feelings either way? > > My suggestion is just to go with emacs-* rather than emacs-common-*. > It is a pretty small change and already quite a number of older > elisp packages follow it. > Jens, please review the previous discussions on this so we don't have to rehash exactly the same old arguments - in this thread I have earlier pointed to the past discussions. The problem arises when a package is an add-on for both GNU Emacs and XEmacs. In that case there ARE subpackages called emacs-foo and xemacs-foo for each flavour. But that means the main package name can't also be emacs-foo. > > I'm not convinced that emacs-common-foo is broken as a naming scheme. > > IMHO it is too verbose and it makes it hard to read and find emacs packages. > Why? I want to install the muse package for Emacs. So I type yum install emacs-muse. That of course also pulls in emacs-common-muse. What is so hard about this for a user? > > Then again, I'm not an emacs user. > > I think it would be better if emacs/xemacs users had more say in setting > the naming convention. > Well, I agree, but this mailing list is the forum for that to happen. Emacs/XEmacs users are having the same opportunities to comment on package naming guidelines here that users generally have to comment on package naming (i.e. not a lot). From jonathan.underwood at gmail.com Fri Jul 20 10:18:08 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 11:18:08 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <469D63E2.2090807@redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> Message-ID: <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> On 18/07/07, Jens Petersen wrote: > My suggestion is just to go with emacs-* rather than emacs-common-*. > It is a pretty small change and already quite a number of older > elisp packages follow it. If I understand correctly, this would translate to: main package: emacs-foo, containing files specific to GNU Emacs sub package: emacs-foo-common, containing files not specific to any Emacs flavour sub-package: xemacs-foo, containing files specific to XEmacs sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp source for each flavour. This is essentially was my very first original proposal, but people weren't keen on it as it uses the term emacs as a generalization for emacs flavours, and as a specific for GNU Emacs. I do happen to prefer this though, and tend to agree with Jens. If I recall, at least Tom didn't like it. J. From jonathan.underwood at gmail.com Fri Jul 20 10:20:40 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 11:20:40 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> Message-ID: <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> On 20/07/07, Jonathan Underwood wrote: > If I understand correctly, this would translate to: > > main package: emacs-foo, containing files specific to GNU Emacs > sub package: emacs-foo-common, containing files not specific to any > Emacs flavour > sub-package: xemacs-foo, containing files specific to XEmacs > sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp > source for each flavour. > > This is essentially was my very first original proposal, but people > weren't keen on it as it uses the term emacs as a generalization for > emacs flavours, and as a specific for GNU Emacs. I should also point out that the above proposal doesn't treat GNU Emacs and XEmacs on an equal footing - the XEmacs package being a sub package and the GNU Emacs package being the main package. The current emacs-common-foo scheme does not have that bias. From tcallawa at redhat.com Fri Jul 20 13:01:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 20 Jul 2007 08:01:59 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> <1179838056.6254.266.camel@localhost.localdomain> <469D63E2.2090807@redhat.com> <645d17210707200318l7c3fa561i8b85a8e70b41288a@mail.gmail.com> <645d17210707200320s58ad567codc98913e9e969aeb@mail.gmail.com> Message-ID: <1184936519.4026.80.camel@localhost.localdomain> On Fri, 2007-07-20 at 11:20 +0100, Jonathan Underwood wrote: > On 20/07/07, Jonathan Underwood wrote: > > If I understand correctly, this would translate to: > > > > main package: emacs-foo, containing files specific to GNU Emacs > > sub package: emacs-foo-common, containing files not specific to any > > Emacs flavour > > sub-package: xemacs-foo, containing files specific to XEmacs > > sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp > > source for each flavour. > > > > This is essentially was my very first original proposal, but people > > weren't keen on it as it uses the term emacs as a generalization for > > emacs flavours, and as a specific for GNU Emacs. > > I should also point out that the above proposal doesn't treat GNU > Emacs and XEmacs on an equal footing - the XEmacs package being a sub > package and the GNU Emacs package being the main package. The current > emacs-common-foo scheme does not have that bias. This is one of the main reasons why I prefer the current scheme, because I don't have to pull people apart while fighting "my editor is better" wars. :) ~spot From Axel.Thimm at ATrpms.net Fri Jul 20 12:49:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 20 Jul 2007 14:49:25 +0200 Subject: [Fedora-packaging] Re: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070712153328.GA3857@dudweiler.stuttgart.redhat.com> Message-ID: <20070720124925.GB32120@puariko.nirvana> On Thu, Jul 12, 2007 at 11:12:16AM -0500, Rex Dieter wrote: > Florian La Roche wrote on fedora-maintainers > > On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: > >> Florian La Roche wrote: > > >> > anything holding back an update of the default snippets we > >> > propose for Fedora until a more permanent solution in > >> > rpm/tools is available? > > >> The Snippets wiki has been updated, after getting feedback on the > >> fedora-desktop list. > > > it still says that no deps are needed, but should list a dependency > > for touch/coreutils in there. > > At first, I thought > http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30-2 > applied here, but that's only for BuildRequires. > > Do we need to come up with a similar list for packages assumed to be present > at run-time, stuff like: > glibc kernel coreutils > ?? glibc is always pulled in via rpm's soname dependency mechanism, kernel please not, as it is already a pain to run a chroot w/o a kernel due to some dependencies. coreutils probably yes, but some packages need to be exempted (probably filesystem and setup) -- 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 Tue Jul 24 16:47:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Jul 2007 11:47:02 -0500 Subject: [Fedora-packaging] Missing the meeting today Message-ID: <1185295622.7646.52.camel@localhost.localdomain> Sorry guys, but I'm going to be missing the meeting today. I'd hoped to be able to at least put forward a draft for the Licensing issue, but I'm still buried in boxes. I'll try to get something written up this week, and send it to the list. ~spot From krzyzowiec at yahoo.com Tue Jul 24 19:17:47 2007 From: krzyzowiec at yahoo.com (Adam Ornat) Date: Tue, 24 Jul 2007 12:17:47 -0700 (PDT) Subject: [Fedora-packaging] Duplicate pacakges question Message-ID: <892548.60903.qm@web51110.mail.re2.yahoo.com> Is there a utility that identifies/deletes duplicate (older version) packages in Fedora? Thanks, Art From rtlm10 at gmail.com Tue Jul 24 19:57:43 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Tue, 24 Jul 2007 15:57:43 -0400 Subject: [Fedora-packaging] Duplicate pacakges question In-Reply-To: <892548.60903.qm@web51110.mail.re2.yahoo.com> References: <892548.60903.qm@web51110.mail.re2.yahoo.com> Message-ID: <1ed4a0130707241257l7f928481x7531f18c9fa4720b@mail.gmail.com> On 7/24/07, Adam Ornat wrote: > Is there a utility that identifies/deletes duplicate > (older version) packages in Fedora? Part of the yum-utils package is the package-cleanup command. Run package-cleanup -h to see the options related to detecting and cleaning duplicate packages. Russell ---- Russell Harrison Systems Administrator -- Linux Desktops Cisco Systems, Inc. From krzyzowiec at yahoo.com Wed Jul 25 19:54:10 2007 From: krzyzowiec at yahoo.com (Adam Ornat) Date: Wed, 25 Jul 2007 12:54:10 -0700 (PDT) Subject: [Fedora-packaging] kmod-madwifi Message-ID: <632063.20767.qm@web51102.mail.re2.yahoo.com> Does anybody know how soon there will be a new version of a kmod-madwifi package for a 2.6.22.1-27.fc7 kernel? Thanks, Art From tmz at pobox.com Wed Jul 25 20:09:32 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 25 Jul 2007 16:09:32 -0400 Subject: [Fedora-packaging] kmod-madwifi In-Reply-To: <632063.20767.qm@web51102.mail.re2.yahoo.com> References: <632063.20767.qm@web51102.mail.re2.yahoo.com> Message-ID: <20070725200932.GB2025@psilocybe.teonanacatl.org> Adam Ornat wrote: > Does anybody know how soon there will be a new version of a > kmod-madwifi package for a 2.6.22.1-27.fc7 kernel? This is far off-topic for this list[1]. It's also not in any official repositories, so you'll need to ask the folks that package the module about it. Livna ships it, AFAIK. See their mailing list. [1] The short description for this list is: Discussion of RPM packaging standards and practices for Fedora -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Quick to judge, quick to anger, slow to understand. Ignorance and prejudice and fear walk hand in hand. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From krzyzowiec at yahoo.com Wed Jul 25 20:14:01 2007 From: krzyzowiec at yahoo.com (Adam Ornat) Date: Wed, 25 Jul 2007 13:14:01 -0700 (PDT) Subject: [Fedora-packaging] kmod-madwifi In-Reply-To: <20070725200932.GB2025@psilocybe.teonanacatl.org> Message-ID: <302202.14206.qm@web51112.mail.re2.yahoo.com> Thanks. --- Todd Zullinger wrote: > Adam Ornat wrote: > > Does anybody know how soon there will be a new > version of a > > kmod-madwifi package for a 2.6.22.1-27.fc7 kernel? > > This is far off-topic for this list[1]. It's also > not in any official > repositories, so you'll need to ask the folks that > package the module > about it. Livna ships it, AFAIK. See their mailing > list. > > [1] The short description for this list is: > Discussion of RPM packaging standards and > practices for Fedora > > -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: > www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Quick to judge, quick to anger, slow to understand. > Ignorance and prejudice and fear walk hand in hand. > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From a.badger at gmail.com Tue Jul 24 19:34:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 24 Jul 2007 12:34:34 -0700 Subject: [Fedora-packaging] Users and groups -- the static alternative Message-ID: <1185305674.4709.76.camel@localhost.localdomain> The Packaging committee has been discussing users and groups for a long time, coming up with increasingly elaborate methods of solving the problems with dynamic allocation of uids. As an alternative we want to explore biting the bullet and just allocating another uid range for static assignment. We thought of two possible ways to do this that made some sense: 1) Allocate the uids at the high end of the 32 bit range: 2**32-(range) to avoid the uids being used on as many systems as possible. 2) Work with another distro to share the range of static uids. What do people think of this? Will it cause pain for too many sites? Is it an acceptable cost to avoid having to debate dynamic vs static uids for every package review in the future? -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 Wed Jul 25 23:42:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Jul 2007 01:42:03 +0200 Subject: [Fedora-packaging] Re: Users and groups -- the static alternative In-Reply-To: <1185305674.4709.76.camel@localhost.localdomain> References: <1185305674.4709.76.camel@localhost.localdomain> Message-ID: <20070725234203.GF14940@puariko.nirvana> On Tue, Jul 24, 2007 at 12:34:34PM -0700, Toshio Kuratomi wrote: > The Packaging committee has been discussing users and groups for a long > time, coming up with increasingly elaborate methods of solving the > problems with dynamic allocation of uids. > > As an alternative we want to explore biting the bullet and just > allocating another uid range for static assignment. > We thought of two possible ways to do this that made some sense: > > 1) Allocate the uids at the high end of the 32 bit range: 2**32-(range) > to avoid the uids being used on as many systems as possible. > > 2) Work with another distro to share the range of static uids. > > What do people think of this? Will it cause pain for too many sites? > Is it an acceptable cost to avoid having to debate dynamic vs static > uids for every package review in the future? Ville's proposal was fine, what are we really trying to fix that will force us to break with FHS and several large sites? If static uids are ***really*** required for a networked application, then you don't only have to coordinate with "another distro", but with all of them as well as all Unices, so it's a lost cause to start with. And if one argues that one doesn't need the same uid/gid on all systems to start a Unix-global registry, then why doe Fedora need it? Don't fix something that isn't broken. -- 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 Thu Jul 26 01:15:02 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 26 Jul 2007 11:15:02 +1000 Subject: [Fedora-packaging] why not %{_datadir} on fonts scripletsnippet Message-ID: <46A7F596.7020101@redhat.com> Hi, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 The "Fonts" scriptlets currently have: %{_bindir}/fc-cache /usr/share/fonts is there some subtle reason for not using %{_datadir} here? I'll for responses before changing it to: %{_bindir}/fc-cache %{_datadir}/fonts Jens -- Jens Petersen Internationalization Team Red Hat From nicolas.mailhot at laposte.net Thu Jul 26 08:07:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 26 Jul 2007 10:07:35 +0200 (CEST) Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: <1185305674.4709.76.camel@localhost.localdomain> References: <1185305674.4709.76.camel@localhost.localdomain> Message-ID: <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> Le Mar 24 juillet 2007 21:34, Toshio Kuratomi a ?crit : > 2) Work with another distro to share the range of static uids. > > What do people think of this? Will it cause pain for too many sites? > Is it an acceptable cost to avoid having to debate dynamic vs static > uids for every package review in the future? +1 for finding interested contacts in other distros and just submit a request to the LSB to have the static range expanded You have to realise static UID scarcity is a big reason UIDs vary from distro to distro - given UID shortage each distro priorises the packages it cares most about and as a result the attribution choices vary. With a non-scarce range new UIDs and (and later historical UIDs) could just nicely converge. -- Nicolas Mailhot From ssorce at redhat.com Thu Jul 26 08:22:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 26 Jul 2007 04:22:05 -0400 Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> References: <1185305674.4709.76.camel@localhost.localdomain> <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> Message-ID: <1185438125.6631.95.camel@hopeson> On Thu, 2007-07-26 at 10:07 +0200, Nicolas Mailhot wrote: > Le Mar 24 juillet 2007 21:34, Toshio Kuratomi a ?crit : > > > 2) Work with another distro to share the range of static uids. > > > > What do people think of this? Will it cause pain for too many sites? > > Is it an acceptable cost to avoid having to debate dynamic vs static > > uids for every package review in the future? > > +1 for finding interested contacts in other distros and just submit a > request to the LSB to have the static range expanded > > You have to realise static UID scarcity is a big reason UIDs vary from > distro to distro - given UID shortage each distro priorises the > packages it cares most about and as a result the attribution choices > vary. > > With a non-scarce range new UIDs and (and later historical UIDs) could > just nicely converge. With 4 billion UIDs claiming UIDs are a scarce resource is a bit excessive. It's just that nobody has the courage to break with the past and bump up the reserved UID space or even just move to a more creative approaches. Simo. From nicolas.mailhot at laposte.net Thu Jul 26 09:41:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 26 Jul 2007 11:41:53 +0200 (CEST) Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: <1185438125.6631.95.camel@hopeson> References: <1185305674.4709.76.camel@localhost.localdomain> <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> <1185438125.6631.95.camel@hopeson> Message-ID: <43039.192.54.193.51.1185442913.squirrel@rousalka.dyndns.org> Le Jeu 26 juillet 2007 10:22, Simo Sorce a ?crit : > With 4 billion UIDs claiming UIDs are a scarce resource is a bit > excessive. I was talking of the artificial static UID scarcity created by assigning a ridiculously small range to them of course -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Thu Jul 26 11:35:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Jul 2007 13:35:28 +0200 Subject: [Fedora-packaging] Re: Users and groups -- the static alternative In-Reply-To: <20070725234203.GF14940@puariko.nirvana> References: <1185305674.4709.76.camel@localhost.localdomain> <20070725234203.GF14940@puariko.nirvana> Message-ID: <20070726113528.GB1720@puariko.nirvana> On Thu, Jul 26, 2007 at 01:42:03AM +0200, Axel Thimm wrote: > Ville's proposal was fine, what are we really trying to fix that will > force us to break with FHS and several large sites? s/break with FHS/break with LSB/ -- 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 Thu Jul 26 13:57:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jul 2007 08:57:16 -0500 Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet References: <46A7F596.7020101@redhat.com> Message-ID: Jens Petersen wrote: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 > The "Fonts" scriptlets currently have: > %{_bindir}/fc-cache /usr/share/fonts > is there some subtle reason for not using %{_datadir} here? afaik, no. > I'll for responses before changing it to: > %{_bindir}/fc-cache %{_datadir}/fonts do it. Maybe even go one step further, and either say change to %{_bindir}/fc-cache or even just %{_bindir}/fc-cache -- Rex From nicolas.mailhot at laposte.net Thu Jul 26 14:08:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 26 Jul 2007 16:08:12 +0200 (CEST) Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: References: <46A7F596.7020101@redhat.com> Message-ID: <40279.192.54.193.51.1185458892.squirrel@rousalka.dyndns.org> Le Jeu 26 juillet 2007 15:57, Rex Dieter a ?crit : > Jens Petersen wrote: >> I'll for responses before changing it to: >> %{_bindir}/fc-cache %{_datadir}/fonts > > do it. Maybe even go one step further, and either say change to > %{_bindir}/fc-cache This one is easy as a lot of font specfiles already define a font_dir_actually_used_in_this_pkg shorthand However, I'm not sure if pointing fc-cache just at this dir is worth it. Asking it to refresh everything is safer. -- Nicolas Mailhot From tcallawa at redhat.com Thu Jul 26 23:27:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 18:27:59 -0500 Subject: [Fedora-packaging] License Tag Draft Message-ID: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way: Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing . We'll vote on it next week. Thanks, ~spot From opensource at till.name Thu Jul 26 23:13:47 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 01:13:47 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <200707270113.52971.opensource@till.name> On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote: > and http://fedoraproject.org/wiki/Licensing . Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL Compatibility Matrix? Regards, Till From smooge at gmail.com Thu Jul 26 23:17:30 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Jul 2007 17:17:30 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> On 7/26/07, Tom spot Callaway wrote: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . > > We'll vote on it next week. > I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From a.badger at gmail.com Thu Jul 26 23:18:19 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 16:18:19 -0700 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185491902.19639.70.camel@localhost.localdomain> On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . > > We'll vote on it next week. > I think that's missing a scenario. Covered: You can have License A or License B (Dual license) You can have License A on /usr/bin/foo and License B on /usr/bin/bar (Multiple Licensing) Not Covered: You can have License A on foo.c and License B on bar.c being linked together to form /usr/bin/foobar (A different kind of multiple licensing) With GPLv2 as one of the licenses, this shouldn't be an issue because the GPLv2 states that you can't have additional restrictions so for our purposes[1]_, saying the package is GPL is fine. But there could be code under two licenses in which this does matter, for instance BSD with advert clause and a second license which specifies that modifications must be shipped as patches on top of upstream. [1]_: Provided that "our purposes" is internal package audit and not information for developers. Someone outside Fedora looking for code to include in their project could be interested in knowing that 90% of /usr/bin/foo is public domain and only one GPL source file makes the whole thing GPL. -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 j2solutions.net Thu Jul 26 23:19:04 2007 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 26 Jul 2007 19:19:04 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> Message-ID: <20070726191904.4a826f4a@ender> On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" wrote: > I find the reading of && || to be a little hard. Wouldnt it be better > to use the or as in the Perl license way? or was there a legal reason > for not to.. beyond that I think the two are good.Parenthesis I do not > have a problem with. Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Jul 27 00:23:13 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 19:23:13 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070726191904.4a826f4a@ender> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> Message-ID: <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote: > On Thu, 26 Jul 2007 17:17:30 -0600 > "Stephen John Smoogen" wrote: > > > I find the reading of && || to be a little hard. Wouldnt it be better > > to use the or as in the Perl license way? or was there a legal reason > > for not to.. beyond that I think the two are good.Parenthesis I do not > > have a problem with. > > Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and > 'and' perhaps? Just guessing. This is precisely why. ~spot From tcallawa at redhat.com Fri Jul 27 00:24:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 19:24:02 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <200707270113.52971.opensource@till.name> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> Message-ID: <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote: > On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote: > > > and http://fedoraproject.org/wiki/Licensing . > > Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL > Compatibility Matrix? Because the FSF makes no distinction. I don't think there would be any difference, since there is not currently a "later". ~spot From mclasen at redhat.com Thu Jul 26 23:25:58 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 26 Jul 2007 19:25:58 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185492358.3616.3.camel@localhost.localdomain> On Thu, 2007-07-26 at 19:23 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote: > > On Thu, 26 Jul 2007 17:17:30 -0600 > > "Stephen John Smoogen" wrote: > > > > > I find the reading of && || to be a little hard. Wouldnt it be better > > > to use the or as in the Perl license way? or was there a legal reason > > > for not to.. beyond that I think the two are good.Parenthesis I do not > > > have a problem with. > > > > Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and > > 'and' perhaps? Just guessing. > > This is precisely why. Looks entirely over the top to me. Can we make packaging any harder ? I'm all for somewhat accurate license tags, but if the goal is to make spec files machine parsable, then why not go to xml straight away ? And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ? From a.badger at gmail.com Thu Jul 26 23:34:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 16:34:00 -0700 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185492843.19639.75.camel@localhost.localdomain> On Thu, 2007-07-26 at 19:24 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote: > > On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote: > > > > > and http://fedoraproject.org/wiki/Licensing . > > > > Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL > > Compatibility Matrix? > > Because the FSF makes no distinction. I don't think there would be any > difference, since there is not currently a "later". > If this is true, I have a slightly cosmetic comment: GPL and LGPL get an "or later" clause while other licenses would have to jump through the dual license hoops to achieve the same thing. Perhaps it would be better to define an "operator" to mean or later? (And I nominate "+=" as the most logical and ugliest operator for the job :-) -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 a.badger at gmail.com Thu Jul 26 23:47:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 16:47:14 -0700 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492358.3616.3.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> <1185492358.3616.3.camel@localhost.localdomain> Message-ID: <1185493637.19639.82.camel@localhost.localdomain> On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote: > And what is the purpose of commenting licenses in the file list, apart > from making the packagers life miserable ? I agree. Or at least, I disagree with the example and scope in the Draft. I don't think we care what the license of an individual built program is. We might care what the license of a built library is. Whether it's better to mark libraries with a spec comment or make it mandatory to split libraries that are licensed differently from other code, I don't know, though. -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 Jul 27 00:16:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Jul 2007 02:16:00 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185492843.19639.75.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> <1185492843.19639.75.camel@localhost.localdomain> Message-ID: <20070727001600.GE9468@puariko.nirvana> On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote: > On Thu, 2007-07-26 at 19:24 -0500, Tom "spot" Callaway wrote: > > On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote: > > > On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote: > > > > > > > and http://fedoraproject.org/wiki/Licensing . > > > > > > Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL > > > Compatibility Matrix? > > > > Because the FSF makes no distinction. I don't think there would be any > > difference, since there is not currently a "later". > > > If this is true, I have a slightly cosmetic comment: > > GPL and LGPL get an "or later" clause while other licenses would have to > jump through the dual license hoops to achieve the same thing. Perhaps > it would be better to define an "operator" to mean or later? > > (And I nominate "+=" as the most logical and ugliest operator for the > job :-) A comparison operator (>=) would make more sense -- 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 skvidal at linux.duke.edu Fri Jul 27 00:08:48 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 26 Jul 2007 20:08:48 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185493637.19639.82.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> <1185492358.3616.3.camel@localhost.localdomain> <1185493637.19639.82.camel@localhost.localdomain> Message-ID: <1185494928.2409.1.camel@cutter> On Thu, 2007-07-26 at 16:47 -0700, Toshio Kuratomi wrote: > On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote: > > And what is the purpose of commenting licenses in the file list, apart > > from making the packagers life miserable ? > > I agree. Or at least, I disagree with the example and scope in the > Draft. I don't think we care what the license of an individual built > program is. We might care what the license of a built library is. > > Whether it's better to mark libraries with a spec comment or make it > mandatory to split libraries that are licensed differently from other > code, I don't know, though. > How would we know if there is a problem if program X links to lib Y if we don't have the licenses of both available. -sv From Axel.Thimm at ATrpms.net Fri Jul 27 00:18:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Jul 2007 02:18:56 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185492358.3616.3.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> <1185492358.3616.3.camel@localhost.localdomain> Message-ID: <20070727001856.GF9468@puariko.nirvana> On Thu, Jul 26, 2007 at 07:25:58PM -0400, Matthias Clasen wrote: > On Thu, 2007-07-26 at 19:23 -0500, Tom "spot" Callaway wrote: > > On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote: > > > On Thu, 26 Jul 2007 17:17:30 -0600 > > > "Stephen John Smoogen" wrote: > > > > > > > I find the reading of && || to be a little hard. Wouldnt it be better > > > > to use the or as in the Perl license way? or was there a legal reason > > > > for not to.. beyond that I think the two are good.Parenthesis I do not > > > > have a problem with. > > > > > > Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and > > > 'and' perhaps? Just guessing. > > > > This is precisely why. > > Looks entirely over the top to me. Can we make packaging any harder ? > I'm all for somewhat accurate license tags, but if the goal is to make > spec files machine parsable, then why not go to xml straight away ? > And what is the purpose of commenting licenses in the file list, apart > from making the packagers life miserable ? Matthias is right, I start feeling like if we're trying to top Debian on the area of over-bureaucratisation. -- 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 notting at redhat.com Fri Jul 27 00:31:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 20:31:43 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727003143.GA4227@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later). I think the tagging per file in comments is definitely overkill. Bill From tcallawa at redhat.com Fri Jul 27 01:44:22 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 20:44:22 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727003143.GA4227@nostromo.devel.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> Message-ID: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > OK, I know this is going to be painful, but we need to solve this (FESCo > > is waiting for us to do it), and I think this is the cleanest way: > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > and http://fedoraproject.org/wiki/Licensing . > > For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) > and 'GPLv2+' (GPL version 2 or later). > > I think the tagging per file in comments is definitely overkill. Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler. ~spot From notting at redhat.com Fri Jul 27 00:50:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 20:50:06 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727005006.GB4227@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > I think the tagging per file in comments is definitely overkill. > > Most packages won't need it, and for those that do, it will make the > task for whomever is auditing the package (re: me) much simpler. 73 packages that I have installed have some sort of multiple licensing. Bill From tcallawa at redhat.com Fri Jul 27 01:48:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 20:48:17 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727003143.GA4227@nostromo.devel.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> Message-ID: <1185500897.3765.33.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > OK, I know this is going to be painful, but we need to solve this (FESCo > > is waiting for us to do it), and I think this is the cleanest way: > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > and http://fedoraproject.org/wiki/Licensing . > > For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) > and 'GPLv2+' (GPL version 2 or later). I'm not opposed to that. > I think the tagging per file in comments is definitely overkill. Again, most packages won't need this, its only in the case of packages with multiple files that are under different licenses. We're talking less than 1% of packages in Fedora. (Note that documentation licensing doesn't trigger this, nor would differing content licensing in the same package). ~spot From tcallawa at redhat.com Fri Jul 27 01:49:29 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 20:49:29 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727005006.GB4227@nostromo.devel.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> Message-ID: <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > > I think the tagging per file in comments is definitely overkill. > > > > Most packages won't need it, and for those that do, it will make the > > task for whomever is auditing the package (re: me) much simpler. > > 73 packages that I have installed have some sort of multiple licensing. 73 out of how many? How many of those packages could be reworked to use subpackages instead? ~spot From tcallawa at redhat.com Fri Jul 27 01:54:55 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 26 Jul 2007 20:54:55 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 20:49 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote: > > Tom spot Callaway (tcallawa at redhat.com) said: > > > > I think the tagging per file in comments is definitely overkill. > > > > > > Most packages won't need it, and for those that do, it will make the > > > task for whomever is auditing the package (re: me) much simpler. > > > > 73 packages that I have installed have some sort of multiple licensing. > > 73 out of how many? How many of those packages could be reworked to use > subpackages instead? In addition, keep in mind that truly "dual/triple" licensed packages don't need this, only the "Various licenses" or "Assorted licenses" would. Listing them all in the License field is only step 1. Step 2 is being able to determine what, in that package, actually has what license, and having the packager do this makes step 2 a lot simpler. Utopia: RPM could support License(STRING), then we could have multiple license tags for packages. But as said many times before, we work with what we have, and if better things come along in RPM, we move to them. ~spot From notting at redhat.com Fri Jul 27 01:42:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 21:42:54 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727014254.GA6253@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > 73 packages that I have installed have some sort of multiple licensing. > > 73 out of how many? How many of those packages could be reworked to use > subpackages instead? Out of 1279, which extrapolates to ~450 over the whole repository. Are you seriously suggesting we start splitting 400+ packages differently than they are now? The goal is to get something *simple*. Bill From a.badger at gmail.com Fri Jul 27 01:46:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 18:46:00 -0700 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185494928.2409.1.camel@cutter> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> <1185492358.3616.3.camel@localhost.localdomain> <1185493637.19639.82.camel@localhost.localdomain> <1185494928.2409.1.camel@cutter> Message-ID: <1185500763.19639.110.camel@localhost.localdomain> On Thu, 2007-07-26 at 20:08 -0400, seth vidal wrote: > On Thu, 2007-07-26 at 16:47 -0700, Toshio Kuratomi wrote: > > On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote: > > > And what is the purpose of commenting licenses in the file list, apart > > > from making the packagers life miserable ? > > > > I agree. Or at least, I disagree with the example and scope in the > > Draft. I don't think we care what the license of an individual built > > program is. We might care what the license of a built library is. > > > > Whether it's better to mark libraries with a spec comment or make it > > mandatory to split libraries that are licensed differently from other > > code, I don't know, though. > > > > How would we know if there is a problem if program X links to lib Y if > we don't have the licenses of both available. You don't need the licenses to the same granularity to determine the degree to which relicensing will cause problems:: Program changes license. 1) Use ldd to find which libraries we link to. 2) Use repoquery to find out which libraries have incompatible licenses.[1]_ 3) Look at the library spec file to determine which library is incompatible and whether the program even uses the particular library that has the issue. 4) Package maintainers figure out whether we can do anything to save the situation or have to discard one of the packages. Library changes license. 1) Use repoquery to find out which programs link. 2) Use repoquery on the programs to find out which programs have incompatible licenses.[1]_ 3) Package maintainers figure out whether we can do anything to save the situation or have to throw out one or the other package. Figuring out which program in a package has an incompatible license doesn't add value for the library maintainer as they have to involve the program maintainer in order to fix the situation no matter what. On the contrary figuring out which library has a license issue could allow the program maintainer to determine that they can fix the issue without involving the other maintainer. [1]_: Looks like repoquery needs to be enhanced to show the license tag. -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 notting at redhat.com Fri Jul 27 01:50:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 21:50:37 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185500763.19639.110.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> <1185492358.3616.3.camel@localhost.localdomain> <1185493637.19639.82.camel@localhost.localdomain> <1185494928.2409.1.camel@cutter> <1185500763.19639.110.camel@localhost.localdomain> Message-ID: <20070727015037.GB6253@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > [1]_: Looks like repoquery needs to be enhanced to show the license tag. --queryformat '%{LICENSE}' Bill From smooge at gmail.com Fri Jul 27 02:01:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Jul 2007 20:01:39 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261617qc7a83edwd8f1c7d3a21d944d@mail.gmail.com> <20070726191904.4a826f4a@ender> <1185495793.3765.14.camel@dhcp83-168.boston.redhat.com> Message-ID: <80d7e4090707261901q19413f07ke30f59d48c69baa5@mail.gmail.com> On 7/26/07, Tom spot Callaway wrote: > > On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote: > > On Thu, 26 Jul 2007 17:17:30 -0600 > > "Stephen John Smoogen" wrote: > > > > > I find the reading of && || to be a little hard. Wouldnt it be better > > > to use the or as in the Perl license way? or was there a legal reason > > > for not to.. beyond that I think the two are good.Parenthesis I do not > > > have a problem with. > > > > Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and > > 'and' perhaps? Just guessing. > > This is precisely why. > Ahh I figured that and/or could be done by computer while humans have to read the text. I can see the weird questions that will come up over time. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Fri Jul 27 02:07:00 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Jul 2007 20:07:00 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> Message-ID: <80d7e4090707261907k21cba1f6x37e0a7eebf5d0f5@mail.gmail.com> On 7/26/07, Tom spot Callaway wrote: > > On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote: > > Tom spot Callaway (tcallawa at redhat.com) said: > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > > is waiting for us to do it), and I think this is the cleanest way: > > > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > > and http://fedoraproject.org/wiki/Licensing . > > > > For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) > > and 'GPLv2+' (GPL version 2 or later). > > > > I think the tagging per file in comments is definitely overkill. > > Most packages won't need it, and for those that do, it will make the > task for whomever is auditing the package (re: me) much simpler. > Hmmm would it be simpler to just have an included PACKAGE-LICENSES file that you would then audit? That would keep the SPEC file from getting overly ugly in some cases, and make your job a lot simpler by giving out a tool that they could check to see if something matches/doesnt match the PACKAGE-LICENSES. We could then share that with our friends at Debian etc unless they have such a tool that we could use. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Fri Jul 27 02:08:09 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Jul 2007 20:08:09 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707261907k21cba1f6x37e0a7eebf5d0f5@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261907k21cba1f6x37e0a7eebf5d0f5@mail.gmail.com> Message-ID: <80d7e4090707261908l8b8560bwc36576db4c173419@mail.gmail.com> On 7/26/07, Stephen John Smoogen wrote: > On 7/26/07, Tom spot Callaway wrote: > > > > On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote: > > > Tom spot Callaway (tcallawa at redhat.com) said: > > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > > > is waiting for us to do it), and I think this is the cleanest way: > > > > > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > > > and http://fedoraproject.org/wiki/Licensing . > > > > > > For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) > > > and 'GPLv2+' (GPL version 2 or later). > > > > > > I think the tagging per file in comments is definitely overkill. > > > > Most packages won't need it, and for those that do, it will make the > > task for whomever is auditing the package (re: me) much simpler. > > > > Hmmm would it be simpler to just have an included PACKAGE-LICENSES > file that you would then audit? That would keep the SPEC file from > getting overly ugly in some cases, and make your job a lot simpler by > giving out a tool that they could check to see if something > matches/doesnt match the PACKAGE-LICENSES. We could then share that > with our friends at Debian etc unless they have such a tool that we > could use. PS. Not trying to be a pain in the ass to the guy who took over something I half assed did back in FC2 or so.. who just drove across the country, and hasnt found where they serve grits in Boston (so he can either have or avoid). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rc040203 at freenet.de Fri Jul 27 03:51:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 05:51:13 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185508274.20980.280.camel@mccallum.corsepiu.local> On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . > > We'll vote on it next week. -1 As I understand it, you are trying mandate versioned license tags. Such an approach is inapplicable without a "license tags" register being actively maintained by an "licence tag administration office". In other words, to me your proposal is equivalent to mandating cars carring license tags but allowing car owner to "paint them themselves". This can't work. Ralf From rc040203 at freenet.de Fri Jul 27 04:10:02 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 06:10:02 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727005006.GB4227@nostromo.devel.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> Message-ID: <1185509402.20980.296.camel@mccallum.corsepiu.local> On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > > I think the tagging per file in comments is definitely overkill. > > > > Most packages won't need it, and for those that do, it will make the > > task for whomever is auditing the package (re: me) much simpler. > > 73 packages that I have installed have some sort of multiple licensing. ?? 90% of all perl packages are multiple licensed. These alone make several 100s of packages. Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL. Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses Ralf From tcallawa at redhat.com Fri Jul 27 05:28:30 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 00:28:30 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185491902.19639.70.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185491902.19639.70.camel@localhost.localdomain> Message-ID: <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 16:18 -0700, Toshio Kuratomi wrote: > On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > > OK, I know this is going to be painful, but we need to solve this (FESCo > > is waiting for us to do it), and I think this is the cleanest way: > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > and http://fedoraproject.org/wiki/Licensing . > > > > We'll vote on it next week. > > > I think that's missing a scenario. > > Covered: > You can have License A or License B (Dual license) > > You can have License A on /usr/bin/foo and License B on /usr/bin/bar > (Multiple Licensing) > > Not Covered: > You can have License A on foo.c and License B on bar.c being linked > together to form /usr/bin/foobar (A different kind of multiple > licensing) Wouldn't that effectively be a dual license on /usr/bin/foobar? Except, it would be a dual AND instead of a dual OR. How about we call that "Mixed Source Licensing": === Mixed Source Licensing Scenario === In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses. For example, it is possible that a binary is generated from a source file licensed as BSD with advertising, and another source file licensed as QPL (which specifies that modifications must be shipped as patches). In this scenario, we'd mark the license as (BSD with advertising && QPL). ~spot From tcallawa at redhat.com Fri Jul 27 05:29:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 00:29:59 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185509402.20980.296.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> Message-ID: <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 06:10 +0200, Ralf Corsepius wrote: > On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote: > > Tom spot Callaway (tcallawa at redhat.com) said: > > > > I think the tagging per file in comments is definitely overkill. > > > > > > Most packages won't need it, and for those that do, it will make the > > > task for whomever is auditing the package (re: me) much simpler. > > > > 73 packages that I have installed have some sort of multiple licensing. > > ?? 90% of all perl packages are multiple licensed. > These alone make several 100s of packages. 90% of perl packages are _dual_ licensed, and thus, wouldn't need to do this. > Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL. > > Also I am still missing a detailed list of all tags you want to force us > to use for BSD*ish, X11*ish and other licenses These aren't licenses. Either it is BSD or X11 or it is something else. ~spot From tcallawa at redhat.com Fri Jul 27 05:34:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 00:34:56 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185508274.20980.280.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> Message-ID: <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote: > On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > > OK, I know this is going to be painful, but we need to solve this (FESCo > > is waiting for us to do it), and I think this is the cleanest way: > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > and http://fedoraproject.org/wiki/Licensing . > > > > We'll vote on it next week. > > -1 > > As I understand it, you are trying mandate versioned license tags. > Such an approach is inapplicable without a "license tags" register being > actively maintained by an "licence tag administration office". > > In other words, to me your proposal is equivalent to mandating cars > carring license tags but allowing car owner to "paint them themselves". Ralf, there really isn't any other way to solve the problem without having a list of standard license identifiers. The http://fedoraproject.org/wiki/Licensing page is the license registry. I'm volunteering to lead the effort to maintain it, since I've effectively been doing that for more than a year now. I'm more than willing to take on additional helpers to maintain this license registry. I'm very willing to alter the license identifiers to make they more simplistic, but without that baseline standard, it won't be possible to predictably track license data from packages. ~spot From tcallawa at redhat.com Fri Jul 27 05:41:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 00:41:25 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707261907k21cba1f6x37e0a7eebf5d0f5@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <80d7e4090707261907k21cba1f6x37e0a7eebf5d0f5@mail.gmail.com> Message-ID: <1185514885.3765.69.camel@dhcp83-168.boston.redhat.com> On Thu, 2007-07-26 at 20:07 -0600, Stephen John Smoogen wrote: > On 7/26/07, Tom spot Callaway wrote: > > > > On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote: > > > Tom spot Callaway (tcallawa at redhat.com) said: > > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > > > is waiting for us to do it), and I think this is the cleanest way: > > > > > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > > > and http://fedoraproject.org/wiki/Licensing . > > > > > > For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) > > > and 'GPLv2+' (GPL version 2 or later). > > > > > > I think the tagging per file in comments is definitely overkill. > > > > Most packages won't need it, and for those that do, it will make the > > task for whomever is auditing the package (re: me) much simpler. > > > > Hmmm would it be simpler to just have an included PACKAGE-LICENSES > file that you would then audit? That would keep the SPEC file from > getting overly ugly in some cases, and make your job a lot simpler by > giving out a tool that they could check to see if something > matches/doesnt match the PACKAGE-LICENSES. We could then share that > with our friends at Debian etc unless they have such a tool that we > could use. I'm not opposed to that at all. Again, just to reiterate: If the package is dual licensed for all of its bits (e.g. perl-foo, License: GPL or Artistic), you wouldn't need to do this. You'd only need to do this if you had a package with a lot of files with differing licenses. ~spot From rc040203 at freenet.de Fri Jul 27 04:50:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 06:50:58 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185511858.20980.302.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 00:29 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-07-27 at 06:10 +0200, Ralf Corsepius wrote: > > On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote: > > > Tom spot Callaway (tcallawa at redhat.com) said: > > > > > I think the tagging per file in comments is definitely overkill. > > > > > > > > Most packages won't need it, and for those that do, it will make the > > > > task for whomever is auditing the package (re: me) much simpler. > > > > > > 73 packages that I have installed have some sort of multiple licensing. > > > > ?? 90% of all perl packages are multiple licensed. > > These alone make several 100s of packages. > > 90% of perl packages are _dual_ licensed, Yes, GPL or Artistic. > and thus, wouldn't need to do > this. I don't see this. > > Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL. > > > > Also I am still missing a detailed list of all tags you want to force us > > to use for BSD*ish, X11*ish and other licenses > > These aren't licenses. Either it is BSD or X11 or it is something else. BS. Of cause they are licenses. A RH owned BSD'ish license is something completely different as a UCB owned BSD'ish license. They probably are compatible but that's all. Different copyright owners, different licensors => different licenses. This hits esp. when licensors change their licenses, as it had been several times been the case in case of the X11 licenses. Ralf From rc040203 at freenet.de Fri Jul 27 04:58:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 06:58:23 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185512303.20980.311.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 00:34 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote: > > On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > > is waiting for us to do it), and I think this is the cleanest way: > > > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > > and http://fedoraproject.org/wiki/Licensing . > > > > > > We'll vote on it next week. > > > > -1 > > > > As I understand it, you are trying mandate versioned license tags. > > Such an approach is inapplicable without a "license tags" register being > > actively maintained by an "licence tag administration office". > > > > In other words, to me your proposal is equivalent to mandating cars > > carring license tags but allowing car owner to "paint them themselves". > > Ralf, there really isn't any other way to solve the problem without > having a list of standard license identifiers. Then think your thought to an end and implement the required administration bureau first. Right now, you are stopping half-ways, and therefore fail to see the bureaucracy you are trying to push onto fedora contributors. RH is going to force Fedora into a more bureaucratic than Debian has ever been. > The http://fedoraproject.org/wiki/Licensing page is the license > registry. I'm volunteering to lead the effort to maintain it, since I've > effectively been doing that for more than a year now. ROTFL - You can't be serious to call this an infrastructure. > I'm more than willing to take on additional helpers to maintain this > license registry. I'm very willing to alter the license identifiers to > make they more simplistic, but without that baseline standard, it won't > be possible to predictably track license data from packages. Whatfor? Somebody from the "dark circles" at RH ordered you to do so and because of the GPLv3 had been introduced. I call this overreaction and hysteria ... Ralf From a.badger at gmail.com Fri Jul 27 05:05:29 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 22:05:29 -0700 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <20070727001600.GE9468@puariko.nirvana> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> <1185492843.19639.75.camel@localhost.localdomain> <20070727001600.GE9468@puariko.nirvana> Message-ID: <1185512732.19639.123.camel@localhost.localdomain> On Fri, 2007-07-27 at 02:16 +0200, Axel Thimm wrote: > On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote: > > (And I nominate "+=" as the most logical and ugliest operator for the > > job :-) > > > A comparison operator (>=) would make more sense Your nomination is definitely more logical, but no less ugly :-( License: GPLv2 >= || MPLv1.1 We could break the version apart from the license tag. I don't know if that makes it harder for spot's use case or not:: License: GPL >= v2 || MPL == v1.1 -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 tcallawa at redhat.com Fri Jul 27 06:21:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 01:21:10 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185511858.20980.302.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> Message-ID: <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> > I don't see this. Perhaps I've not been clear on when you would need to generate a license/file list. When a package has a consistent license (or dual/triple license) for all of its files (not including docs or content), it does not need to have a license file list. It is only when the package has multiple files with differing licenses that this is useful, and thus, required. > > > Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL. > > > > > > Also I am still missing a detailed list of all tags you want to force us > > > to use for BSD*ish, X11*ish and other licenses > > > > These aren't licenses. Either it is BSD or X11 or it is something else. > BS. Of cause they are licenses. OK, let me rephrase. Yes, these items are licenses, but "BSD-ish" is not a license. Merely changing the copyright holder in the BSD license text does _not_ make the license not BSD. It is only when the terms of the license are altered by the copyright holder that the license stops being BSD. At that point, the license isn't BSD, it is something new. Depending on what those changes are, the new license is either ok for Fedora or it is not. When this new license gets submitted for approval, it will be added to the Licensing table, and given a new short name, with a link to the Licensing text. "BSD-ish" is as useless as "Distributable", in that it tells us nothing about the potential license compatibility. Two packages with "BSD-ish" as a license could be identical or wholly incompatible, and this is precisely the problem that we're trying to avoid. ~spot From tcallawa at redhat.com Fri Jul 27 06:24:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 01:24:46 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185512303.20980.311.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> <1185512303.20980.311.camel@mccallum.corsepiu.local> Message-ID: <1185517486.3765.81.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 06:58 +0200, Ralf Corsepius wrote: > Whatfor? Somebody from the "dark circles" at RH ordered you to do so > and > because of the GPLv3 had been introduced. I call this overreaction and > hysteria ... Repeat after me. There is no conspiracy. No one ordered me to do this. I volunteered. The immediate motivation was concern over GPLv3 and LGPLv3 compatibility, as packagers were innocently violating licensing due to a lack of awareness, and there was no mechanism in place to automate basic package license checking due to a lack of standardization. However, as Smooge pointed out, this is something that a lot of people have known needed to be done since FC2 (and likely, before). And yes, the Licensing wiki is not the utopian mechanism for this. Having this data in the PackageDB makes a lot more sense to me, but we'll start here and grow. ~spot From a.badger at gmail.com Fri Jul 27 05:33:47 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Jul 2007 22:33:47 -0700 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185491902.19639.70.camel@localhost.localdomain> <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185514435.19639.139.camel@localhost.localdomain> On Fri, 2007-07-27 at 00:28 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-07-26 at 16:18 -0700, Toshio Kuratomi wrote: > > On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > > is waiting for us to do it), and I think this is the cleanest way: > > > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > > and http://fedoraproject.org/wiki/Licensing . > > > > > > We'll vote on it next week. > > > > > I think that's missing a scenario. > > > > Covered: > > You can have License A or License B (Dual license) > > > > You can have License A on /usr/bin/foo and License B on /usr/bin/bar > > (Multiple Licensing) > > > > Not Covered: > > You can have License A on foo.c and License B on bar.c being linked > > together to form /usr/bin/foobar (A different kind of multiple > > licensing) > > Wouldn't that effectively be a dual license on /usr/bin/foobar? Except, > it would be a dual AND instead of a dual OR. > Yes. > How about we call that "Mixed Source Licensing": > > === Mixed Source Licensing Scenario === > In some cases, it is possible for a binary to be generated from multiple > source files with compatible, but differing licenses. > For example, it is possible that a binary is generated from a source file > licensed as BSD with advertising, and another source file licensed as QPL > (which specifies that modifications must be shipped as patches). In this > scenario, we'd mark the license as (BSD with advertising && QPL). > This mixes the operator for multiple licensing with mixed source licensing, though. Since I agree that this is another type of dual license, how about making parens [()] mandatory for dual licensing whether or not there are other licenses involved? Then we have: Separate built files are under separate licenses QPL && BSD Single built file is under one of multiple licenses (QPL || BSD) Single built file is under more than one license (QPL && BSD) Versions, as amended by notting: Specific version: v# Specific version or later: v#+ So, AIUI, Firefox would be under: License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+) -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 rc040203 at freenet.de Fri Jul 27 06:12:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 08:12:18 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185516739.20980.338.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 01:21 -0500, Tom "spot" Callaway wrote: > > > I don't see this. > > Perhaps I've not been clear on when you would need to generate a > license/file list. > > When a package has a consistent license (or dual/triple license) for all > of its files (not including docs or content), it does not need to have a > license file list. The problem with dual licensed packages is: "Which license applies in a particular situation" - Your approach doesn't cope with this case. > It is only when the package has multiple files with differing licenses > that this is useful, and thus, required. OK, but the later is the common case on most "non-trivial" packages, which often apply the GPL as "umbrella". Also, these latter packages, are those who often come along with diverging "run-time" licenses (in most cases the "umbrella" rules) and "source-code" licenses (often different licenses on different files). Your approach is not considering the latter case. > > > > Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL. > > > > > > > > Also I am still missing a detailed list of all tags you want to force us > > > > to use for BSD*ish, X11*ish and other licenses > > > > > > These aren't licenses. Either it is BSD or X11 or it is something else. > > BS. Of cause they are licenses. > > OK, let me rephrase. Yes, these items are licenses, but "BSD-ish" is not > a license. Right, you would have to cite the complete license with its exact wording being applied. > Merely changing the copyright holder in the BSD license text > does _not_ make the license not BSD. That's true, but if you don't track copyright holders, your automatic tracking system is more or less worthless. * Consider X10/X11's history: The code base still originates back to the X10/Athena/MIT days, but the code's owners have changed several times, the code had been forked many times. If you had tried to track this as "X11" your automated tracking would not have caught the potential license incompatibilities being introduced to other packages relying on X11 being "X11/MIT/Athena"-license (You might recall these incompatibilities having been the cause for X11 to fork several times.) * Consider the original UCB license: UCB has declared _their_ "ad-clause" invalid. So if you had tracked their packages as "BSD", you would not have caught any of the packages having been affect by their change in policy. > It is only when the terms of the > license are altered by the copyright holder that the license stops being > BSD. At that point, the license isn't BSD, it is something new. Yes, it's yet another variant ... one amongst 100s if not 1000s existing around. > Depending on what those changes are, the new license is either ok for > Fedora or it is not. When this new license gets submitted for approval, > it will be added to the Licensing table, and given a new short name, > with a link to the Licensing text. > > "BSD-ish" is as useless as "Distributable", in that it tells us nothing > about the potential license compatibility. Two packages with "BSD-ish" > as a license could be identical or wholly incompatible, and this is > precisely the problem that we're trying to avoid. Exactly: The Fedora License Register would have to track each of these licenses with their copyright holders individually. The point why I am laughing at you and your wiki. Ralf From rc040203 at freenet.de Fri Jul 27 06:24:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Jul 2007 08:24:52 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185517486.3765.81.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> <1185512303.20980.311.camel@mccallum.corsepiu.local> <1185517486.3765.81.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185517493.20980.350.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 01:24 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-07-27 at 06:58 +0200, Ralf Corsepius wrote: > > Whatfor? Somebody from the "dark circles" at RH ordered you to do so > > and > > because of the GPLv3 had been introduced. I call this overreaction and > > hysteria ... > > Repeat after me. There is no conspiracy. No one ordered me to do this. I > volunteered. OK, then this plan all grow on your own soil? Then this isn't much more but a: "I, Spot, want my pony"? > The immediate motivation was concern over GPLv3 and LGPLv3 > compatibility, as packagers were innocently violating licensing due to a > lack of awareness, and there was no mechanism in place to automate basic > package license checking due to a lack of standardization. > > However, as Smooge pointed out, this is something that a lot of people > have known needed to be done since FC2 (and likely, before). Well, this isn't the first time this issue pops up. We even discussed and rejected a similar proposal on FPC before. Just reiterating and re-proposing something doesn't make a plan/proposal more useful. > And yes, the Licensing wiki is not the utopian mechanism for this. > Having this data in the PackageDB makes a lot more sense to me, but > we'll start here and grow. "We'll start here and grow" .. do you sense what you are saying here? You are saying: "I, Spot, have decided and am dictating the community what to do" 8() Ralf From pmatilai at laiskiainen.org Fri Jul 27 07:26:49 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 27 Jul 2007 10:26:49 +0300 (EEST) Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> Message-ID: On Fri, 27 Jul 2007, Tom \spot\ Callaway wrote: > > On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote: >> On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: >>> OK, I know this is going to be painful, but we need to solve this (FESCo >>> is waiting for us to do it), and I think this is the cleanest way: >>> >>> Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag >>> and http://fedoraproject.org/wiki/Licensing . >>> >>> We'll vote on it next week. >> >> -1 >> >> As I understand it, you are trying mandate versioned license tags. >> Such an approach is inapplicable without a "license tags" register being >> actively maintained by an "licence tag administration office". >> >> In other words, to me your proposal is equivalent to mandating cars >> carring license tags but allowing car owner to "paint them themselves". > > Ralf, there really isn't any other way to solve the problem without > having a list of standard license identifiers. > > The http://fedoraproject.org/wiki/Licensing page is the license > registry. I'm volunteering to lead the effort to maintain it, since I've > effectively been doing that for more than a year now. > > I'm more than willing to take on additional helpers to maintain this > license registry. I'm very willing to alter the license identifiers to > make they more simplistic, but without that baseline standard, it won't > be possible to predictably track license data from packages. Make the wiki-list a real license compatibility matrix, stored in a machine parsable format. Put the matrix into (fedora-)license-matrix (or such) package that contains the actual copy of known license text and require that anything claiming to be of license foo has a license file matching the checksum of the license-matrix copy of that license. Enforce this at build time so that no package with unknown (or incompatible) license can enter the repository. It'd probably need some additional help from rpm to map the license tag and actual file (while it's often "COPYING" it also often is not, not to mention various homegrown licenses). Something like License(): Back to scheduled morning coffee break... - Panu - From nicolas.mailhot at laposte.net Fri Jul 27 07:47:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Jul 2007 09:47:52 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185514435.19639.139.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185491902.19639.70.camel@localhost.localdomain> <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> <1185514435.19639.139.camel@localhost.localdomain> Message-ID: <1185522472.31046.11.camel@rousalka.dyndns.org> Le jeudi 26 juillet 2007 ? 22:33 -0700, Toshio Kuratomi a ?crit : > So, AIUI, Firefox would be under: > License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+) This kind of notation is pretty useless. in theory many packages are dual or tri-licensed. In reality the multi-licensing if often collapsed due to deps (upstream or downstream) that impose one particular license. If we go the "or" route no one will check, and everyone will assume the most permissive license applies (even if it's not the case due to the packages fedora builds again) IMHO in the case of multi-licensing we should choose one of the possible licenses and stick with it. Only revisit the choice if another fedora package forces us to, and let the packager of this other package do the licensing analysis. This is different from the case where different bits of a component are under different licences. There we have no choice but carefully track licensing boundaries? -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 27 09:00:39 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Jul 2007 11:00:39 +0200 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727110039.46506188@python3.es.egwn.lan> Tom "spot" Callaway wrote : > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . That was an interesting read. Thanks for your hard work, spot! A few comments, FWIW : - Same as Bill, I prefer the "GPLv2+" style notations. - To keep using "GPL or Artistic" for perl doesn't make much sense to me, since we are trying to differentiate clearly the different GPL versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"? - If we use only " and " and " or " (with spaces around them), wouldn't the field still be reliably parseable, yet easier to read? And more coherent with the "GPL* or Artistic" from the perl packages? - I find having to detail the licenses in %files quite unpractical, and possibly not the best suited for most cases, as I have the feeling that the most common case of multiple-licensing I've come across is having parts of the source code under a different compatible license, but then having all libs/programs use it. So I think having comments inside the spec file right above the License: tag might be more useful, something like : # The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.56 0.50 0.45 From tcallawa at redhat.com Fri Jul 27 13:05:45 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 08:05:45 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727110039.46506188@python3.es.egwn.lan> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> Message-ID: <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 11:00 +0200, Matthias Saou wrote: > Tom "spot" Callaway wrote : > > > OK, I know this is going to be painful, but we need to solve this (FESCo > > is waiting for us to do it), and I think this is the cleanest way: > > > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > and http://fedoraproject.org/wiki/Licensing . > > That was an interesting read. Thanks for your hard work, spot! > > A few comments, FWIW : > > - Same as Bill, I prefer the "GPLv2+" style notations. Yeah, this makes sense to me, I'm going to change it when I get to work today. > - To keep using "GPL or Artistic" for perl doesn't make much sense to > me, since we are trying to differentiate clearly the different GPL > versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"? This is a valid point, but I can already hear the perl packagers screaming again. :) > - If we use only " and " and " or " (with spaces around them), wouldn't > the field still be reliably parseable, yet easier to read? And more > coherent with the "GPL* or Artistic" from the perl packages? My concern about having scripts that try to parse "and" or "or" as a separator is that we have to be especially careful about license short identifiers. No "Random", "Korn", "Floor", (or to give an actual relevant example, "Condor", which is currently in the list). Using && and || prevents us from having parsing mistakes. I suppose we could parse on _and/_or...but even then, a hypothetical "Andover" license would throw us off. It's still doable, we'd just have to be very careful how it is implemented. We'd also still need some way to handle nasty case like multiple licenses where at least one of the licenses was a dual license. Assuming parenthesis are used, it would look like this: License: "Foo and Bar and (Cat or Dog)" > - I find having to detail the licenses in %files quite unpractical, and > possibly not the best suited for most cases, as I have the feeling that > the most common case of multiple-licensing I've come across is having > parts of the source code under a different compatible license, but then > having all libs/programs use it. So I think having comments inside the > spec file right above the License: tag might be more useful, something > like : > > # The entire source code is GPLv2+ except foolib/ which is BSD > License: GPLv2+ and BSD It seems fine to me. I think I'm going to redraft the wording for that section to simply say that "the package must contain a comment explaining the multiple licensing breakdown", and leave the actual implementation to the packager. This way, one could do as you've suggested, or as I originally drafted, or even say # For a breakdown of the licensing, see PACKAGE-LICENSING Thanks for the help! ~spot From tcallawa at redhat.com Fri Jul 27 13:18:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 08:18:17 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185522472.31046.11.camel@rousalka.dyndns.org> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185491902.19639.70.camel@localhost.localdomain> <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> <1185514435.19639.139.camel@localhost.localdomain> <1185522472.31046.11.camel@rousalka.dyndns.org> Message-ID: <1185542297.3765.106.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 09:47 +0200, Nicolas Mailhot wrote: > Le jeudi 26 juillet 2007 ? 22:33 -0700, Toshio Kuratomi a ?crit : > > > So, AIUI, Firefox would be under: > > License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+) > > This kind of notation is pretty useless. in theory many packages are > dual or tri-licensed. In reality the multi-licensing if often collapsed > due to deps (upstream or downstream) that impose one particular license. > If we go the "or" route no one will check, and everyone will assume the > most permissive license applies (even if it's not the case due to the > packages fedora builds again) > > IMHO in the case of multi-licensing we should choose one of the possible > licenses and stick with it. Only revisit the choice if another fedora > package forces us to, and let the packager of this other package do the > licensing analysis. I think the problem is that when Firefox is under GPLv2+, LGPLv2.1+ and MPLv1.1+, differing Fedora packages that want to link to it will each choose the appropriate license that matches it, for linking purposes. So, we really can't just pick a license and stick with it, because that's just not correct. I'm also not sure I want the packager to bear the burden, and I suspect the various upstreams would get rather angry over our attempts to "simplify" their licensing. :) We've had a sort of "or" route for a while now (Foo/Bar/Baz), but the problem is that we've also had packagers using that as an "and" where it applies. Also, I've found that most packagers either don't want to, or aren't qualified to do licensing analysis. I'm getting better at it through practice, but I'm certainly not perfect either (which is why I defer to the thoughts of more skilled folks, either at Red Hat or the FSF, when I have any doubt). > This is different from the case where different bits of a component > are under different licences. There we have no choice but carefully > track licensing boundaries? Well, I wouldn't say we have no choice, since we've not been doing this in Fedora so far, but it certainly seems to be a logical continuation (at least to me). Having a list of all the licenses that all the files in a package uses is useful, but when one of those files has a license related conflict (I linked against foo in package bar, was it GPLv3 or not?), it would be very helpful to have a quick way to check at a glance, without exploding a source tree. ~spot From jkeating at redhat.com Fri Jul 27 12:54:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:54:03 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185522472.31046.11.camel@rousalka.dyndns.org> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185491902.19639.70.camel@localhost.localdomain> <1185514110.3765.53.camel@dhcp83-168.boston.redhat.com> <1185514435.19639.139.camel@localhost.localdomain> <1185522472.31046.11.camel@rousalka.dyndns.org> Message-ID: <20070727085403.3ec8bd88@ender> On Fri, 27 Jul 2007 09:47:52 +0200 Nicolas Mailhot wrote: > IMHO in the case of multi-licensing we should choose one of the > possible licenses and stick with it. Only revisit the choice if > another fedora package forces us to, and let the packager of this > other package do the licensing analysis. We can't just do that, as we also provide them the srpm/source which is not yet linked to anything, and thus is not limited to which license the end user chooses to receive/use the source under. WHEEEEEEE! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 27 12:57:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:57:28 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185516739.20980.338.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> Message-ID: <20070727085728.31cacf23@ender> On Fri, 27 Jul 2007 08:12:18 +0200 Ralf Corsepius wrote: > Exactly: The Fedora License Register would have to track each of these > licenses with their copyright holders individually. The point why I am > laughing at you and your wiki. Ignoring (or laughing at) the problem does not make it go away. So instead of just telling us how all our ideas suck and we're all dumb and unworthy of working on Fedora, why don't you offer some constructive feedback and help us solve the problem? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 27 13:02:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 09:02:46 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185517493.20980.350.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> <1185512303.20980.311.camel@mccallum.corsepiu.local> <1185517486.3765.81.camel@dhcp83-168.boston.redhat.com> <1185517493.20980.350.camel@mccallum.corsepiu.local> Message-ID: <20070727090246.1cc40233@ender> On Fri, 27 Jul 2007 08:24:52 +0200 Ralf Corsepius wrote: > OK, then this plan all grow on your own soil? > > Then this isn't much more but a: "I, Spot, want my pony"? > > > The immediate motivation was concern over GPLv3 and LGPLv3 > > compatibility, as packagers were innocently violating licensing due > > to a lack of awareness, and there was no mechanism in place to > > automate basic package license checking due to a lack of > > standardization. > > > > However, as Smooge pointed out, this is something that a lot of > > people have known needed to be done since FC2 (and likely, > > before). > Well, this isn't the first time this issue pops up. We even discussed > and rejected a similar proposal on FPC before. Just reiterating and > re-proposing something doesn't make a plan/proposal more useful. Please lower your tinfoil hat a bit so you can hear this. The duly elected Fedora Board has decided that due to things like (l)gplv3 it is now painfully apparent that we need a better method of tracking what licenses our various packages are under, and has asked FESCo to make it happen. FESCo has deemed this a Packaging issue and given FPC the mandate to make proposals for how to accomplish this. Spot has volunteered as part of the FPC to create such a proposal for how to handle this for FPC/FESCo/Board approval, and that's where we are. If Spot didn't volunteer, who would? Would you then claim that whomever created the draft is now trying to be dictator? If the idea doesn't come from you does it automatically mean it's coming from a shadowy smoke filled room somewhere within the bowels of Red Hat? Yes, the FPC rejected one proposal. That was before the Fedora Board voted and deemed it necessary to track this, and that's why we're talking about it again. We don't have the authority to veto the Board in their mandate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Jul 27 13:08:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Jul 2007 08:08:21 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <20070727085728.31cacf23@ender> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> Message-ID: <46A9EE45.20708@math.unl.edu> Jesse Keating wrote: > On Fri, 27 Jul 2007 08:12:18 +0200 > Ralf Corsepius wrote: > >> Exactly: The Fedora License Register would have to track each of these >> licenses with their copyright holders individually. The point why I am >> laughing at you and your wiki. > > Ignoring (or laughing at) the problem does not make it go away. So > instead of just telling us how all our ideas suck and we're all dumb > and unworthy of working on Fedora, why don't you offer some > constructive feedback and help us solve the problem? Seems to me, that at least in part, Ralf disagrees with the assertion that a problem exists that is worth all this pain of solving. -- Rex From mclasen at redhat.com Fri Jul 27 13:22:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 09:22:38 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185542558.3650.9.camel@localhost.localdomain> On Fri, 2007-07-27 at 08:05 -0500, Tom "spot" Callaway wrote: > > - To keep using "GPL or Artistic" for perl doesn't make much sense to > > me, since we are trying to differentiate clearly the different GPL > > versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"? > > This is a valid point, but I can already hear the perl packagers > screaming again. :) > > > - If we use only " and " and " or " (with spaces around them), wouldn't > > the field still be reliably parseable, yet easier to read? And more > > coherent with the "GPL* or Artistic" from the perl packages? > > My concern about having scripts that try to parse "and" or "or" as a > separator is that we have to be especially careful about license short > identifiers. No "Random", "Korn", "Floor", (or to give an actual > relevant example, "Condor", which is currently in the list). Using && > and || prevents us from having parsing mistakes. I suppose we could > parse on _and/_or...but even then, a hypothetical "Andover" license > would throw us off. It's still doable, we'd just have to be very careful > how it is implemented. > Oh, come on, \band\b is not that hard. Using some awkward notation is making the life of every packager harder, for the benefit of the one person who implements the parser. From notting at redhat.com Fri Jul 27 13:43:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 09:43:19 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727134319.GG25862@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > - Same as Bill, I prefer the "GPLv2+" style notations. > > Yeah, this makes sense to me, I'm going to change it when I get to work > today. One more change to the license table - a GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include. So that would be GPL+, or GPLv1+. > > # The entire source code is GPLv2+ except foolib/ which is BSD > > License: GPLv2+ and BSD > > It seems fine to me. I think I'm going to redraft the wording for that > section to simply say that "the package must contain a comment > explaining the multiple licensing breakdown", and leave the actual > implementation to the packager. This way, one could do as you've > suggested, or as I originally drafted, or even say > > # For a breakdown of the licensing, see PACKAGE-LICENSING Sounds reasonable. Thanks for your work on this! Bill From jkeating at redhat.com Fri Jul 27 14:14:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 10:14:48 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <46A9EE45.20708@math.unl.edu> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727003143.GA4227@nostromo.devel.redhat.com> <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> <46A9EE45.20708@math.unl.edu> Message-ID: <20070727101448.0ac921cf@localhost.localdomain> On Fri, 27 Jul 2007 08:08:21 -0500 Rex Dieter wrote: > Seems to me, that at least in part, Ralf disagrees with the assertion > that a problem exists that is worth all this pain of solving. You mean the problem of mixing thousands of packages together of varying licenses which may or may not be incompatible? I don't see how you can possibly think this problem doesn't exist. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jul 27 14:39:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Jul 2007 16:39:13 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185512732.19639.123.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <200707270113.52971.opensource@till.name> <1185495843.3765.16.camel@dhcp83-168.boston.redhat.com> <1185492843.19639.75.camel@localhost.localdomain> <20070727001600.GE9468@puariko.nirvana> <1185512732.19639.123.camel@localhost.localdomain> Message-ID: <20070727143913.GB10303@puariko.nirvana> On Thu, Jul 26, 2007 at 10:05:29PM -0700, Toshio Kuratomi wrote: > On Fri, 2007-07-27 at 02:16 +0200, Axel Thimm wrote: > > On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote: > > > (And I nominate "+=" as the most logical and ugliest operator for the > > > job :-) > > > > > > A comparison operator (>=) would make more sense > > Your nomination is definitely more logical, but no less ugly :-( > > License: GPLv2 >= || MPLv1.1 I didn't imply postfix notation. > We could break the version apart from the license tag. I don't know if > that makes it harder for spot's use case or not:: > > License: GPL >= v2 || MPL == v1.1 Me thinks that spot and anyone else will be more than capable to parse anything properly, even if it's "or" instead of "||" and ">=" instead of "+=$%&/?" The most important thing is to not disrupt current packaging practices too much. What this means is that if 99% of current "GPL >= v2" packages have "GPL" in their License: tag, then simply define "GPL" to mean that and only fix th remain one percent. Currently it looks like there would be a mass rebuild for License tags only. I'm all for at least one mass rebuild per release, but not for a retagging of Licenses to Polish notation like parsing structures. -- 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 herrold at owlriver.com Fri Jul 27 14:43:05 2007 From: herrold at owlriver.com (R P Herrold) Date: Fri, 27 Jul 2007 10:43:05 -0400 (EDT) Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> References: <1185305674.4709.76.camel@localhost.localdomain> <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> Message-ID: On Thu, 26 Jul 2007, Nicolas Mailhot wrote: > +1 for finding interested contacts in other distros and just submit a > request to the LSB to have the static range expanded Mats Wichmann of the LSB, and I discussed Linux Assigned Names And Numbers Authority matters at OLS a few weeks ago at some length, and the matter was discussed in the LSB weekly conference call on Wednesday with him and me leading the discussion [the calls are open to persons willing to participate and work -- ask off list if Fedora or Red Hat wish details for calling in -- each has been absent from th process for reasons unknown to me in recent years. -- Alan Cox occastionally chimes in on the mailing list, always with insightful comment, however] http://www.lanana.org/ and there is certainly an interest at the LSB in helping reach inter-vendor coordination in this space. Please feel free to CC me on any proposal for extension as it is worked up. -- Russ Herrold herrold at owlriver.com From Axel.Thimm at ATrpms.net Fri Jul 27 14:47:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Jul 2007 16:47:43 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727144743.GC10303@puariko.nirvana> On Thu, Jul 26, 2007 at 06:27:59PM -0500, Tom spot Callaway wrote: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . > > We'll vote on it next week. What I'm missing is the reason this has to change. Obviously someone made lots of noise about it and the current model is inadequate for whomever needs. Before jumping through loops to understand what which lawyer from where wanted to do with this information, maybe it would be helpful to outline the bird's eye sepcification? All I currently see is a mountain of bureaucracy falling on us. Some background information can make us understand the need and perhaps even he?p us make better counter suggestions. -- 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 Jul 27 14:56:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Jul 2007 16:56:13 +0200 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <20070727101448.0ac921cf@localhost.localdomain> References: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> <46A9EE45.20708@math.unl.edu> <20070727101448.0ac921cf@localhost.localdomain> Message-ID: <20070727145613.GD10303@puariko.nirvana> On Fri, Jul 27, 2007 at 10:14:48AM -0400, Jesse Keating wrote: > On Fri, 27 Jul 2007 08:08:21 -0500 > Rex Dieter wrote: > > > Seems to me, that at least in part, Ralf disagrees with the assertion > > that a problem exists that is worth all this pain of solving. I also still try to understand where the need for this change comes from, see my other mail in this thread. > You mean the problem of mixing thousands of packages together of > varying licenses which may or may not be incompatible? I don't see > how you can possibly think this problem doesn't exist. But didn't we had to deal with this problem on a per package basis until now and will have to do so no matter what overly complex parsing system will be installed? Take for example madwifi, a "GPL2v += || BSDwhatever" licensed software that should be compatible according to the parser with the "GPL2v || syscalls exceptions" kernel ... So you'll creating a mesh where elefants can slip through, and at the end we'll only have added bureaucracy for the packagers with no added value whatsoever - packages will have to be checked against their build and runtime depdencies carefully llllike they had to until now. You can't replace a legal review with a parser ... -- 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 Jul 27 15:55:28 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 10:55:28 -0500 Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: References: <1185305674.4709.76.camel@localhost.localdomain> <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> Message-ID: <1185551728.3765.113.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 10:43 -0400, R P Herrold wrote: > On Thu, 26 Jul 2007, Nicolas Mailhot wrote: > > > +1 for finding interested contacts in other distros and just submit a > > request to the LSB to have the static range expanded > > Mats Wichmann of the LSB, and I discussed Linux Assigned Names > And Numbers Authority matters at OLS a few weeks ago at some > length, and the matter was discussed in the LSB weekly > conference call on Wednesday with him and me leading the > discussion [the calls are open to persons willing to > participate and work -- ask off list if Fedora or Red Hat wish > details for calling in -- each has been absent from th process > for reasons unknown to me in recent years. -- Alan Cox > occastionally chimes in on the mailing list, always with > insightful comment, however] > http://www.lanana.org/ > and there is certainly an interest at the LSB in helping reach > inter-vendor coordination in this space. > > Please feel free to CC me on any proposal for extension as it > is worked up. Russ, it seems to me like there is some logic in having a centralized "assignment" for static UID/GIDs, across distributions. Is this something that LANANA would be interested in maintaining? ~spot From tcallawa at redhat.com Fri Jul 27 16:10:15 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 11:10:15 -0500 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <20070727145613.GD10303@puariko.nirvana> References: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> <46A9EE45.20708@math.unl.edu> <20070727101448.0ac921cf@localhost.localdomain> <20070727145613.GD10303@puariko.nirvana> Message-ID: <1185552615.3765.116.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 16:56 +0200, Axel Thimm wrote: > You can't replace a legal review with a parser ... This is not the attempt to replace legal review, it is the attempt to enable a first pass check for obvious package incompatibilities. I'm reworking the draft to try and make it simpler, based on the constructive feedback received. ~spot From opensource at till.name Fri Jul 27 15:38:52 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 17:38:52 +0200 Subject: [Fedora-packaging] Please Update Packaging/RPMMacros to mention lib64 Message-ID: <200707271739.01121.opensource@till.name> Aloas, on http://fedoraproject.org/wiki/Packaging/RPMMacros it is written, that %{_lib} expands to lib but on 64bit architectures it seems to be lib64 instead. The page is locked, so I cannot change it, so would please someone who can do it, add a note about lib64? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Fri Jul 27 16:42:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 11:42:21 -0500 Subject: [Fedora-packaging] Please Update Packaging/RPMMacros to mention lib64 In-Reply-To: <200707271739.01121.opensource@till.name> References: <200707271739.01121.opensource@till.name> Message-ID: <1185554541.3765.122.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 17:38 +0200, Till Maas wrote: > Aloas, > > on http://fedoraproject.org/wiki/Packaging/RPMMacros it is written, > that %{_lib} expands to lib but on 64bit architectures it seems to be lib64 > instead. The page is locked, so I cannot change it, so would please someone > who can do it, add a note about lib64? Added. Thanks, ~spot From opensource at till.name Fri Jul 27 16:00:15 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 18:00:15 +0200 Subject: [Fedora-packaging] Please Update Packaging/RPMMacros to mention lib64 In-Reply-To: <1185554541.3765.122.camel@dhcp83-168.boston.redhat.com> References: <200707271739.01121.opensource@till.name> <1185554541.3765.122.camel@dhcp83-168.boston.redhat.com> Message-ID: <200707271800.28543.opensource@till.name> On Friday 27 July 2007 18:42:21 Tom "spot" Callaway wrote: > Added. Thanks, Thank you, too. But I am afraid you have to edit it again, because you added too much: "bb" See: http://fedoraproject.org/wiki/Packaging/RPMMacros?action=diff&rev2=7&rev1=6 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Fri Jul 27 16:04:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Jul 2007 11:04:01 -0500 Subject: [Fedora-packaging] Please Update Packaging/RPMMacros to mention lib64 In-Reply-To: <200707271800.28543.opensource@till.name> References: <200707271739.01121.opensource@till.name> <1185554541.3765.122.camel@dhcp83-168.boston.redhat.com> <200707271800.28543.opensource@till.name> Message-ID: <46AA1771.9030209@math.unl.edu> Till Maas wrote: > On Friday 27 July 2007 18:42:21 Tom "spot" Callaway wrote: > >> Added. Thanks, > > Thank you, too. But I am afraid you have to edit it again, because you added > too much: "bb" > See: > http://fedoraproject.org/wiki/Packaging/RPMMacros?action=diff&rev2=7&rev1=6 fixed. -- Rex From mclasen at redhat.com Fri Jul 27 16:38:33 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 12:38:33 -0400 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185552615.3765.116.camel@dhcp83-168.boston.redhat.com> References: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> <46A9EE45.20708@math.unl.edu> <20070727101448.0ac921cf@localhost.localdomain> <20070727145613.GD10303@puariko.nirvana> <1185552615.3765.116.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185554313.3650.49.camel@localhost.localdomain> (Trying to add some constructive criticism now...) I think it would be good if we could ensure that the list of "approved" licenses and their official abbreviations would be in sync with what rpmlint considered valid licenses before this is put in place. Even better if rpmlint had knowledge of the new, machine-readable, license tag syntax and could validate that, too. Matthias From smooge at gmail.com Fri Jul 27 17:09:01 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 27 Jul 2007 11:09:01 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185512303.20980.311.camel@mccallum.corsepiu.local> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185508274.20980.280.camel@mccallum.corsepiu.local> <1185514496.3765.61.camel@dhcp83-168.boston.redhat.com> <1185512303.20980.311.camel@mccallum.corsepiu.local> Message-ID: <80d7e4090707271009j49e1f119y2d53963daf6a8f2d@mail.gmail.com> On 7/26/07, Ralf Corsepius wrote: > > I'm more than willing to take on additional helpers to maintain this > > license registry. I'm very willing to alter the license identifiers to > > make they more simplistic, but without that baseline standard, it won't > > be possible to predictably track license data from packages. > Whatfor? Somebody from the "dark circles" at RH ordered you to do so and > because of the GPLv3 had been introduced. I call this overreaction and > hysteria ... > Ralf, I guess my cover as being the head of the Black Blood Red Hat conspiracy has been found out. I started this effort a long time ago when I was trying to figure out why a non-OSS license package in Fedora was listed as Distributable.. I began a quick listing of packages, but had other issues come up (the moon was in the 6th house, and the its conjunction with Ceres opened a small door for me to commune with my masters). Spot took it up because he thought it was something to be done. You have seen through my ruse of using this to help move the stars into the proper place for R'yleh to rise again and my dark masters to rule once more. It was so much easier to cause the pain and torment of developers than trying to find virgins to sacrifice these days. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tcallawa at redhat.com Fri Jul 27 18:19:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 13:19:20 -0500 Subject: [Fedora-packaging] Re: License Tag Draft In-Reply-To: <1185554313.3650.49.camel@localhost.localdomain> References: <1185500662.3765.30.camel@dhcp83-168.boston.redhat.com> <20070727005006.GB4227@nostromo.devel.redhat.com> <1185509402.20980.296.camel@mccallum.corsepiu.local> <1185514200.3765.56.camel@dhcp83-168.boston.redhat.com> <1185511858.20980.302.camel@mccallum.corsepiu.local> <1185517270.3765.76.camel@dhcp83-168.boston.redhat.com> <1185516739.20980.338.camel@mccallum.corsepiu.local> <20070727085728.31cacf23@ender> <46A9EE45.20708@math.unl.edu> <20070727101448.0ac921cf@localhost.localdomain> <20070727145613.GD10303@puariko.nirvana> <1185552615.3765.116.camel@dhcp83-168.boston.redhat.com> <1185554313.3650.49.camel@localhost.localdomain> Message-ID: <1185560360.3765.124.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 12:38 -0400, Matthias Clasen wrote: > (Trying to add some constructive criticism now...) > > I think it would be good if we could ensure that the list of "approved" > licenses and their official abbreviations would be in sync with what > rpmlint considered valid licenses before this is put in place. Even > better if rpmlint had knowledge of the new, machine-readable, license > tag syntax and could validate that, too. Agreed. I can work on that. ~spot From smooge at gmail.com Fri Jul 27 17:26:57 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 27 Jul 2007 11:26:57 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> Message-ID: <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> On 7/27/07, Tom spot Callaway wrote: > > > # For a breakdown of the licensing, see PACKAGE-LICENSING > Actual would it be possible that we cut down the syntax to the following: License: see PACKAGE-LICENSING PACKAGE-LICENSING: [Change format so that you can autoparse it better: # Packager fill in the following. Package Reviewer check off. Licenses for binaries: GPLv3+ Licenses for documentation: CC v3 OR GFDLv1.1 Licenses for source code: GPLv3+ # Auto built licenses from rpmbuild-find-licenses.py Known License Files Found: GPLv2+ : /usr/share/pudding-pie-1.1.1/COPYING Mozilla 1+ :/usr/share/pudding-pie-1.1.1/MOZILLA_STUFF Unknown Licenses Found: Apache 9 : Found mentioned in ./pudding-pie-1.1.1/zapper.cc # License Headers Found: ./pudding-pie-1.1.1/foo.cc GPLv2+ ./pudding-pie-1.1.1/main.cc Mozilla 1+ ./pudding-pie-1.1.1/zapper.cc Apache 9 .... # No License Headers Found In: ./pudding-pie-1.1.1/foo.h .... The tool could do a rough draft, and try to pull out any bad stuff that might show up.. or at least help a reviewer think to themselves.. wtf Apache 9 License? These could be fed upstream to help the authors better protect their IP, avoid a license issue where their code ends up somewhere because it didnt have a license header etc. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From katzj at redhat.com Fri Jul 27 17:27:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 13:27:13 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> Message-ID: <1185557233.15991.40.camel@localhost.localdomain> On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote: > On 7/27/07, Tom spot Callaway wrote: > > # For a breakdown of the licensing, see PACKAGE-LICENSING > > Actual would it be possible that we cut down the syntax to the following: > > License: see PACKAGE-LICENSING A downside of keeping all the information in a separate file is that it doesn't end up in the metadata and so you have to explode out packages to get at it. Jeremy From tcallawa at redhat.com Fri Jul 27 21:02:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 16:02:44 -0500 Subject: [Fedora-packaging] License Tag Draft: Revised Message-ID: <1185570164.3765.131.camel@dhcp83-168.boston.redhat.com> Please go take a look at the revised License Tag Draft: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag http://fedoraproject.org/wiki/Licensing has also had some minor short name changes. Constructive criticism is welcomed. Conspiratorial rantings will neither be confirmed nor denied. Thanks, ~spot From smooge at gmail.com Fri Jul 27 20:51:47 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 27 Jul 2007 14:51:47 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185557233.15991.40.camel@localhost.localdomain> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> <1185557233.15991.40.camel@localhost.localdomain> Message-ID: <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> On 7/27/07, Jeremy Katz wrote: > On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote: > > On 7/27/07, Tom spot Callaway wrote: > > > # For a breakdown of the licensing, see PACKAGE-LICENSING > > > > Actual would it be possible that we cut down the syntax to the following: > > > > License: see PACKAGE-LICENSING > > A downside of keeping all the information in a separate file is that it > doesn't end up in the metadata and so you have to explode out packages > to get at it. > Well for most single license systems, i could see License: GPLv2 see PACKAGE-LICENSING for more information License: Complicated see PACKAGE-LICENSING for more information License: Frickin' Complicated see PACKAGE-LICENSING for more information License: Spot Died For This Package see PACKAGE-LICENSING for more information With that having the gory bits. The problem I see is that for these side cases.. you are ending up with -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tcallawa at redhat.com Fri Jul 27 21:57:16 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 16:57:16 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> <1185557233.15991.40.camel@localhost.localdomain> <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> Message-ID: <1185573436.3765.146.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 14:51 -0600, Stephen John Smoogen wrote: > On 7/27/07, Jeremy Katz wrote: > > On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote: > > > On 7/27/07, Tom spot Callaway wrote: > > > > # For a breakdown of the licensing, see PACKAGE-LICENSING > > > > > > Actual would it be possible that we cut down the syntax to the following: > > > > > > License: see PACKAGE-LICENSING > > > > A downside of keeping all the information in a separate file is that it > > doesn't end up in the metadata and so you have to explode out packages > > to get at it. > > > > Well for most single license systems, i could see > > License: GPLv2 see PACKAGE-LICENSING for more information > License: Complicated see PACKAGE-LICENSING for more information > License: Frickin' Complicated see PACKAGE-LICENSING for more information > License: Spot Died For This Package see PACKAGE-LICENSING for more information This is really overloading the License field, and sadly, a "PACKAGE-LICENSING" file wouldn't really be any more legally binding. Don't get me wrong, I'd be tickled pink if we did this, but it would add a LOT of overhead, unless it was automatically generated at build time and slid into the package. ~spot From tibbs at math.uh.edu Fri Jul 27 21:19:25 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jul 2007 16:19:25 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> <1185557233.15991.40.camel@localhost.localdomain> <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> Message-ID: >>>>> "SJS" == Stephen John Smoogen writes: SJS> License: GPLv2 see PACKAGE-LICENSING for more information This reminds me to ask if anyone knows WTF %license in the %files list actually does. From the RPM source, build/files.c: VFA_t virtualFileAttributes[] = { { "%dir", 0, 0 }, /* XXX why not RPMFILE_DIR? */ { "%doc", 0, RPMFILE_DOC }, { "%ghost", 0, RPMFILE_GHOST }, { "%exclude", 0, RPMFILE_EXCLUDE }, { "%readme", 0, RPMFILE_README }, { "%license", 0, RPMFILE_LICENSE }, { "%pubkey", 0, RPMFILE_PUBKEY }, { "%policy", 0, RPMFILE_POLICY }, #if WHY_NOT { "%icon", 0, RPMFILE_ICON }, { "%spec", 0, RPMFILE_SPEC }, { "%config", 0, RPMFILE_CONFIG }, { "%missingok", 0, RPMFILE_CONFIG|RPMFILE_MISSINGOK }, { "%noreplace", 0, RPMFILE_CONFIG|RPMFILE_NOREPLACE }, #endif { NULL, 0, 0 } - J< From smooge at gmail.com Fri Jul 27 22:30:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 27 Jul 2007 16:30:39 -0600 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185573436.3765.146.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> <1185557233.15991.40.camel@localhost.localdomain> <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> <1185573436.3765.146.camel@dhcp83-168.boston.redhat.com> Message-ID: <80d7e4090707271530m46aee508v4617587bf0fa3707@mail.gmail.com> On 7/27/07, Tom spot Callaway wrote: > > On Fri, 2007-07-27 at 14:51 -0600, Stephen John Smoogen wrote: > > On 7/27/07, Jeremy Katz wrote: > > > On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote: > > > > On 7/27/07, Tom spot Callaway wrote: > > > > > # For a breakdown of the licensing, see PACKAGE-LICENSING > > > > > > > > Actual would it be possible that we cut down the syntax to the following: > > > > > > > > License: see PACKAGE-LICENSING > > > > > > A downside of keeping all the information in a separate file is that it > > > doesn't end up in the metadata and so you have to explode out packages > > > to get at it. > > > > > > > Well for most single license systems, i could see > > > > License: GPLv2 see PACKAGE-LICENSING for more information > > License: Complicated see PACKAGE-LICENSING for more information > > License: Frickin' Complicated see PACKAGE-LICENSING for more information > > License: Spot Died For This Package see PACKAGE-LICENSING for more information > > This is really overloading the License field, and sadly, a > "PACKAGE-LICENSING" file wouldn't really be any more legally binding. > Well I was going for hyperbole on a Friday email.. before I tried sending it to memo-list :). I am not sure that there is any legally binding part of either the Tag or the PACKAGE-LICENSING file if either were wrong. > Don't get me wrong, I'd be tickled pink if we did this, but it would add > a LOT of overhead, unless it was automatically generated at build time > and slid into the package. > I would like to try and help with this part. Having a PACKAGE-LICENSE, fedora-approved-licenses.rpm, and a find-licences.py would all have to be done together in some stage. The idea is to try and make the life of the maintainer, upstream, and the project easier in the case where unknown licenses creep in, an approved package gets an update that has a bad license in it (Someone changed foo-bar from GPLv2 to MicrosoftOwnsUv1 on this release..). The idea would be to make it as automated as possible, or at least create a report that the maintainer/the reviewer/the board/and the customer could read. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From notting at redhat.com Fri Jul 27 22:48:44 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 18:48:44 -0400 Subject: [Fedora-packaging] License Tag Draft: Revised In-Reply-To: <1185570164.3765.131.camel@dhcp83-168.boston.redhat.com> References: <1185570164.3765.131.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070727224844.GA6996@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > Please go take a look at the revised License Tag Draft: > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > http://fedoraproject.org/wiki/Licensing has also had some minor short > name changes. > > Constructive criticism is welcomed. Conspiratorial rantings will neither > be confirmed nor denied. Looks good to me. Bill From tcallawa at redhat.com Sat Jul 28 04:16:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 23:16:52 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <80d7e4090707271530m46aee508v4617587bf0fa3707@mail.gmail.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <20070727110039.46506188@python3.es.egwn.lan> <1185541545.3765.96.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271026y570efb25i3cb3767e081e114f@mail.gmail.com> <1185557233.15991.40.camel@localhost.localdomain> <80d7e4090707271351q399eb9ag807ecd8428dee2b@mail.gmail.com> <1185573436.3765.146.camel@dhcp83-168.boston.redhat.com> <80d7e4090707271530m46aee508v4617587bf0fa3707@mail.gmail.com> Message-ID: <1185596212.3765.167.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 16:30 -0600, Stephen John Smoogen wrote: > > Don't get me wrong, I'd be tickled pink if we did this, but it would > add > > a LOT of overhead, unless it was automatically generated at build > time > > and slid into the package. > > > > I would like to try and help with this part. Having a PACKAGE-LICENSE, > fedora-approved-licenses.rpm, and a find-licences.py would all have to > be done together in some stage. The idea is to try and make the life > of the maintainer, upstream, and the project easier in the case where > unknown licenses creep in, an approved package gets an update that has > a bad license in it (Someone changed foo-bar from GPLv2 to > MicrosoftOwnsUv1 on this release..). The idea would be to make it as > automated as possible, or at least create a report that the > maintainer/the reviewer/the board/and the customer could read. I'm not going to write it into the draft now, but we can amend it as needed when you've got this ready. It seems to me there's a fair bit of code that would need to be written to "find the licenses" before this could occur, but if you're willing to try, more power to you. ~spot From rc040203 at freenet.de Sat Jul 28 04:23:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 28 Jul 2007 06:23:30 +0200 Subject: [Fedora-packaging] License Tag Draft: Revised In-Reply-To: <1185570164.3765.131.camel@dhcp83-168.boston.redhat.com> References: <1185570164.3765.131.camel@dhcp83-168.boston.redhat.com> Message-ID: <1185596610.20980.446.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 16:02 -0500, Tom "spot" Callaway wrote: > Please go take a look at the revised License Tag Draft: > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > http://fedoraproject.org/wiki/Licensing has also had some minor short > name changes. -1 From ville.skytta at iki.fi Sat Jul 28 09:05:29 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 28 Jul 2007 12:05:29 +0300 Subject: [Fedora-packaging] Re: Users and groups -- the static alternative In-Reply-To: <20070725234203.GF14940@puariko.nirvana> References: <1185305674.4709.76.camel@localhost.localdomain> <20070725234203.GF14940@puariko.nirvana> Message-ID: <200707281205.29595.ville.skytta@iki.fi> On Thursday 26 July 2007, Axel Thimm wrote: > > Ville's proposal was fine For the record, it was me who brought this (finding out if we could go almost-all-static mappings) up in the meeting. I'm still fine with "my" draft, but I thought it'd be a good idea to explicitly discuss and evaluate the static alternative for real too before the dynamic approach is voted on. From ville.skytta at iki.fi Sat Jul 28 09:15:25 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 28 Jul 2007 12:15:25 +0300 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> Message-ID: <200707281215.25836.ville.skytta@iki.fi> On Friday 27 July 2007, Tom "spot" Callaway wrote: > > Utopia: RPM could support License(STRING), then we could have multiple > license tags for packages. Provides could be (ab?)used for that, eg: Provides: License(Apache2), License(BSD) Provides: License(Artistic||GPLv2+) From Axel.Thimm at ATrpms.net Sat Jul 28 09:15:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Jul 2007 11:15:52 +0200 Subject: [Fedora-packaging] Re: Users and groups -- the static alternative In-Reply-To: <200707281205.29595.ville.skytta@iki.fi> References: <1185305674.4709.76.camel@localhost.localdomain> <20070725234203.GF14940@puariko.nirvana> <200707281205.29595.ville.skytta@iki.fi> Message-ID: <20070728091552.GA4993@puariko.nirvana> On Sat, Jul 28, 2007 at 12:05:29PM +0300, Ville Skytt? wrote: > On Thursday 26 July 2007, Axel Thimm wrote: > > > > Ville's proposal was fine > > For the record, it was me who brought this (finding out if we could go > almost-all-static mappings) up in the meeting. I'm still fine with "my" > draft, but I thought it'd be a good idea to explicitly discuss and evaluate > the static alternative for real too before the dynamic approach is voted on. OK, no problem. Next meeting we'll start discussing about switching to deb format for packages. ;) -- 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 Sat Jul 28 15:49:33 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 28 Jul 2007 10:49:33 -0500 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <200707281215.25836.ville.skytta@iki.fi> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> <200707281215.25836.ville.skytta@iki.fi> Message-ID: <1185637773.3765.184.camel@dhcp83-168.boston.redhat.com> On Sat, 2007-07-28 at 12:15 +0300, Ville Skytt? wrote: > On Friday 27 July 2007, Tom "spot" Callaway wrote: > > > > Utopia: RPM could support License(STRING), then we could have multiple > > license tags for packages. > > Provides could be (ab?)used for that, eg: > > Provides: License(Apache2), License(BSD) > Provides: License(Artistic||GPLv2+) Wow. I can just hear yum choking on itself and dying. I'd feel very sorry for the first person who did: yum install "License(BSD)" ~spot From jkeating at j2solutions.net Sat Jul 28 15:08:38 2007 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 28 Jul 2007 11:08:38 -0400 Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185637773.3765.184.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> <200707281215.25836.ville.skytta@iki.fi> <1185637773.3765.184.camel@dhcp83-168.boston.redhat.com> Message-ID: <20070728110838.7c13b9cd@ender> On Sat, 28 Jul 2007 10:49:33 -0500 "Tom \"spot\" Callaway" wrote: > yum install "License(BSD)" Shortest name would win. You'd get one (maybe two for multilib) packages installed, at most. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Jul 28 15:29:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 28 Jul 2007 18:29:50 +0300 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? Message-ID: <200707281829.51199.ville.skytta@iki.fi> Hi, How about making empty debuginfo packages a build error? I can't think of a reason why an empty one would be a desired result, but empty ones do almost always indicate problems with the build. Arch specific packages that expectedly don't have anything to place into the debuginfo package should explicitly disable it eg. with "%define debug_package %{nil}". Also submitted as https://bugzilla.redhat.com/249956 From tibbs at math.uh.edu Sat Jul 28 16:15:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 11:15:07 -0500 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: <200707281829.51199.ville.skytta@iki.fi> References: <200707281829.51199.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> How about making empty debuginfo packages a build error? Sure. And I'm having trouble coming up with a situation where a debuginfo containing a single file is OK, since it generally indicates that debuginfo was extracted from an executable but no source was found. (Common for Java packages, at least.) Or is such a stunted debuginfo package still considered useful? - J< From ville.skytta at iki.fi Sat Jul 28 16:50:18 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 28 Jul 2007 19:50:18 +0300 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: References: <200707281829.51199.ville.skytta@iki.fi> Message-ID: <200707281950.19068.ville.skytta@iki.fi> On Saturday 28 July 2007, Jason L Tibbitts III wrote: > >>>>> "VS" == Ville Skytt? writes: > > VS> How about making empty debuginfo packages a build error? > > Sure. And I'm having trouble coming up with a situation where a > debuginfo containing a single file is OK, since it generally indicates > that debuginfo was extracted from an executable but no source was > found. (Common for Java packages, at least.) Yep, ditto cases where "strip -g" is invoked on the binaries before find-debuginfo.sh does its thing, or the binaries are built without -g which almost always means that $RPM_OPT_FLAGS aren't being used either and at that point useless -debuginfo is no longer necessarily the biggest problem. > Or is such a stunted > debuginfo package still considered useful? I don't think so, at least generally, but detecting it without false positives is harder than the empty debuginfo case. And the Java case is a good example of another problem - I'm not sure we'd want people to disable debuginfo packages because the tools don't support creating sane ones from them yet. From tibbs at math.uh.edu Sat Jul 28 17:01:11 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 12:01:11 -0500 Subject: [Fedora-packaging] rpmlint check for proper %defattr? Message-ID: I'm seeing a lot of reviews lately with complaints about %defattr. I admit to not always checking it myself, but this seems to be the kind of thing that rpmlint could easily check for. I know that the complete lack of %defattr is problematic, but I'm not sure whether "%defattr(-,root,root)" is a blocker or not. The only place it seems to be mentioned is in %lang section of the guidelines (and in templates contained in the various language-specific guidelines). - J< From ivazqueznet at gmail.com Sat Jul 28 17:07:29 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 28 Jul 2007 13:07:29 -0400 Subject: [Fedora-packaging] rpmlint check for proper %defattr? In-Reply-To: References: Message-ID: <1185642449.13492.1.camel@ignacio.lan> On Sat, 2007-07-28 at 12:01 -0500, Jason L Tibbitts III wrote: > I know that the complete lack of %defattr is problematic, Yes. > but I'm not > sure whether "%defattr(-,root,root)" is a blocker or not. No. It's perfectly valid for a package to not have any files owned by root. Yes, it would be unusual, but not wrong per se. -- Ignacio Vazquez-Abrams -------------- 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 tibbs at math.uh.edu Sat Jul 28 17:08:03 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 12:08:03 -0500 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: <200707281950.19068.ville.skytta@iki.fi> References: <200707281829.51199.ville.skytta@iki.fi> <200707281950.19068.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> And the Java case is a good example of another problem - I'm not VS> sure we'd want people to disable debuginfo packages because the VS> tools don't support creating sane ones from them yet. Actually it's possible to fix the Java packages; you have to move the source so that the scripts will find it. I've been through this on pretty much all of the Java packages I reviewed. (It's been a while since I did one, though.) I've also had to do this with some Perl XS-built packages. I admit this is nasty, but I've been assuming that we really want proper debuginfo when we can get it. - J< From ville.skytta at iki.fi Sat Jul 28 19:19:15 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 28 Jul 2007 22:19:15 +0300 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: References: <200707281829.51199.ville.skytta@iki.fi> <200707281950.19068.ville.skytta@iki.fi> Message-ID: <200707282219.15763.ville.skytta@iki.fi> On Saturday 28 July 2007, Jason L Tibbitts III wrote: > >>>>> "VS" == Ville Skytt? writes: > > VS> And the Java case is a good example of another problem - I'm not > VS> sure we'd want people to disable debuginfo packages because the > VS> tools don't support creating sane ones from them yet. > > Actually it's possible to fix the Java packages; you have to move the > source so that the scripts will find it. I've been through this on > pretty much all of the Java packages I reviewed. (It's been a while > since I did one, though.) I've also had to do this with some Perl > XS-built packages. Ah, good to know. If there's a common pattern how these files need to be moved around or how to generally find a way to do it, could you add some info about it to http://fedoraproject.org/wiki/Packaging/Debuginfo ? > I admit this is nasty, but I've been assuming that we really want > proper debuginfo when we can get it. Ditto. From opensource at till.name Sat Jul 28 19:26:12 2007 From: opensource at till.name (Till Maas) Date: Sat, 28 Jul 2007 21:26:12 +0200 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: References: <200707281829.51199.ville.skytta@iki.fi> <200707281950.19068.ville.skytta@iki.fi> Message-ID: <200707282126.16053.opensource@till.name> On Saturday 28 July 2007 19:08:03 Jason L Tibbitts III wrote: > Actually it's possible to fix the Java packages; you have to move the > source so that the scripts will find it. I've been through this on Is it not possible to fix the script to find the source files without moving them? Or maybe add an enviroment variable to specify where it should search? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Sat Jul 28 19:25:46 2007 From: opensource at till.name (Till Maas) Date: Sat, 28 Jul 2007 21:25:46 +0200 Subject: [Fedora-packaging] rpmlint check for proper %defattr? In-Reply-To: References: Message-ID: <200707282125.57899.opensource@till.name> On Saturday 28 July 2007 19:01:11 Jason L Tibbitts III wrote: > I know that the complete lack of %defattr is problematic, but I'm not > sure whether "%defattr(-,root,root)" is a blocker or not. The only Why is it sometimes %defattr(-,root,root) and sometimes %defattr(-,root,root,-) (which is what rpmdev-newspec generates)? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pmatilai at laiskiainen.org Sat Jul 28 19:58:09 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 22:58:09 +0300 (EEST) Subject: [Fedora-packaging] License Tag Draft In-Reply-To: <1185637773.3765.184.camel@dhcp83-168.boston.redhat.com> References: <1185492479.3765.6.camel@dhcp83-168.boston.redhat.com> <1185500969.3765.35.camel@dhcp83-168.boston.redhat.com> <1185501296.3765.41.camel@dhcp83-168.boston.redhat.com> <200707281215.25836.ville.skytta@iki.fi> <1185637773.3765.184.camel@dhcp83-168.boston.redhat.com> Message-ID: On Sat, 28 Jul 2007, Tom \spot\ Callaway wrote: > On Sat, 2007-07-28 at 12:15 +0300, Ville Skytt? wrote: >> On Friday 27 July 2007, Tom "spot" Callaway wrote: >>> >>> Utopia: RPM could support License(STRING), then we could have multiple >>> license tags for packages. >> >> Provides could be (ab?)used for that, eg: >> >> Provides: License(Apache2), License(BSD) >> Provides: License(Artistic||GPLv2+) > > Wow. I can just hear yum choking on itself and dying. > > I'd feel very sorry for the first person who did: > > yum install "License(BSD)" Yeah, provides wont do. Dunno if you saw my "utopia" mail in this thread - some of it might be utter utopia but not all. I'm willing to help from rpm side, we just need to figure out what exactly is it that'd needed. Getting rpm enhacements widely deployed is a slooooooooooooow process so it'd better be reasonably well defined by the first attempt :) - Panu - From ivazqueznet at gmail.com Sat Jul 28 19:58:58 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 28 Jul 2007 15:58:58 -0400 Subject: [Fedora-packaging] rpmlint check for proper %defattr? In-Reply-To: <200707282125.57899.opensource@till.name> References: <200707282125.57899.opensource@till.name> Message-ID: <1185652738.13492.5.camel@ignacio.lan> On Sat, 2007-07-28 at 21:25 +0200, Till Maas wrote: > Why is it sometimes %defattr(-,root,root) and > sometimes %defattr(-,root,root,-) (which is what rpmdev-newspec generates)? I believe the complete spec for %defattr is: "%defattr" "(" fileperms ["," user-owner ["," group-owner ["," dirperms] ] ] ")" with "-" in {file,dir}perms meaning no change from what it already has. -- Ignacio Vazquez-Abrams -------------- 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 tibbs at math.uh.edu Sat Jul 28 20:21:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 15:21:26 -0500 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: <200707282126.16053.opensource@till.name> References: <200707281829.51199.ville.skytta@iki.fi> <200707281950.19068.ville.skytta@iki.fi> <200707282126.16053.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Is it not possible to fix the script to find the source files TM> without moving them? Honestly I know nothing about how the debuginfo is generated and I'm loath to poke around in there. - J< From pmatilai at laiskiainen.org Sat Jul 28 20:22:15 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 23:22:15 +0300 (EEST) Subject: [Fedora-packaging] rpmlint check for proper %defattr? In-Reply-To: <1185652738.13492.5.camel@ignacio.lan> References: <200707282125.57899.opensource@till.name> <1185652738.13492.5.camel@ignacio.lan> Message-ID: On Sat, 28 Jul 2007, Ignacio Vazquez-Abrams wrote: > On Sat, 2007-07-28 at 21:25 +0200, Till Maas wrote: >> Why is it sometimes %defattr(-,root,root) and >> sometimes %defattr(-,root,root,-) (which is what rpmdev-newspec generates)? > > I believe the complete spec for %defattr is: > > "%defattr" "(" fileperms ["," user-owner ["," group-owner ["," > dirperms] ] ] ")" > > with "-" in {file,dir}perms meaning no change from what it already has. Yup. If something, rpmlint should check for unattributed files: ones that aren't covered by %defattr or file-specific %attr. Missing %defattr isn't an error, totally unattributed files are (or should be treated as such, perhaps on rpmbuild level) because the outcome then relies on who happens to build the package. - Panu - From tibbs at math.uh.edu Sat Jul 28 20:25:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 15:25:18 -0500 Subject: [Fedora-packaging] Make empty debuginfo packages a build error? In-Reply-To: <200707282219.15763.ville.skytta@iki.fi> References: <200707281829.51199.ville.skytta@iki.fi> <200707281950.19068.ville.skytta@iki.fi> <200707282219.15763.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> If there's a common pattern how these files need to be moved VS> around or how to generally find a way to do it, could you add some VS> info about it to http://fedoraproject.org/wiki/Packaging/Debuginfo VS> ? I'm not sure that I even remember how to do it. I guess I could review another Java package, or I could try to find an on-point review. Here's one: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191014 I note that you've commented in there as well. - J< From herrold at owlriver.com Sun Jul 29 19:53:02 2007 From: herrold at owlriver.com (R P Herrold) Date: Sun, 29 Jul 2007 15:53:02 -0400 (EDT) Subject: [Fedora-packaging] Users and groups -- the static alternative In-Reply-To: <1185551728.3765.113.camel@dhcp83-168.boston.redhat.com> References: <1185305674.4709.76.camel@localhost.localdomain> <45353.192.54.193.51.1185437255.squirrel@rousalka.dyndns.org> <1185551728.3765.113.camel@dhcp83-168.boston.redhat.com> Message-ID: On Fri, 27 Jul 2007, Tom "spot" Callaway wrote: >> Mats Wichmann of the LSB, and I discussed Linux Assigned Names >> And Numbers Authority matters at OLS a few weeks ago at some >> length, and the matter was discussed in the LSB weekly >> conference call on Wednesday with him and me leading the ... >> http://www.lanana.org/ >> and there is certainly an interest at the LSB in helping reach >> inter-vendor coordination in this space. > Russ, it seems to me like there is some logic in having a centralized > "assignment" for static UID/GIDs, across distributions. Is this > something that LANANA would be interested in maintaining? While I need to run it past the LSB side, it is a natural fit for LANANA --- we'll discuss it Wednesday, I imagine. -- Russ From petersen at redhat.com Tue Jul 31 06:06:23 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 31 Jul 2007 16:06:23 +1000 Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: References: <46A7F596.7020101@redhat.com> Message-ID: <46AED15F.6070702@redhat.com> Ok, thanks for the responses. Rex Dieter ????????: >> I'll for responses before changing it to: >> %{_bindir}/fc-cache %{_datadir}/fonts > > do it Just noticed that I don't have permission to edit that page, so can someone here please fix it? Thanks, Jens -- Jens Petersen Internationalization Team Red Hat From Axel.Thimm at ATrpms.net Tue Jul 31 08:24:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 31 Jul 2007 10:24:37 +0200 Subject: [Fedora-packaging] Missing most meetings until mid-September Message-ID: <20070731082437.GC6038@puariko.nirvana> Hi, I'm quite busy in August [no, not with a vacation ... :/], so I will have to skip most meetings. Please ping me when my vote is needed (although most voting are almost unanimous, so my vote will not be neccessary). I'll try to look into the meetings whenever possible. -- 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 Jul 31 08:25:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 31 Jul 2007 10:25:50 +0200 Subject: [Fedora-packaging] Re: why not %{_datadir} on fonts scripletsnippet In-Reply-To: <46AED15F.6070702@redhat.com> References: <46A7F596.7020101@redhat.com> <46AED15F.6070702@redhat.com> Message-ID: <20070731082550.GD6038@puariko.nirvana> On Tue, Jul 31, 2007 at 04:06:23PM +1000, Jens Petersen wrote: > Rex Dieter ????????: > >> %{_bindir}/fc-cache %{_datadir}/fonts > > > >do it > > Just noticed that I don't have permission to edit that page, > so can someone here please fix it? done (I think only PC members are allowed to edit these pages) -- 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: