From jkeating at redhat.com Fri Sep 1 22:35:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 01 Sep 2006 18:35:19 -0400 Subject: libxml no longer needed Message-ID: <1157150119.6577.50.camel@ender> It's been discovered (thanks Bill) that nothing in Core or Extras seems to need libxml. We'd like to kill it from the tree, before the freeze for Test3 (Tuesday). Speak now, or forever hold your pieces of packages. -- Jesse Keating Release Engineer: Fedora -------------- 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 Fri Sep 1 23:08:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 01 Sep 2006 19:08:50 -0400 Subject: FC6 Test3 Freeze coming very soon Message-ID: <1157152130.6577.57.camel@ender> Sorry for the late reminder, but the freeze for FC6 Test3 is set for Tuesday. Please be aware of this (: We plan to have release candidate isos spun by Wed or Thur, and sync to the mirrors started by Friday for a Wed release. -- Jesse Keating Release Engineer: Fedora -------------- 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 paul at city-fan.org Sat Sep 2 08:39:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 02 Sep 2006 09:39:59 +0100 Subject: libxml no longer needed In-Reply-To: <1157150119.6577.50.camel@ender> References: <1157150119.6577.50.camel@ender> Message-ID: <1157186399.19179.4.camel@metropolis.intra.city-fan.org> On Fri, 2006-09-01 at 18:35 -0400, Jesse Keating wrote: > It's been discovered (thanks Bill) that nothing in Core or Extras seems > to need libxml. We'd like to kill it from the tree, before the freeze > for Test3 (Tuesday). Speak now, or forever hold your pieces of > packages. It's a dependency of libglade, which is up for review for entry into Extras (#198244). If it's going from Core I'll pick it up for Extras. Paul. From veillard at redhat.com Sat Sep 2 12:31:26 2006 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 2 Sep 2006 08:31:26 -0400 Subject: libxml no longer needed In-Reply-To: <1157186399.19179.4.camel@metropolis.intra.city-fan.org> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> Message-ID: <20060902123126.GA20136@redhat.com> On Sat, Sep 02, 2006 at 09:39:59AM +0100, Paul Howarth wrote: > On Fri, 2006-09-01 at 18:35 -0400, Jesse Keating wrote: > > It's been discovered (thanks Bill) that nothing in Core or Extras seems > > to need libxml. We'd like to kill it from the tree, before the freeze > > for Test3 (Tuesday). Speak now, or forever hold your pieces of > > packages. > > It's a dependency of libglade, which is up for review for entry into > Extras (#198244). If it's going from Core I'll pick it up for Extras. What is using libglade then ? Anything relying on libxml version 1 really must die now ! You should block libglade from Extras if it really is so far behind and has no app needing it. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From paul at city-fan.org Sat Sep 2 13:59:23 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 02 Sep 2006 14:59:23 +0100 Subject: libxml no longer needed In-Reply-To: <20060902123126.GA20136@redhat.com> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> <20060902123126.GA20136@redhat.com> Message-ID: <1157205563.19179.9.camel@metropolis.intra.city-fan.org> On Sat, 2006-09-02 at 08:31 -0400, Daniel Veillard wrote: > On Sat, Sep 02, 2006 at 09:39:59AM +0100, Paul Howarth wrote: > > On Fri, 2006-09-01 at 18:35 -0400, Jesse Keating wrote: > > > It's been discovered (thanks Bill) that nothing in Core or Extras seems > > > to need libxml. We'd like to kill it from the tree, before the freeze > > > for Test3 (Tuesday). Speak now, or forever hold your pieces of > > > packages. > > > > It's a dependency of libglade, which is up for review for entry into > > Extras (#198244). If it's going from Core I'll pick it up for Extras. > > What is using libglade then ? Anything relying on libxml version 1 > really must die now ! You should block libglade from Extras if it really > is so far behind and has no app needing it. I need libglade for pptpconfig, which is written in php-gtk; there is work going on to port it to pygtk but that is stalled at the moment due to lack of manpower. Lots of people find pptpconfig very useful for configuring connections to Windows VPN servers. Paul. From veillard at redhat.com Sat Sep 2 14:10:44 2006 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 2 Sep 2006 10:10:44 -0400 Subject: libxml no longer needed In-Reply-To: <1157205563.19179.9.camel@metropolis.intra.city-fan.org> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> <20060902123126.GA20136@redhat.com> <1157205563.19179.9.camel@metropolis.intra.city-fan.org> Message-ID: <20060902141043.GA22060@redhat.com> On Sat, Sep 02, 2006 at 02:59:23PM +0100, Paul Howarth wrote: > On Sat, 2006-09-02 at 08:31 -0400, Daniel Veillard wrote: > > On Sat, Sep 02, 2006 at 09:39:59AM +0100, Paul Howarth wrote: > > > On Fri, 2006-09-01 at 18:35 -0400, Jesse Keating wrote: > > > > It's been discovered (thanks Bill) that nothing in Core or Extras seems > > > > to need libxml. We'd like to kill it from the tree, before the freeze > > > > for Test3 (Tuesday). Speak now, or forever hold your pieces of > > > > packages. > > > > > > It's a dependency of libglade, which is up for review for entry into > > > Extras (#198244). If it's going from Core I'll pick it up for Extras. > > > > What is using libglade then ? Anything relying on libxml version 1 > > really must die now ! You should block libglade from Extras if it really > > is so far behind and has no app needing it. > > I need libglade for pptpconfig, which is written in php-gtk; there is > work going on to port it to pygtk but that is stalled at the moment due > to lack of manpower. Lots of people find pptpconfig very useful for > configuring connections to Windows VPN servers. PHP uses libxml2 ... I don't see how you could get both versions of the library to cohabit in the same address space... smells very fishy to me Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From paul at city-fan.org Sat Sep 2 18:43:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 02 Sep 2006 19:43:27 +0100 Subject: libxml no longer needed In-Reply-To: <20060902141043.GA22060@redhat.com> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> <20060902123126.GA20136@redhat.com> <1157205563.19179.9.camel@metropolis.intra.city-fan.org> <20060902141043.GA22060@redhat.com> Message-ID: <1157222607.19179.13.camel@metropolis.intra.city-fan.org> On Sat, 2006-09-02 at 10:10 -0400, Daniel Veillard wrote: > On Sat, Sep 02, 2006 at 02:59:23PM +0100, Paul Howarth wrote: > > On Sat, 2006-09-02 at 08:31 -0400, Daniel Veillard wrote: > > > On Sat, Sep 02, 2006 at 09:39:59AM +0100, Paul Howarth wrote: > > > > On Fri, 2006-09-01 at 18:35 -0400, Jesse Keating wrote: > > > > > It's been discovered (thanks Bill) that nothing in Core or Extras seems > > > > > to need libxml. We'd like to kill it from the tree, before the freeze > > > > > for Test3 (Tuesday). Speak now, or forever hold your pieces of > > > > > packages. > > > > > > > > It's a dependency of libglade, which is up for review for entry into > > > > Extras (#198244). If it's going from Core I'll pick it up for Extras. > > > > > > What is using libglade then ? Anything relying on libxml version 1 > > > really must die now ! You should block libglade from Extras if it really > > > is so far behind and has no app needing it. > > > > I need libglade for pptpconfig, which is written in php-gtk; there is > > work going on to port it to pygtk but that is stalled at the moment due > > to lack of manpower. Lots of people find pptpconfig very useful for > > configuring connections to Windows VPN servers. > > PHP uses libxml2 ... I don't see how you could get both versions > of the library to cohabit in the same address space... smells very fishy > to me PHP-GTK requires PHP4, and pptpconfig requires the pcntl extension, so I use an cut-down PHP4 with pcntl compiled in to support PHP-GTK, and hence libxml2 isn't used. Paul. From dwmw2 at infradead.org Mon Sep 4 04:36:38 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 03 Sep 2006 21:36:38 -0700 Subject: libxml no longer needed In-Reply-To: <1157205563.19179.9.camel@metropolis.intra.city-fan.org> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> <20060902123126.GA20136@redhat.com> <1157205563.19179.9.camel@metropolis.intra.city-fan.org> Message-ID: <1157344598.2473.80.camel@shinybook.infradead.org> On Sat, 2006-09-02 at 14:59 +0100, Paul Howarth wrote: > I need libglade for pptpconfig, which is written in php-gtk; there is > work going on to port it to pygtk but that is stalled at the moment due > to lack of manpower. Lots of people find pptpconfig very useful for > configuring connections to Windows VPN servers. Surely we should be using system-config-network for this? -- dwmw2 From paul at city-fan.org Mon Sep 4 07:40:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 04 Sep 2006 08:40:51 +0100 Subject: libxml no longer needed In-Reply-To: <1157344598.2473.80.camel@shinybook.infradead.org> References: <1157150119.6577.50.camel@ender> <1157186399.19179.4.camel@metropolis.intra.city-fan.org> <20060902123126.GA20136@redhat.com> <1157205563.19179.9.camel@metropolis.intra.city-fan.org> <1157344598.2473.80.camel@shinybook.infradead.org> Message-ID: <1157355651.19179.25.camel@metropolis.intra.city-fan.org> On Sun, 2006-09-03 at 21:36 -0700, David Woodhouse wrote: > On Sat, 2006-09-02 at 14:59 +0100, Paul Howarth wrote: > > I need libglade for pptpconfig, which is written in php-gtk; there is > > work going on to port it to pygtk but that is stalled at the moment due > > to lack of manpower. Lots of people find pptpconfig very useful for > > configuring connections to Windows VPN servers. > > Surely we should be using system-config-network for this? It would be great if system-config-network could do that, though I'd still have to maintain pptpconfig upstream for the benefit of non-Fedora/RedHat and legacy users. Paul. From rc040203 at freenet.de Mon Sep 4 11:41:10 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Sep 2006 13:41:10 +0200 Subject: Free Software audit update In-Reply-To: <20060831124757.4ca36244@python2> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> Message-ID: <1157370070.4488.46.camel@mccallum.corsepiu.local> On Thu, 2006-08-31 at 12:47 +0200, Matthias Saou wrote: > Ralf Corsepius wrote : > > > On Wed, 2006-08-30 at 21:06 +0200, Patrice Dumas wrote: > > > On Wed, Aug 30, 2006 at 11:15:09AM -0500, Tom 'spot' Callaway wrote: > > > > > > > * Working hard to get lesstif in and openmotif out before FC-6. > > > > > > lesstif is built in fedora extras now. > > > > > > We can start rebuilding against lesstif now, but I don't think we should > > > remove openmotif hastily. The devel packages conflict but the packages > > > that contain the libs don't conflict. So a user that want to build his > > > own apps against openmotif can do it, and the libs are available for > > > linking even if lesstif is used to build. > > A fact, I consider to be a fault of FE QA and bad design of yours. > > > > You should have packaged lesstif in such a way both openmotif-devel and > > lesstif-devel can be installed in parallel. > > If lesstif is to be considered a straight drop-in replacement for > openmotif, Lesstif isn't a drop-in replacement. It tries to clone the OpenMotif API, but it isn't ABI nor 100% API compatible. I.e. packaging-wise Pertusus is not replacing OpenMotif with something compatible, he is removing one package and adding a new (incompatible) one instead. > then I don't really see why this is a fault or a bad design. > Here, packagers will just need to s/openmotif-devel/lesstif-devel/ and > have their application link against lesstif. ... until they hit a behavioral difference, or a bug in lesstif ... > No further changes > required is something I'd consider positive (i.e. no need to force an > include or library path for motif). Furthermore, since the idea is to > completely drop openmotif ASAP, this is really a low priority (almost > 'non') issue IMHO. To me, OpenMotif is one of the foundations of my work. Petusus has just kicked my work off from Fedora and rendered Fedora into a platform not worth to be considered for a part of my work in future. So be it :) Ralf From michael at knox.net.nz Mon Sep 4 11:45:01 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 4 Sep 2006 23:45:01 +1200 (NZST) Subject: Free Software audit update In-Reply-To: <1157370070.4488.46.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> Message-ID: <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> Ralf Corsepius wrote: > To me, OpenMotif is one of the foundations of my work. Petusus has just > kicked my work off from Fedora and rendered Fedora into a platform not > worth to be considered for a part of my work in future. So be it :) No.. Petusus did no such thing. The license of OpenMotif is the problem. OpenMotif is not compatible with Fedora's license guidelines. Its grossly unfair to "point the finger" at a Fedora contributor for that. Fedora is certainly not the first to drop the use of OpenMotif and port apps to use LessTif and I doubt it will be the last. Michael From skvidal at linux.duke.edu Mon Sep 4 11:49:07 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 04 Sep 2006 07:49:07 -0400 Subject: Free Software audit update In-Reply-To: <1157370070.4488.46.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> Message-ID: <1157370547.16181.4.camel@cutter> On Mon, 2006-09-04 at 13:41 +0200, Ralf Corsepius wrote: > To me, OpenMotif is one of the foundations of my work. Petusus has just > kicked my work off from Fedora and rendered Fedora into a platform not > worth to be considered for a part of my work in future. So be it :) Then that's the way it'll have to be, Ralf. We're not going to change our policies on the legal/licensing issues just b/c you're threatening to not be involved. It doesn't work that way. -sv From alan at redhat.com Mon Sep 4 11:52:57 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Sep 2006 07:52:57 -0400 Subject: Free Software audit update In-Reply-To: <1157370070.4488.46.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> Message-ID: <20060904115257.GA9371@devserv.devel.redhat.com> On Mon, Sep 04, 2006 at 01:41:10PM +0200, Ralf Corsepius wrote: > Lesstif isn't a drop-in replacement. It tries to clone the OpenMotif > API, but it isn't ABI nor 100% API compatible. It certainly doesn't try to be ABI compatible, for API issues "send patches" > To me, OpenMotif is one of the foundations of my work. Petusus has just > kicked my work off from Fedora and rendered Fedora into a platform not > worth to be considered for a part of my work in future. So be it :) For out of tree code you can package openmotif with your package so I don't see a big problem. I'm sure several proprietary vendors will continue to do that or static link motif as they do now. From denis at poolshark.org Mon Sep 4 12:00:22 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 04 Sep 2006 14:00:22 +0200 Subject: Free Software audit update In-Reply-To: <1157370070.4488.46.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> Message-ID: <44FC1556.4030701@poolshark.org> Ralf Corsepius wrote: > To me, OpenMotif is one of the foundations of my work. Petusus has just > kicked my work off from Fedora and rendered Fedora into a platform not > worth to be considered for a part of my work in future. So be it :) Ralf, what is the OpenMotif-based application that you depend upon ? I'm sure we can iron out the most obvious compatibility bugs out of lesstif fairly quickly if enough people are interested. From alexl at redhat.com Mon Sep 4 13:11:26 2006 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 04 Sep 2006 15:11:26 +0200 Subject: devel packages with only one .pc file Message-ID: <1157375487.4016.112.camel@greebo> I've recently got several bugs against package involving basically splitting out only one pkg-config file into a -devel package, because the packaging guidelines says so. I've done this for a couple of packages, but its starting to get very ridicolous. The one-file -devel package is totally useless, all it leads to is: * Existance of -devel package means we bloat the 64bit distro with the 32bit version of the main package too. * Developers, script or packages fail because they want to use the .pc file but the -devel package is not installed. * The package metadata (like changelog) stored twice in the rpm database. I can't really think of any advantages. What exactly is the reasoning behind this rule? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly neurotic stage actor on a search for his missing sister. She's a time-travelling foul-mouthed femme fatale trying to make a difference in a man's world. They fight crime! From bugs.michael at gmx.net Mon Sep 4 14:43:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Sep 2006 16:43:20 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157375487.4016.112.camel@greebo> References: <1157375487.4016.112.camel@greebo> Message-ID: <20060904164320.39ca6ded.bugs.michael@gmx.net> On Mon, 04 Sep 2006 15:11:26 +0200, Alexander Larsson wrote: > I've recently got several bugs against package involving basically > splitting out only one pkg-config file into a -devel package, Examples, please. > because > the packaging guidelines says so. I've done this for a couple of > packages, but its starting to get very ridicolous. > The one-file -devel package is totally useless, all it leads to is: Whether it is really ridiculous or useless depends on the contents of the .pc file. > * Existance of -devel package means we bloat the 64bit distro with the > 32bit version of the main package too. Which would also be the case if the main package did "Provides: %name-devel = %version-%release", which it ought to do if it includes "devel" stuff. > * Developers, script or packages fail because they want to use the .pc > file but the -devel package is not installed. Not an issue with correct "BuildRequires" and correct dependency chains in general. > * The package metadata (like changelog) stored twice in the rpm > database. > > I can't really think of any advantages. What exactly is the reasoning > behind this rule? Above all, if a .pc file specifies dependencies on other .pc files (e.g. in its own "Requires" line), this must be reflected in the package's "Requires". Else there are missing dependencies, which pile up and which are very tiresome for developers and packagers, who need to search for the packages, which provide the needed .pc files and their dependencies. So, if a .pc file influences the RPM package's dependency chain, this must not be ignored. From alexl at redhat.com Mon Sep 4 15:42:10 2006 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 04 Sep 2006 17:42:10 +0200 Subject: devel packages with only one .pc file In-Reply-To: <20060904164320.39ca6ded.bugs.michael@gmx.net> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> Message-ID: <1157384530.4016.136.camel@greebo> On Mon, 2006-09-04 at 16:43 +0200, Michael Schwendt wrote: > On Mon, 04 Sep 2006 15:11:26 +0200, Alexander Larsson wrote: > > > I've recently got several bugs against package involving basically > > splitting out only one pkg-config file into a -devel package, > > Examples, please. A typical example is gtk-sharp2-devel. It contains only four pc files. There are no headers or anything, because for mono you don't need anything but the dll. Another example is in mono. Here the "mono-nunit" subpackage contains a similar pkg-config file. This case is even weirder, because nunit (being a framework for developing unit tests) is clearly already a development application, and you wouldn't really install it if you weren't already doing development. > > * Existance of -devel package means we bloat the 64bit distro with the > > 32bit version of the main package too. > > Which would also be the case if the main package did > "Provides: %name-devel = %version-%release", which it ought to do > if it includes "devel" stuff. Sure, but an alternative would be to just let the main package contain the pc file and not involve the "-devel" stuff at all. > > * Developers, script or packages fail because they want to use the .pc > > file but the -devel package is not installed. > > Not an issue with correct "BuildRequires" and correct dependency > chains in general. The argument is that its easy to forget this dependency, in for instance the nunit example above, especially since upstream doesn't have these subpackages. One would expect that pulling in the nunit package would give you a working unit test system, not expecting you to have to pull in nunit-devel. > > I can't really think of any advantages. What exactly is the reasoning > > behind this rule? > > Above all, if a .pc file specifies dependencies on other .pc files (e.g. > in its own "Requires" line), this must be reflected in the package's > "Requires". Else there are missing dependencies, which pile up and which > are very tiresome for developers and packagers, who need to search for the > packages, which provide the needed .pc files and their dependencies. > > So, if a .pc file influences the RPM package's dependency chain, this > must not be ignored. In many cases these pc files have not pc file dependencies, and in others they only have dependencies on pc files where the pc file also didn't have to be in a -devel subpackage, so this isn't always a problem. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lounge-singing day-dreaming gangster on the edge. She's a sharp-shooting gypsy former first lady operating on the wrong side of the law. They fight crime! From jkeating at j2solutions.net Mon Sep 4 17:02:13 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 04 Sep 2006 13:02:13 -0400 Subject: devel packages with only one .pc file In-Reply-To: <1157384530.4016.136.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> Message-ID: <1157389333.2047.12.camel@ender> On Mon, 2006-09-04 at 17:42 +0200, Alexander Larsson wrote: > On Mon, 2006-09-04 at 16:43 +0200, Michael Schwendt wrote: > > On Mon, 04 Sep 2006 15:11:26 +0200, Alexander Larsson wrote: > > > > > I've recently got several bugs against package involving basically > > > splitting out only one pkg-config file into a -devel package, > > > > Examples, please. > > A typical example is gtk-sharp2-devel. It contains only four pc files. > There are no headers or anything, because for mono you don't need > anything but the dll. > > Another example is in mono. Here the "mono-nunit" subpackage contains a > similar pkg-config file. This case is even weirder, because nunit (being > a framework for developing unit tests) is clearly already a development > application, and you wouldn't really install it if you weren't already > doing development. Perhaps in the case of mono, where the main package has no difference between the runtime and the development files (one in the same) then the .pc file can stay in the main package. I'm OK with that. > > > * Existance of -devel package means we bloat the 64bit distro with the > > > 32bit version of the main package too. > > > > Which would also be the case if the main package did > > "Provides: %name-devel = %version-%release", which it ought to do > > if it includes "devel" stuff. > > Sure, but an alternative would be to just let the main package contain > the pc file and not involve the "-devel" stuff at all. > > > > * Developers, script or packages fail because they want to use the .pc > > > file but the -devel package is not installed. > > > > Not an issue with correct "BuildRequires" and correct dependency > > chains in general. > > The argument is that its easy to forget this dependency, in for instance > the nunit example above, especially since upstream doesn't have these > subpackages. One would expect that pulling in the nunit package would > give you a working unit test system, not expecting you to have to pull > in nunit-devel. While a side issue, there are many examples of upstream releases being all inclusive. We downstream packagers are usually the ones that break it up into logical units, such as a base package and a development package. > > > I can't really think of any advantages. What exactly is the reasoning > > > behind this rule? > > > > Above all, if a .pc file specifies dependencies on other .pc files (e.g. > > in its own "Requires" line), this must be reflected in the package's > > "Requires". Else there are missing dependencies, which pile up and which > > are very tiresome for developers and packagers, who need to search for the > > packages, which provide the needed .pc files and their dependencies. > > > > So, if a .pc file influences the RPM package's dependency chain, this > > must not be ignored. > > In many cases these pc files have not pc file dependencies, and in > others they only have dependencies on pc files where the pc file also > didn't have to be in a -devel subpackage, so this isn't always a > problem. But it is something to take into consideration. If the .pc has listed requires that would in turn pull in other -devel packages, then it should be split itself into a -devel package and the requires listed as such. This prevents a normal userland install from being polluted by -devel packages just for the runtime components. -- 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: This is a digitally signed message part URL: From mharris at mharris.ca Mon Sep 4 17:35:43 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 04 Sep 2006 13:35:43 -0400 Subject: Free Software audit update In-Reply-To: <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> Message-ID: <44FC63EF.6050801@mharris.ca> Michael J. Knox wrote: > Ralf Corsepius wrote: >> To me, OpenMotif is one of the foundations of my work. Petusus has just >> kicked my work off from Fedora and rendered Fedora into a platform not >> worth to be considered for a part of my work in future. So be it :) > > No.. Petusus did no such thing. The license of OpenMotif is the problem. > OpenMotif is not compatible with Fedora's license guidelines. Its grossly > unfair to "point the finger" at a Fedora contributor for that. Fedora is > certainly not the first to drop the use of OpenMotif and port apps to use > LessTif and I doubt it will be the last. I agree with the decision to remove OpenMotif from Fedora, but what is a bit funny, is that the license was known for years to not be the best license in the world, but it was included anyway. I remember when Openmotif was added to the distro way back when and all these issues came up... but it was decided to ship it anyway. ;o) There was no legal reason it couldn't be shipped of course, but I never liked the fact it was part of the OS as it isn't really true "free software" IMHO. Over time Red Hat has made more and more of a push towards excluding software with non-free or questionable licenses (such as pine for example), and I've been glad to see that happen - but it hasn't happened across the board for whatever reasons, and I have always found that very odd. ;o) I'm not sure what the official textbook reason is for why openmotif has survived in the OS this long, but if I had to hazard a guess, it would be because there are so many 3rd party applications that use Motif _outside_ of the OS, in particular many in-house custom apps that RHL and RHEL customers have written and still use today for example. By having a working Motif implementation ship with the OS, it ensured that paying customers would have a Motif come with the OS and not have to worry about it themselves. From a business perspective that makes a fair amount of sense. One of the good things about Fedora though, is that such non-free software can be removed from Fedora Core (and/or Extras), and keep the OS itself completely "free" software, and have things like Motif maintained in separate non-free repository inside or outside Red Hat. That way if Red Hat decides it still needs to be included in RHEL5 for example, it can be put on the extra LACD or whatever. Either way though, I'm glad to _finally_ see Motif getting a fork stuck in it, and I hope that Xaw and Xt follow suit in the future just as a great symbolic gesture. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Linux fans: Check out Tym Morrison's hit new heavy metal single "Only Linux" at http://tymmorrison.com - If you would like to support this great Canadian metal artist and open source fanatic, you can buy a copy of Tym's Solo Project CD at the "Buy CD" link on his site. From mclasen at redhat.com Mon Sep 4 19:05:58 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 04 Sep 2006 15:05:58 -0400 Subject: devel packages with only one .pc file In-Reply-To: <20060904164320.39ca6ded.bugs.michael@gmx.net> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> Message-ID: <1157396758.3533.7.camel@localhost.localdomain> On Mon, 2006-09-04 at 16:43 +0200, Michael Schwendt wrote: > So, if a .pc file influences the RPM package's dependency chain, this > must not be ignored. There is no way we are going to correctly reflect all these dependencies in the rpms unless rpm picks them up automatically. Matthias From ville.skytta at iki.fi Mon Sep 4 20:07:16 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Sep 2006 23:07:16 +0300 Subject: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff) Message-ID: <1157400436.16129.134.camel@viper.local> For those who haven't noticed, FE6 will ship XEmacs 21.5.x. Additionally, I've recently realized that stuff in the xemacs-sumo package is not really built from sources; only patched *.el have been recompiled to *.elc, and the majority of upstream byte-compiled *.elc are shipped as-is. It's time for that to change, but it requires some packaging changes too. Warning: longish mail containing thinking aloud and some instructions follows. Not that it would really necessarily deserve this long an explanation, but I just wanted this dump somewhere out for reference. (Maintainers of XEmacs related packages in FE also Bcc'd in case they're not on the list.) Currently, the few bits in xemacs-sumo that are actually rebuilt are done so using the xemacs-nox package, without xemacs-nox having any dependencies to xemacs-sumo in order to avoid a build dependency loop, ie. a bootstrap problem. However, that won't work when everything is built from sources; some bits require a XEmacs that has X support to build. The main xemacs package currently has a dependency on xemacs-sumo, that has to go too in order to avoid just moving the build dep loop elsewhere. So, I'm planning to reorganize things for FE6, but exactly how to do it is still an open issue. First, one plan is to split xemacs-sumo to two. The smaller bit, xemacs-packages-base, will contain packages that upstream considers the minimal set: xemacs-base, efs, and mule-base. This will be compiled with xemacs-nox, and will be enough for people who choose to manage rest of the upstream lisp packages using XEmacs's built in tools instead of installing them from rpms. The second part, xemacs-packages, will contain practically rest of the current sumo and it will be compiled with the main X-enabled xemacs. These packages will not be called "sumo" because they no longer quite represent what upstream calls sumo either. Backwards compat Provides/Obsoletes will be there, naturally. Second part of the above plan is that the main xemacs package will no longer have a dependency to xemacs-packages (ex-sumo, due to the build dep loop above); it will have a dependency on xemacs-packages-base only. So this is what it would look like (versions dropped for brevity): xemacs: dep on xemacs-common, xemacs-packages-base, provides xemacs(bin) xemacs-nox: depends on xemacs-common, provides xemacs(bin) xemacs-common: no xemacs* deps xemacs-packages-base: depends on xemacs-common xemacs-packages: depends on xemacs-packages-base The most significant change for users and packagers is that the main xemacs package will no longer pull in all the xemacs lisp packages formerly in Sumos. Users who upgrade will get the same functionality, but ones who install from scratch, will need to install xemacs-packages in addition to xemacs to get the same lisp bundle as was earlier pulled in by just xemacs. But packagers should be aware of the changes, too. I looked into current FE packages that have some XEmacs things, and it looks like some work is required in all of them, some less, some more. This is "IMO", not a policy, and not all findings are related to the xemacs-sumo split, and some are applicable to GNU Emacs lisp packaging too. Here's a rough checklist for runtime dependencies: 1) Makes sense with full featured xemacs only, not -nox -> Requires: xemacs. Additionally, if it requires something from xemacs-packages -> Requires: xemacs-packages - as said above, that's no longer pulled in by the main xemacs package. 2) Makes sense both with full featured and -nox -> Requires: xemacs(bin). Additionally, if it requires something from xemacs-packages -> Requires: xemacs-packages. If not, but requires something from xemacs-packages-base -> Requires: xemacs-packages-base (because -nox does not and can't have a dep on xemacs-packages-base - that'd result in a build dep loop). 3) Ships *.elc (IMO everything that is not a simple init-like file dropped to site-start.d should be byte-compiled into *.elc during build!) -> Requires: $xemacs >= $version (versioned!), where $xemacs is xemacs or xemacs(bin) determined by 1) and 2) above, and $version is the version of xemacs (or -nox, see build stuff below) that was used to compile the *.elc. An example how to take care of the version part will be included in the upcoming xemacs-packages and xemacs-packages-base packages. The version is important because there are no backward compatibility guarantees for *.elc. One specific example is that Requires: xemacs-common is most likely a packaging bug and should be changed to (a versioned) Requires: xemacs or Requires: xemacs(bin) as appropriate. Build time dependencies: a) Can be built with xemacs-nox -> BuildRequires: xemacs-nox. If also requires something from xemacs-packages to build -> BuildRequires: xemacs-packages. If not, but requires something from xemacs-packages-base to build -> BuildRequires: xemacs-packages-base. b) Can not be built with xemacs-nox, requires full featured xemacs to build -> BuildRequires: xemacs. If additionally requires something from xemacs-packages to build -> BuildRequires: xemacs-packages. For simplicity, b) could be applied to all xemacs lisp packages, but deciding between a) or b) as applicable allows for a more optimized/minimized set of build dependencies. Open issues: - Is xemacs(bin) is a good name for the Provides provided by xemacs and xemacs-nox? One alternative would be to rename the current main package to let's say xemacs-x, leave xemacs-nox as is, and have xemacs-x and xemacs-nox simply provide "xemacs" instead. This would however be slightly less backwards compatible in the "install from scratch" case than the xemacs(bin) approach. - Would it be better to fold all the sumo/lisp package things back to the main xemacs source rpm? This would allow making some things a fair bit simpler, and would also make it possible to drop xemacs-nox altogether; as long as emacs-nox exists, I'm not sure if anyone really needs it. The drawbacks of the bundling would be kind of gratuitously arch-specific lisp subpackages (OTOH in rpm arch only, the content would continue to be arch independent) and that updates for the whole shebang would need to be shipped all at once. Hm, strange. Having written the last paragraph, I'm starting to lean towards it ;) (including dropping xemacs-nox). Comments welcome, either on or off list - I'd like to have a firm plan how to proceed at end of this week. From petersen at redhat.com Tue Sep 5 01:41:47 2006 From: petersen at redhat.com (Jens Petersen) Date: Tue, 05 Sep 2006 10:41:47 +0900 Subject: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff) In-Reply-To: <1157400436.16129.134.camel@viper.local> References: <1157400436.16129.134.camel@viper.local> Message-ID: <44FCD5DB.4030505@redhat.com> Ville Skytt? wrote: > The most significant change for users and packagers is that the main > xemacs package will no longer pull in all the xemacs lisp packages > formerly in Sumos. Users who upgrade will get the same functionality, > but ones who install from scratch, will need to install xemacs-packages > in addition to xemacs to get the same lisp bundle as was earlier pulled > in by just xemacs. But packagers should be aware of the changes, too. > OK. Sounds find to me - probably most users don't need every package in xemacs-sumo anyway. > - Would it be better to fold all the sumo/lisp package things back to > the main xemacs source rpm? This would allow making some things a fair > bit simpler, and would also make it possible to drop xemacs-nox > altogether; as long as emacs-nox exists, I'm not sure if anyone really > needs it. The drawbacks of the bundling would be kind of gratuitously > arch-specific lisp subpackages (OTOH in rpm arch only, the content would > continue to be arch independent) and that updates for the whole shebang > would need to be shipped all at once. > IMHO keeping xemacs-packages separate is better and more conducive to pushing updates since they have tended to be released more often than xemacs. Personally I like to minimize downloading bits that are essentially unchanged from what is already installed. Jens From jkeating at redhat.com Tue Sep 5 03:25:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 23:25:01 -0400 Subject: Freeze tomorrow at noon Message-ID: <1157426701.2047.27.camel@ender> So we're going to freeze the tree for Test3 tomorrow around noon eastern daylight time (1600 UTC). We will remain frozen for the rest of the release period, pulling important bug fixes in from -HEAD. -- Jesse Keating Release Engineer: Fedora -------------- 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 Tue Sep 5 04:29:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 06:29:06 +0200 Subject: Free Software audit update In-Reply-To: <44FC63EF.6050801@mharris.ca> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> Message-ID: <1157430546.4654.16.camel@mccallum.corsepiu.local> On Mon, 2006-09-04 at 13:35 -0400, Mike A. Harris wrote: > Michael J. Knox wrote: > > Ralf Corsepius wrote: > >> To me, OpenMotif is one of the foundations of my work. Petusus has just > >> kicked my work off from Fedora and rendered Fedora into a platform not > >> worth to be considered for a part of my work in future. So be it :) > > > > No.. Petusus did no such thing. The license of OpenMotif is the problem. > > OpenMotif is not compatible with Fedora's license guidelines. Its grossly > > unfair to "point the finger" at a Fedora contributor for that. I could not disagree more, but I am not going to reiterate over this on this list again. > > Fedora is > > certainly not the first to drop the use of OpenMotif and port apps to use > > LessTif and I doubt it will be the last. > > I agree with the decision to remove OpenMotif from Fedora, but > what is a bit funny, is that the license was known for years to > not be the best license in the world, but it was included anyway. Yes, ... > I remember when Openmotif was added to the distro way back when > and all these issues came up... but it was decided to ship it > anyway. ;o) Yes, lesstif had not been much more but crap then. > There was no legal reason it couldn't be shipped of course, but > I never liked the fact it was part of the OS as it isn't really > true "free software" IMHO. This is the actual point: OpenMotif doesn't fit into the "definition of OSS" as RH dictated it to Fedora. Face it - RH is not alone on this planet, their "religion" is not the only "belief" and you can't force everybody to YOUR belief. > Either way though, I'm glad to _finally_ see Motif getting a fork > stuck in it, and I hope that Xaw and Xt follow suit in the future > just as a great symbolic gesture. ;o) Why can't you @redhat.com-guys stop agitating against what doesn't fit into your "small-town world" and let the rest of the world live in peace? Ralf From dennis at ausil.us Tue Sep 5 04:44:32 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 4 Sep 2006 23:44:32 -0500 Subject: Free Software audit update In-Reply-To: <1157430546.4654.16.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> Message-ID: <200609042344.32839.dennis@ausil.us> On Monday 04 September 2006 11:29 pm, Ralf Corsepius wrote: > On Mon, 2006-09-04 at 13:35 -0400, Mike A. Harris wrote: > > Michael J. Knox wrote: > > > Ralf Corsepius wrote: > > >> To me, OpenMotif is one of the foundations of my work. Petusus has > > >> just kicked my work off from Fedora and rendered Fedora into a > > >> platform not worth to be considered for a part of my work in future. > > >> So be it :) > > > > > > No.. Petusus did no such thing. The license of OpenMotif is the > > > problem. OpenMotif is not compatible with Fedora's license guidelines. > > > Its grossly unfair to "point the finger" at a Fedora contributor for > > > that. > > I could not disagree more, but I am not going to reiterate over this on > this list again. Ralf you could blame Spot for doing the audit that turned up the need to remove OpenMotif (Spot Thank you very much for doing the audit). you could blame the FPB for asking him to do the audit. you could blame lots of people, hell i probably caused you pain on this. but really it was not Petusus that got the ball rolling he just kicked the ball into the net to get the goal so we all win the game :D > > There was no legal reason it couldn't be shipped of course, but > > I never liked the fact it was part of the OS as it isn't really > > true "free software" IMHO. > > This is the actual point: OpenMotif doesn't fit into the "definition of > OSS" as RH dictated it to Fedora. the definition for OSS has been taken from OSI and FSF not RH. If you feel strongly enugh get the OpenMotif License changed or get one of those bodies to say it is Open Source. > Face it - RH is not alone on this planet, their "religion" is not the > only "belief" and you can't force everybody to YOUR belief. > > > Either way though, I'm glad to _finally_ see Motif getting a fork > > stuck in it, and I hope that Xaw and Xt follow suit in the future > > just as a great symbolic gesture. ;o) I personally am glad to see a truly OSS product going in > Why can't you @redhat.com-guys stop agitating against what > doesn't fit into your "small-town world" and let the rest of the world > live in peace? Ralf Mike is no longer a Red Hate employee. so this is grossly unfair. -- Dennis Gilmore, RHCE Proud Australian From peter at thecodergeek.com Tue Sep 5 04:47:46 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 04 Sep 2006 21:47:46 -0700 Subject: Free Software audit update In-Reply-To: <1157430546.4654.16.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> Message-ID: <44FD0172.9020104@thecodergeek.com> Ralf Corsepius wrote: > Face it - RH is not alone on this planet, their "religion" is not the > only "belief" and you can't force everybody to YOUR belief. Ralf: No one is forcing you to stay within the confines of Fedora's strict licensing policies. You could always maintain your own local copy of the package or grab it from an alternative repository, for example. > Why can't you @redhat.com-guys stop agitating against what > doesn't fit into your "small-town world" and let the rest of the world > live in peace? They are. They are ensuring that their userbase does not have to worry about any weird licensing issues if they want to build on or redistribute the software. I, for one, call that a nice peace. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Tue Sep 5 04:49:43 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 04 Sep 2006 21:49:43 -0700 Subject: Free Software audit update In-Reply-To: <200609042344.32839.dennis@ausil.us> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <200609042344.32839.dennis@ausil.us> Message-ID: <44FD01E7.2020008@thecodergeek.com> Dennis Gilmore wrote: > Ralf Mike is no longer a Red Hate employee. so this is grossly unfair. While you may disagree with the actions taken, please discuss the issue in a respectful manner. Red-herring like "Red Hate" or the like are grossly unneeded. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From michael at knox.net.nz Tue Sep 5 05:37:54 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 05 Sep 2006 17:37:54 +1200 Subject: Free Software audit update In-Reply-To: <44FD0172.9020104@thecodergeek.com> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <44FD0172.9020104@thecodergeek.com> Message-ID: <44FD0D32.5070401@knox.net.nz> Peter Gordon wrote: > Ralf Corsepius wrote: >> Face it - RH is not alone on this planet, their "religion" is not the >> only "belief" and you can't force everybody to YOUR belief. > Ralf: No one is forcing you to stay within the confines of Fedora's strict > licensing policies. You could always maintain your own local copy of the > package or grab it from an alternative repository, for example. This is what I do myself for packages that do not fall with Fedora's legal guidelines. Works well :) Michael From rc040203 at freenet.de Tue Sep 5 05:51:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 07:51:05 +0200 Subject: Free Software audit update In-Reply-To: <44FD0D32.5070401@knox.net.nz> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <44FD0172.9020104@thecodergeek.com> <44FD0D32.5070401@knox.net.nz> Message-ID: <1157435465.4654.43.camel@mccallum.corsepiu.local> On Tue, 2006-09-05 at 17:37 +1200, Michael J. Knox wrote: > Peter Gordon wrote: > > Ralf Corsepius wrote: > >> Face it - RH is not alone on this planet, their "religion" is not the > >> only "belief" and you can't force everybody to YOUR belief. > > Ralf: No one is forcing you to stay within the confines of Fedora's strict > > licensing policies. You could always maintain your own local copy of the > > package or grab it from an alternative repository, for example. > > This is what I do myself for packages that do not fall with Fedora's > legal guidelines. Works well :) That's what I'll do, but Pertusus' packaging of lesstif is such kind of bad, this won't be easy, in this particular case. More generally speaking, the fact people have to build packages on their own at all, simply means "Fedora doesn't fit into their needs". As I said earlier in this thread, initially I had been hoping "Fedora would evolve into a better distro better meeting my demands" ... now I am facing the contrary. Fedora is regressing. Ralf From caillon at redhat.com Tue Sep 5 06:43:59 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Sep 2006 02:43:59 -0400 Subject: devel packages with only one .pc file In-Reply-To: <20060904164320.39ca6ded.bugs.michael@gmx.net> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> Message-ID: <44FD1CAF.4000508@redhat.com> Michael Schwendt wrote: > On Mon, 04 Sep 2006 15:11:26 +0200, Alexander Larsson wrote: > >> I've recently got several bugs against package involving basically >> splitting out only one pkg-config file into a -devel package, > > Examples, please. gecko-sharp2-devel has one tiny .pc file. That is it. Rather silly, but I have no time to argue with this silliness. Cheers to you Alex, for raising this issue. From skasal at redhat.com Tue Sep 5 07:41:16 2006 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 5 Sep 2006 09:41:16 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157389333.2047.12.camel@ender> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> Message-ID: <20060905074116.GA12923@camelia.ucw.cz> Hello, though I was not aware of the rule ``.pc to -devel,'' I happened to reinvent it a few weeks ago, for my java-gnome packages. And yes, dependencies are the main reason for these -devel packages, even if they do not contain anything but a tiny file. For example, libglade-java-devel requires libglade2-devel, which brings all the glib-devel baggage. If the base libglade-java required libglade2-devel, then all the machines which want only runtime would have the whole -devel of the whole Gnome. This is not acceptable. Stepan Kasal From rc040203 at freenet.de Tue Sep 5 07:52:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 09:52:05 +0200 Subject: Free Software audit update In-Reply-To: <44FD01E7.2020008@thecodergeek.com> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <200609042344.32839.dennis@ausil.us> <44FD01E7.2020008@thecodergeek.com> Message-ID: <1157442726.4654.65.camel@mccallum.corsepiu.local> On Mon, 2006-09-04 at 21:49 -0700, Peter Gordon wrote: > Dennis Gilmore wrote: > > Ralf Mike is no longer a Red Hate employee. I wasn't aware about this. > While you may disagree with the actions taken, please discuss the issue in > a respectful manner. Red-herring like "Red Hate" or the like are grossly > unneeded. ... this wasn't meant to attack individuals at RH. I meant to question the attitude being exposed by RH (the enterprise), the people representing it (@redhat.com) and RH's role in Fedora. IMO, they are exposing a pretty narrow-minded view and attitude. Instead, OpenSource needs open minds and open systems, not protectionism (OSI). Ralf From mharris at mharris.ca Tue Sep 5 09:28:16 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 05 Sep 2006 05:28:16 -0400 Subject: Free Software audit update In-Reply-To: <1157430546.4654.16.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> Message-ID: <44FD4330.4090101@mharris.ca> Ralf Corsepius wrote: > On Mon, 2006-09-04 at 13:35 -0400, Mike A. Harris wrote: >> Michael J. Knox wrote: >>> Ralf Corsepius wrote: >>>> To me, OpenMotif is one of the foundations of my work. Petusus has just >>>> kicked my work off from Fedora and rendered Fedora into a platform not >>>> worth to be considered for a part of my work in future. So be it :) >>> No.. Petusus did no such thing. The license of OpenMotif is the problem. >>> OpenMotif is not compatible with Fedora's license guidelines. Its grossly >>> unfair to "point the finger" at a Fedora contributor for that. > I could not disagree more, but I am not going to reiterate over this on > this list again. To be clear, I didn't write any of the above. Your comment is in response to one of the other persons, but misattributed to me. >> There was no legal reason it couldn't be shipped of course, but >> I never liked the fact it was part of the OS as it isn't really >> true "free software" IMHO. > This is the actual point: OpenMotif doesn't fit into the "definition of > OSS" as RH dictated it to Fedora. Red Hat more or less uses the OSI definition of free software, but there have been some historical exceptions, some of them intentional, while others simply due to nobody doing an exhaustive audit of all packages - until now... > Face it - RH is not alone on this planet, their "religion" is not the > only "belief" and you can't force everybody to YOUR belief. I'm not a religious zealot, so I wouldn't ever attempt to force anyone to believe anything. >> Either way though, I'm glad to _finally_ see Motif getting a fork >> stuck in it, and I hope that Xaw and Xt follow suit in the future >> just as a great symbolic gesture. ;o) > Why can't you @redhat.com-guys stop agitating against what > doesn't fit into your "small-town world" and let the rest of the world > live in peace? Well um... for starters... I'm not a @redhat.com guy. How about this: Why can't people like you allow other people to express their opinions without taking a holier than thou approach which is ironically the opposite of what you yourself are trying to shove down my throat. You don't have to like my opinion, nor to read it if you don't want to. But I'll express it if I choose to do so, which I have. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Linux fans: Check out Tym Morrison's hit new heavy metal single "Only Linux" at http://tymmorrison.com - If you would like to support this great Canadian metal artist and open source fanatic, you can buy a copy of Tym's Solo Project CD at the "Buy CD" link on his site. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Sep 5 09:50:32 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 5 Sep 2006 11:50:32 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157396758.3533.7.camel@localhost.localdomain> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157396758.3533.7.camel@localhost.localdomain> Message-ID: <20060905115032.7bef8139@python2> Matthias Clasen wrote : > On Mon, 2006-09-04 at 16:43 +0200, Michael Schwendt wrote: > > > So, if a .pc file influences the RPM package's dependency chain, this > > must not be ignored. > > There is no way we are going to correctly reflect all these dependencies > in the rpms unless rpm picks them up automatically. Automatic requirements generated from the *.pc files contained in a package is something that recent rpm versions have, but not the version still shipped in FC... a feature I really miss in FC indeed. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2611.fc6 Load : 0.46 0.45 0.36 From alexl at redhat.com Tue Sep 5 10:43:59 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 05 Sep 2006 12:43:59 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157389333.2047.12.camel@ender> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> Message-ID: <1157453039.4016.142.camel@greebo> On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: > On Mon, 2006-09-04 at 17:42 +0200, Alexander Larsson wrote: > > A typical example is gtk-sharp2-devel. It contains only four pc files. > > There are no headers or anything, because for mono you don't need > > anything but the dll. > > > > Another example is in mono. Here the "mono-nunit" subpackage contains a > > similar pkg-config file. This case is even weirder, because nunit (being > > a framework for developing unit tests) is clearly already a development > > application, and you wouldn't really install it if you weren't already > > doing development. > > Perhaps in the case of mono, where the main package has no difference > between the runtime and the development files (one in the same) then > the .pc file can stay in the main package. I'm OK with that. So, can we change the packaging guidelines to say this? (Otherwise I'll be flooded with more bug reports.) > > In many cases these pc files have not pc file dependencies, and in > > others they only have dependencies on pc files where the pc file also > > didn't have to be in a -devel subpackage, so this isn't always a > > problem. > > But it is something to take into consideration. If the .pc has listed > requires that would in turn pull in other -devel packages, then it > should be split itself into a -devel package and the requires listed as > such. This prevents a normal userland install from being polluted by > -devel packages just for the runtime components. Sure. And in the majority of cases we really should have the .pc file in a devel package. Its just that in some cases there really is no need for it, and its not without negative consequenses. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy overambitious waffle chef She's a mistrustful cigar-chomping soap star from beyond the grave. They fight crime! From rc040203 at freenet.de Tue Sep 5 11:27:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 13:27:39 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157453039.4016.142.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> Message-ID: <1157455659.4654.98.camel@mccallum.corsepiu.local> On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: > > On Mon, 2006-09-04 at 17:42 +0200, Alexander Larsson wrote: > > > A typical example is gtk-sharp2-devel. It contains only four pc files. > > > There are no headers or anything, because for mono you don't need > > > anything but the dll. > > > > > > Another example is in mono. Here the "mono-nunit" subpackage contains a > > > similar pkg-config file. This case is even weirder, because nunit (being > > > a framework for developing unit tests) is clearly already a development > > > application, and you wouldn't really install it if you weren't already > > > doing development. > > > > Perhaps in the case of mono, where the main package has no difference > > between the runtime and the development files (one in the same) then > > the .pc file can stay in the main package. I'm OK with that. Should this proposal enter the Packaging Committee, I'll vote against it. > > > In many cases these pc files have not pc file dependencies, and in > > > others they only have dependencies on pc files where the pc file also > > > didn't have to be in a -devel subpackage, so this isn't always a > > > problem. > > > > But it is something to take into consideration. If the .pc has listed > > requires that would in turn pull in other -devel packages, then it > > should be split itself into a -devel package and the requires listed as > > such. This prevents a normal userland install from being polluted by > > -devel packages just for the runtime components. > > Sure. And in the majority of cases we really should have the .pc file in > a devel package. Its just that in some cases there really is no need for > it, There is one: Installing the run-time environment will pull in devel files. > and its not without negative consequenses. The more I think about it, I feel you are simply facing a "singular case" (devel collapses into one file), which probably originates from "underdeveloped/underequipped code". Just add some devel-docs and/or some further package deps and I'd expect you to experience your *devel package will consist of more files and/or installing it will pull in a larger infrastructure. Ralf From dennis at ausil.us Tue Sep 5 11:58:06 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 5 Sep 2006 06:58:06 -0500 Subject: Free Software audit update In-Reply-To: <44FD01E7.2020008@thecodergeek.com> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <200609042344.32839.dennis@ausil.us> <44FD01E7.2020008@thecodergeek.com> Message-ID: <200609050658.06658.dennis@ausil.us> On Monday 04 September 2006 11:49 pm, Peter Gordon wrote: > Dennis Gilmore wrote: > > Ralf Mike is no longer a Red Hate employee. so this is grossly unfair. > > While you may disagree with the actions taken, please discuss the issue in > a respectful manner. Red-herring like "Red Hate" or the like are grossly > unneeded. Thanks. Peter im sorry that was a typo -- Dennis Gilmore, RHCE Proud Australian From laurent.rineau__fedora_extras at normalesup.org Tue Sep 5 12:14:41 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Tue, 5 Sep 2006 14:14:41 +0200 Subject: Free Software audit update In-Reply-To: <1157017501.27813.69.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060831071934.GD2455@free.fr> <1157017501.27813.69.camel@mccallum.corsepiu.local> Message-ID: <200609051414.41191@rineau.schtroumpfette> On Thursday 31 August 2006 11:45, Ralf Corsepius wrote: > > > You should have packaged lesstif in such a way both openmotif-devel and > > > lesstif-devel can be installed in parallel. > > > > I would be happy to achieve that, but how? > > The headers and the .so > > conflict. > > Different installation paths, different rpaths. Ok for different installation paths, but RPATH should be avoided, in Fedora, AFAIK. Actually, if only the -devel subpackage of lesstif and openmotif are in conflicts, it means, i think, that their libraries have different SONAME. So only "-L" should be needed to link with the one that is not installed in default libraries, in that case:?both installation paths could be in /etc/ld.so.conf.d/. From rdieter at math.unl.edu Tue Sep 5 12:22:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Sep 2006 07:22:49 -0500 Subject: Free Software audit update In-Reply-To: <200609051414.41191@rineau.schtroumpfette> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <20060831071934.GD2455@free.fr> <1157017501.27813.69.camel@mccallum.corsepiu.local> <200609051414.41191@rineau.schtroumpfette> Message-ID: <44FD6C19.7000809@math.unl.edu> Laurent Rineau wrote: > On Thursday 31 August 2006 11:45, Ralf Corsepius wrote: >>>> You should have packaged lesstif in such a way both openmotif-devel and >>>> lesstif-devel can be installed in parallel. >>> I would be happy to achieve that, but how? > >>> The headers and the .so >>> conflict. >> Different installation paths, different rpaths. > > Ok for different installation paths, but RPATH should be avoided, in Fedora, > AFAIK. > > Actually, if only the -devel subpackage of lesstif and openmotif are in > conflicts, it means, i think, that their libraries have different SONAME. So > only "-L" should be needed to link with the one that is not installed in > default libraries, in that case: both installation paths could be > in /etc/ld.so.conf.d/. IMO, it's just not worth it. -devel conflicts are acceptable, if it means avoiding the pain induced by the hacks required to workaround it (ie, non-standard installation paths, -rpath, ld.so.conf.d, ...) -- Rex From jkeating at redhat.com Tue Sep 5 12:50:44 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Sep 2006 08:50:44 -0400 Subject: Free Software audit update In-Reply-To: <1157442726.4654.65.camel@mccallum.corsepiu.local> References: <1156954509.32717.188.camel@dhcp-32-122.ord.redhat.com> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <200609042344.32839.dennis@ausil.us> <44FD01E7.2020008@thecodergeek.com> <1157442726.4654.65.camel@mccallum.corsepiu.local> Message-ID: <1157460644.2047.31.camel@ender> On Tue, 2006-09-05 at 09:52 +0200, Ralf Corsepius wrote: > IMO, they are exposing a pretty narrow-minded view and attitude. > Instead, OpenSource needs open minds and open systems, not > protectionism > (OSI). Ralf, the board asked for an audit and the board decided to take action based on that audit. Red Hat had to face some hard decisions due to that audit and action. This was not a Red Hat mandated thing, this was the board's decision which has many non Red Hat folks. Red Hat would probably have gone on blissfully ignorant to the licensing issues they had in their packages. So while its easy to blame the big Red Hat target, the more appropriate place would be the board which has community members and acts on behalf of the community. -- Jesse Keating Release Engineer: Fedora -------------- 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 Sep 5 12:56:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Sep 2006 08:56:10 -0400 Subject: devel packages with only one .pc file In-Reply-To: <1157453039.4016.142.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> Message-ID: <1157460970.2047.35.camel@ender> On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > > Perhaps in the case of mono, where the main package has no > difference > > between the runtime and the development files (one in the same) then > > the .pc file can stay in the main package. I'm OK with that. > > So, can we change the packaging guidelines to say this? (Otherwise > I'll > be flooded with more bug reports.) You are positive that your .pc files don't list any further software requirements that might be development in nature? If they did, this rule wouldn't apply. I would think that it would have to be something like this: If A) your package has no distinction between runtime and development libraries (example mono .dll files), and B) your .pc file lists no other development requirements, than your .pc file can go in the main package and not a sub -devel package. -- Jesse Keating Release Engineer: Fedora -------------- 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 alexl at redhat.com Tue Sep 5 13:15:59 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 05 Sep 2006 15:15:59 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157460970.2047.35.camel@ender> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> Message-ID: <1157462159.4016.147.camel@greebo> On Tue, 2006-09-05 at 08:56 -0400, Jesse Keating wrote: > On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > > > Perhaps in the case of mono, where the main package has no > > difference > > > between the runtime and the development files (one in the same) then > > > the .pc file can stay in the main package. I'm OK with that. > > > > So, can we change the packaging guidelines to say this? (Otherwise > > I'll > > be flooded with more bug reports.) > > You are positive that your .pc files don't list any further software > requirements that might be development in nature? If they did, this > rule wouldn't apply. I would think that it would have to be something > like this: > > If A) your package has no distinction between runtime and development > libraries (example mono .dll files), and B) your .pc file lists no other > development requirements, than your .pc file can go in the main package > and not a sub -devel package. What if it depends on another package that satisfies this? (I.E. that has the pc file in the main package) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an immortal alcoholic gangster who knows the secret of the alien invasion. She's a manipulative paranoid widow prone to fits of savage, blood-crazed rage. They fight crime! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Sep 5 13:19:15 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 5 Sep 2006 15:19:15 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157460970.2047.35.camel@ender> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> Message-ID: <20060905151915.0b78d40c@python2> Jesse Keating wrote : > On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > > > Perhaps in the case of mono, where the main package has no > > difference > > > between the runtime and the development files (one in the same) then > > > the .pc file can stay in the main package. I'm OK with that. > > > > So, can we change the packaging guidelines to say this? (Otherwise > > I'll > > be flooded with more bug reports.) > > You are positive that your .pc files don't list any further software > requirements that might be development in nature? If they did, this > rule wouldn't apply. I would think that it would have to be something > like this: > > If A) your package has no distinction between runtime and development > libraries (example mono .dll files), and B) your .pc file lists no other > development requirements, than your .pc file can go in the main package > and not a sub -devel package. Fine by me, but I'd go one step further : ... But you will then need to add this virtual provides to the main package : "Provides: %{name}-devel = %{version}-%{release}". That way other software requiring the package to build can simply buildrequire thisname-devel and not worry about later changes that would require a "real" -devel sub-package to be split out. Last question remaining is if we want "Requires: pkgconfig" in such packages? I don't, but pulling in pkgconfig is what would make most sense... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2617.2.1.fc6 Load : 0.25 0.55 0.65 From nicolas.mailhot at laposte.net Tue Sep 5 13:19:48 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Sep 2006 15:19:48 +0200 (CEST) Subject: devel packages with only one .pc file In-Reply-To: <1157453039.4016.142.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> Message-ID: <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> Le Mar 5 septembre 2006 12:43, Alexander Larsson a ?crit : > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: >> Perhaps in the case of mono, where the main package has no difference >> between the runtime and the development files (one in the same) then >> the .pc file can stay in the main package. I'm OK with that. > > So, can we change the packaging guidelines to say this? (Otherwise I'll > be flooded with more bug reports.) Even if a language does not distinguish between runtime and build files, you may still have to pull stuff used only for building (compiler, tools for %check, i18n, etc) -- Nicolas Mailhot From jkeating at redhat.com Tue Sep 5 13:21:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Sep 2006 09:21:22 -0400 Subject: devel packages with only one .pc file In-Reply-To: <1157462159.4016.147.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> <1157462159.4016.147.camel@greebo> Message-ID: <1157462482.8823.0.camel@ender> On Tue, 2006-09-05 at 15:15 +0200, Alexander Larsson wrote: > > What if it depends on another package that satisfies this? (I.E. that > has the pc file in the main package) Those packages would have to meet the same criteria. However if they don't and somewhere down the line you'd be pulling in -devel package trees, then this can't happen. In narrow install spaces we absolutely cannot bring in -devel dep chains just because of lazy packaging. -- Jesse Keating Release Engineer: Fedora -------------- 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 alexl at redhat.com Tue Sep 5 13:22:48 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 05 Sep 2006 15:22:48 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157460970.2047.35.camel@ender> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> Message-ID: <1157462569.4016.153.camel@greebo> On Tue, 2006-09-05 at 08:56 -0400, Jesse Keating wrote: > On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > > > Perhaps in the case of mono, where the main package has no > > difference > > > between the runtime and the development files (one in the same) then > > > the .pc file can stay in the main package. I'm OK with that. > > > > So, can we change the packaging guidelines to say this? (Otherwise > > I'll > > be flooded with more bug reports.) > > You are positive that your .pc files don't list any further software > requirements that might be development in nature? If they did, this > rule wouldn't apply. I guess its possible that gtk-sharp2 will get devel docs in the future, which would end up in a -devel package. However, for the case of mono-nunit things are different. I don't think putting the docs for nunit in a nunit-devel package. That would be similar to putting the docs for binutils in a binutils-devel package. (Of course, the binutils package has .h/.so/.a and doc files in the main package.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an unconventional misogynist cowboy who must take medication to keep him sane. She's a pregnant gold-digging widow looking for love in all the wrong places. They fight crime! From jkeating at redhat.com Tue Sep 5 13:22:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Sep 2006 09:22:21 -0400 Subject: devel packages with only one .pc file In-Reply-To: <20060905151915.0b78d40c@python2> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> <20060905151915.0b78d40c@python2> Message-ID: <1157462541.8823.2.camel@ender> On Tue, 2006-09-05 at 15:19 +0200, Matthias Saou wrote: > Last question remaining is if we want "Requires: pkgconfig" in such > packages? I don't, but pulling in pkgconfig is what would make most > sense... Yes, because of the directory ownership rule. If you're dropping a file in the pkgconfig/ dir, you need pkgconfig there to own that dir so you don't end up owning it yourself. -- Jesse Keating Release Engineer: Fedora -------------- 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 alexl at redhat.com Tue Sep 5 13:25:21 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 05 Sep 2006 15:25:21 +0200 Subject: devel packages with only one .pc file In-Reply-To: <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> Message-ID: <1157462721.4016.156.camel@greebo> On Tue, 2006-09-05 at 15:19 +0200, Nicolas Mailhot wrote: > Le Mar 5 septembre 2006 12:43, Alexander Larsson a ?crit : > > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: > > >> Perhaps in the case of mono, where the main package has no difference > >> between the runtime and the development files (one in the same) then > >> the .pc file can stay in the main package. I'm OK with that. > > > > So, can we change the packaging guidelines to say this? (Otherwise I'll > > be flooded with more bug reports.) > > Even if a language does not distinguish between runtime and build files, > you may still have to pull stuff used only for building (compiler, tools > for %check, i18n, etc) We don't require gcc or binutils in every package that includes a .pc file, do we? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an unconventional day-dreaming boxer living undercover at Ringling Bros. Circus. She's a green-fingered impetuous angel from beyond the grave. They fight crime! From rc040203 at freenet.de Tue Sep 5 13:30:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 15:30:36 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157462569.4016.153.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> <1157462569.4016.153.camel@greebo> Message-ID: <1157463036.4654.160.camel@mccallum.corsepiu.local> On Tue, 2006-09-05 at 15:22 +0200, Alexander Larsson wrote: > However, for the case of mono-nunit things are different. I don't think > putting the docs for nunit in a nunit-devel package. That would be > similar to putting the docs for binutils in a binutils-devel package. > (Of course, the binutils package has .h/.so/.a and doc files in the main > package.) Packaging bug - Rarely anybody really needs the *.h/*.a/*.so from binutils. Ralf From jwboyer at jdub.homelinux.org Tue Sep 5 13:45:52 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 05 Sep 2006 08:45:52 -0500 Subject: devel packages with only one .pc file In-Reply-To: <1157462721.4016.156.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> Message-ID: <1157463952.6098.16.camel@zod.rchland.ibm.com> On Tue, 2006-09-05 at 15:25 +0200, Alexander Larsson wrote: > On Tue, 2006-09-05 at 15:19 +0200, Nicolas Mailhot wrote: > > Le Mar 5 septembre 2006 12:43, Alexander Larsson a ?crit : > > > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: > > > > >> Perhaps in the case of mono, where the main package has no difference > > >> between the runtime and the development files (one in the same) then > > >> the .pc file can stay in the main package. I'm OK with that. > > > > > > So, can we change the packaging guidelines to say this? (Otherwise I'll > > > be flooded with more bug reports.) > > > > Even if a language does not distinguish between runtime and build files, > > you may still have to pull stuff used only for building (compiler, tools > > for %check, i18n, etc) > > We don't require gcc or binutils in every package that includes a .pc > file, do we? You all realize that the amount of time spent on this thread so far is about 10x greater than it would have been to just fix the packages to match the policy, right? josh From jkeating at redhat.com Tue Sep 5 14:04:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Sep 2006 10:04:28 -0400 Subject: devel packages with only one .pc file In-Reply-To: <1157463952.6098.16.camel@zod.rchland.ibm.com> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> <1157463952.6098.16.camel@zod.rchland.ibm.com> Message-ID: <1157465068.8823.13.camel@ender> On Tue, 2006-09-05 at 08:45 -0500, Josh Boyer wrote: > You all realize that the amount of time spent on this thread so far is > about 10x greater than it would have been to just fix the packages to > match the policy, right? But time spent to understand the policy and the reasoning behind it is priceless compared to just blindly following writ and not knowing why other than 'because it says to...' I encourage anybody that doesn't understand why we set up policy or disagrees with policy to bring it up and discuss it. It is better to understand or even shed new light on a policy decision that may not have been the best decision. -- Jesse Keating Release Engineer: Fedora -------------- 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 alexl at redhat.com Tue Sep 5 14:07:25 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 05 Sep 2006 16:07:25 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157463952.6098.16.camel@zod.rchland.ibm.com> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> <1157463952.6098.16.camel@zod.rchland.ibm.com> Message-ID: <1157465246.4016.158.camel@greebo> On Tue, 2006-09-05 at 08:45 -0500, Josh Boyer wrote: > On Tue, 2006-09-05 at 15:25 +0200, Alexander Larsson wrote: > > On Tue, 2006-09-05 at 15:19 +0200, Nicolas Mailhot wrote: > > > Le Mar 5 septembre 2006 12:43, Alexander Larsson a ?crit : > > > > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: > > > > > > >> Perhaps in the case of mono, where the main package has no difference > > > >> between the runtime and the development files (one in the same) then > > > >> the .pc file can stay in the main package. I'm OK with that. > > > > > > > > So, can we change the packaging guidelines to say this? (Otherwise I'll > > > > be flooded with more bug reports.) > > > > > > Even if a language does not distinguish between runtime and build files, > > > you may still have to pull stuff used only for building (compiler, tools > > > for %check, i18n, etc) > > > > We don't require gcc or binutils in every package that includes a .pc > > file, do we? > > You all realize that the amount of time spent on this thread so far is > about 10x greater than it would have been to just fix the packages to > match the policy, right? Even less time would have been spent if the already well functioning packages didn't get bugs filed against them and lots of imho unnecessary churn. That doesn't make it right. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an immortal neurotic master criminal with a mysterious suitcase handcuffed to his arm. She's a time-travelling impetuous mermaid on her way to prison for a murder she didn't commit. They fight crime! From nicolas.mailhot at laposte.net Tue Sep 5 14:18:19 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Sep 2006 16:18:19 +0200 (CEST) Subject: devel packages with only one .pc file In-Reply-To: <1157462721.4016.156.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> Message-ID: <6925.192.54.193.51.1157465899.squirrel@rousalka.dyndns.org> Le Mar 5 septembre 2006 15:25, Alexander Larsson a ?crit : > On Tue, 2006-09-05 at 15:19 +0200, Nicolas Mailhot wrote: >> Le Mar 5 septembre 2006 12:43, Alexander Larsson a ?crit : >> > On Mon, 2006-09-04 at 13:02 -0400, Jesse Keating wrote: >> >> >> Perhaps in the case of mono, where the main package has no difference >> >> between the runtime and the development files (one in the same) then >> >> the .pc file can stay in the main package. I'm OK with that. >> > >> > So, can we change the packaging guidelines to say this? (Otherwise >> I'll >> > be flooded with more bug reports.) >> >> Even if a language does not distinguish between runtime and build files, >> you may still have to pull stuff used only for building (compiler, tools >> for %check, i18n, etc) > > We don't require gcc or binutils in every package that includes a .pc > file, do we? That's only because those are the common ones. Make replacements, libs used for unit tests, etc... are not covered by the default package set. -- Nicolas Mailhot From jkeating at redhat.com Tue Sep 5 15:38:15 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Sep 2006 11:38:15 -0400 Subject: gtk-sharp removed from Core 6 Message-ID: <200609051138.19789.jkeating@redhat.com> In favor of gtk-sharp2. We believe all core apps have been ported to gtk-sharp2, and most of the extras ones too. paul at all-the-johnsons.co.uk will be submitting it to extras just in case. -- 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 jkeating at redhat.com Tue Sep 5 15:39:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Sep 2006 11:39:21 -0400 Subject: libxml no longer needed In-Reply-To: <1157150119.6577.50.camel@ender> References: <1157150119.6577.50.camel@ender> Message-ID: <200609051139.21565.jkeating@redhat.com> On Friday 01 September 2006 18:35, Jesse Keating wrote: > It's been discovered (thanks Bill) that nothing in Core or Extras seems > to need libxml. ?We'd like to kill it from the tree, before the freeze > for Test3 (Tuesday). ?Speak now, or forever hold your pieces of > packages. This is removed as of today. -- 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 jkeating at redhat.com Tue Sep 5 16:05:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Sep 2006 12:05:21 -0400 Subject: FC6 Test3 is now frozen Message-ID: <200609051205.21931.jkeating@redhat.com> Thanks! -- 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 pertusus at free.fr Tue Sep 5 18:18:37 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Sep 2006 20:18:37 +0200 Subject: Free Software audit update In-Reply-To: <1157435465.4654.43.camel@mccallum.corsepiu.local> References: <20060830190622.GA12462@free.fr> <1157000741.27813.42.camel@mccallum.corsepiu.local> <20060831124757.4ca36244@python2> <1157370070.4488.46.camel@mccallum.corsepiu.local> <34423.203.118.135.21.1157370301.squirrel@www.knox.net.nz> <44FC63EF.6050801@mharris.ca> <1157430546.4654.16.camel@mccallum.corsepiu.local> <44FD0172.9020104@thecodergeek.com> <44FD0D32.5070401@knox.net.nz> <1157435465.4654.43.camel@mccallum.corsepiu.local> Message-ID: <20060905181837.GA2257@free.fr> On Tue, Sep 05, 2006 at 07:51:05AM +0200, Ralf Corsepius wrote: > That's what I'll do, but Pertusus' packaging of lesstif is such kind of > bad, this won't be easy, in this particular case. I am ready to improve the packaging of lesstif to cope better with parallel installation with openmotif. But as I said in another mail, one have to balance the gains obtained parallel installable packages against the complications that are associated. -- Pat From ville.skytta at iki.fi Tue Sep 5 18:55:30 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Sep 2006 21:55:30 +0300 Subject: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff) In-Reply-To: <645d17210609041605l273801a0g834a01effdbb3830@mail.gmail.com> References: <1157400436.16129.134.camel@viper.local> <645d17210609041605l273801a0g834a01effdbb3830@mail.gmail.com> Message-ID: <1157482531.16129.210.camel@viper.local> On Tue, 2006-09-05 at 00:05 +0100, Jonathan Underwood wrote: > I think these packages would be much more sensibly named something > like xemacs-sumo-base and xemacs-sumo-extras or somesuch - both should > have sumo in the name. A package called xemacs-packages to Joe User > might imply "install all xemacs packages that are available" i.e. some > sort of meta package. sumo should definately be in the name. Well, I disagree mildly; what is currently shipped doesn't quite match what upstream includes in their sumos -- jde is pruned altogether, mew and skk removed and provided by other implementations in FE, mule-ucs is not always shipped, Sun will probably go away in the next revision -- and if the package would be split in two, it'd deviate even further. FWIW, there's also some slight movement towards the "xemacs-packages" name upstream, there are some xemacs-all-*packages symlinks in the download dirs, and I think all non-RH-derivative distros have moved on to use other names than the sumo. Anyway, I don't insist getting rid of the "sumo" word. > > Second part of the above plan is that the main xemacs package will no > > longer have a dependency to xemacs-packages (ex-sumo, due to the build > > dep loop above); it will have a dependency on xemacs-packages-base only. > > Why is even this dependency necessary? I don't remember hearing about anyone who uses XEmacs without any lisp packages installed (minimally xemacs-base and mule-base), and I'm not sure if that's even supposed to actually work. Dropping the dependency would however open some interesting possibilities -- eg. could drop xemacs-nox *and* sanely keep the lisp packages in their own noarch SRPM without splitting. I'll experiment with this. > Does upstream xemacs really require xemacs-sumo to build? No. > Also, please strip out the source .el files into separate packages, as > is done with emacs. Sure, -el and -info subpackages will remain, similar to how they're now. From kwade at redhat.com Wed Sep 6 01:44:47 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 05 Sep 2006 18:44:47 -0700 Subject: Reminder: FC6 release notes last possible date 20 Sep. Message-ID: <1157507088.22766.66.camel@erato.phig.org> Help us to again make the best Linux release notes. There are content holes we can see[1], and maybe you know something that should be here: http://fedoraproject.org/wiki/Docs/Beats Please get your changes in by 20 September, so we have a chance to do clean-up. Expect continuous nagging throughout the rest of the release cycle. That is all. :) - Karsten [1] Complete list of pages that have not been updated by a maintainer: http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/PPC http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/x86 http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/x86_64 http://fedoraproject.org/wiki/Docs/Beats/DatabaseServers http://fedoraproject.org/wiki/Docs/Beats/Desktop http://fedoraproject.org/wiki/Docs/Beats/FileServers http://fedoraproject.org/wiki/Docs/Beats/Legacy http://fedoraproject.org/wiki/Docs/Beats/Networking http://fedoraproject.org/wiki/Docs/Beats/PackageChanges http://fedoraproject.org/wiki/Docs/Beats/Printing http://fedoraproject.org/wiki/Docs/Beats/Security http://fedoraproject.org/wiki/Docs/Beats/Security/SELinux http://fedoraproject.org/wiki/Docs/Beats/ServerTools http://fedoraproject.org/wiki/Docs/Beats/SystemDaemons http://fedoraproject.org/wiki/Docs/Beats/Xorg -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 ville.skytta at iki.fi Wed Sep 6 06:47:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Sep 2006 09:47:20 +0300 Subject: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff) In-Reply-To: <1157482531.16129.210.camel@viper.local> References: <1157400436.16129.134.camel@viper.local> <645d17210609041605l273801a0g834a01effdbb3830@mail.gmail.com> <1157482531.16129.210.camel@viper.local> Message-ID: <1157525241.16129.240.camel@viper.local> On Tue, 2006-09-05 at 21:55 +0300, Ville Skytt? wrote: > I don't remember hearing about anyone who uses XEmacs without any lisp > packages installed (minimally xemacs-base and mule-base), and I'm not > sure if that's even supposed to actually work. > > Dropping the dependency would however open some interesting > possibilities -- eg. could drop xemacs-nox *and* sanely keep the lisp > packages in their own noarch SRPM without splitting. I'll experiment > with this. That experiment was quickly over. Even File->Open from the menu doesn't work without the xemacs-base lisp package installed. From alexl at redhat.com Wed Sep 6 09:07:58 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 06 Sep 2006 11:07:58 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157462569.4016.153.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <1157460970.2047.35.camel@ender> <1157462569.4016.153.camel@greebo> Message-ID: <1157533678.4016.168.camel@greebo> On Tue, 2006-09-05 at 15:22 +0200, Alexander Larsson wrote: > On Tue, 2006-09-05 at 08:56 -0400, Jesse Keating wrote: > > On Tue, 2006-09-05 at 12:43 +0200, Alexander Larsson wrote: > > > > Perhaps in the case of mono, where the main package has no > > > difference > > > > between the runtime and the development files (one in the same) then > > > > the .pc file can stay in the main package. I'm OK with that. > > > > > > So, can we change the packaging guidelines to say this? (Otherwise > > > I'll > > > be flooded with more bug reports.) > > > > You are positive that your .pc files don't list any further software > > requirements that might be development in nature? If they did, this > > rule wouldn't apply. > > I guess its possible that gtk-sharp2 will get devel docs in the future, > which would end up in a -devel package. > > However, for the case of mono-nunit things are different. I don't think > putting the docs for nunit in a nunit-devel package. That would be > similar to putting the docs for binutils in a binutils-devel package. > (Of course, the binutils package has .h/.so/.a and doc files in the main > package.) Here is another example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205054 The gtk-sharp2 package is atm divided into three subpackages: gtk-sharp2: runtime files (.dll, .so) gtk-sharp2-devel: 4 pkg-config files needed for developing against stuff in gtk-sharp2 gtk-sharp2-gapi Special developer tool used for generating bindings of other gtk-like libraries. Includes a .pc file for gapi (which is actually pretty empty, so its not really useable other than checking for existance in a configure file). The bug above proposes to further split out this .pc file into a separate subpackage. However, the gapi package itself will never be installed on a user system, and no developer needing it would ever not want the .pc files. So, what use is splitting out this .pc file? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a witless neurotic astronaut who hides his scarred face behind a mask. She's a man-hating psychic opera singer who can talk to animals. They fight crime! From majain at redhat.com Wed Sep 6 11:45:38 2006 From: majain at redhat.com (=?UTF-8?Q?=E0=A4=AE=E0=A4=AF=E0=A4=82=E0=A4=95_=E0=A4=9C=E0=A5=88?= =?UTF-8?Q?=E0=A4=A8?=) Date: Wed, 06 Sep 2006 17:15:38 +0530 Subject: FC6 Test3 is now frozen In-Reply-To: <200609051205.21931.jkeating@redhat.com> References: <200609051205.21931.jkeating@redhat.com> Message-ID: <1157543138.3162.0.camel@majain.pnq.redhat.com> On Tue, 2006-09-05 at 12:05 -0400, Jesse Keating wrote: > Thanks! Hi, If we now submit builds to the buildsystem, would they reflect in FC6 final release? Thanks, Mayank From jkeating at redhat.com Wed Sep 6 12:11:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Sep 2006 08:11:27 -0400 Subject: FC6 Test3 is now frozen In-Reply-To: <1157543138.3162.0.camel@majain.pnq.redhat.com> References: <200609051205.21931.jkeating@redhat.com> <1157543138.3162.0.camel@majain.pnq.redhat.com> Message-ID: <200609060811.27862.jkeating@redhat.com> On Wednesday 06 September 2006 07:45, ???? ??? wrote: > Hi, > > If we now submit builds to the buildsystem, would they reflect in FC6 > final release? We are in a continual freeze. Builds are currently going to dist-fc6-HEAD. There is some criteria to get it moved out of -HEAD and into dist-fc6 for either Test3 or for the final. For Test3 they need to be serious blocker type bugfixes, such as every user will crash this app, or this will prevent installations. Once Test3 goes out the door there is a bit more flexibility in getting things moved in, and it would be low risk bugfixes (preferrably on either FC6Target or FC6Blockers) or the above criteria. Once we've deep frozen for FC6 we'd be back to 'prevents installation' or 'eats users data upon execution' criteria to get it pulled out of -HEAD and into dist-fc6 for the release. After that, the contents of dist-fc6-HEAD would be moved to dist-fc6-updates-candidate to be processed as possible updates. -- 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 jkeating at redhat.com Wed Sep 6 12:12:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Sep 2006 08:12:39 -0400 Subject: devel packages with only one .pc file In-Reply-To: <1157533678.4016.168.camel@greebo> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> Message-ID: <200609060812.39917.jkeating@redhat.com> On Wednesday 06 September 2006 05:07, Alexander Larsson wrote: > The bug above proposes to further split out this .pc file into a > separate subpackage. However, the gapi package itself will never be > installed on a user system, and no developer needing it would ever not > want the .pc files. So, what use is splitting out this .pc file? This bug may be a misunderstanding of what the package actually does. Given that gapi is already a "-devel" type package, I think its acceptable to keep the pc file there. I would close the bug as such. -- 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 rdieter at math.unl.edu Wed Sep 6 12:18:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Sep 2006 07:18:04 -0500 Subject: devel packages with only one .pc file In-Reply-To: <200609060812.39917.jkeating@redhat.com> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> Message-ID: <44FEBC7C.9010904@math.unl.edu> Jesse Keating wrote: > On Wednesday 06 September 2006 05:07, Alexander Larsson wrote: >> The bug above proposes to further split out this .pc file into a >> separate subpackage. However, the gapi package itself will never be >> installed on a user system, and no developer needing it would ever not >> want the .pc files. So, what use is splitting out this .pc file? > > This bug may be a misunderstanding of what the package actually does. Given > that gapi is already a "-devel" type package, I think its acceptable to keep > the pc file there. OTOH, it could be argued that since it is already -devel type package, (with apparently no runtime/non-devel bits), then it's *name* should reflect that. -- Rex From majain at redhat.com Wed Sep 6 12:22:14 2006 From: majain at redhat.com (=?UTF-8?Q?=E0=A4=AE=E0=A4=AF=E0=A4=82=E0=A4=95_=E0=A4=9C=E0=A5=88?= =?UTF-8?Q?=E0=A4=A8?=) Date: Wed, 06 Sep 2006 17:52:14 +0530 Subject: FC6 Test3 is now frozen In-Reply-To: <200609060811.27862.jkeating@redhat.com> References: <200609051205.21931.jkeating@redhat.com> <1157543138.3162.0.camel@majain.pnq.redhat.com> <200609060811.27862.jkeating@redhat.com> Message-ID: <1157545334.3162.4.camel@majain.pnq.redhat.com> On Wed, 2006-09-06 at 08:11 -0400, Jesse Keating wrote: > On Wednesday 06 September 2006 07:45, ???? ??? wrote: > > Hi, > > > > If we now submit builds to the buildsystem, would they reflect in FC6 > > final release? > > We are in a continual freeze. Builds are currently going to dist-fc6-HEAD. > There is some criteria to get it moved out of -HEAD and into dist-fc6 for > either Test3 or for the final. > > For Test3 they need to be serious blocker type bugfixes, such as every user > will crash this app, or this will prevent installations. > > Once Test3 goes out the door there is a bit more flexibility in getting things > moved in, and it would be low risk bugfixes (preferrably on either FC6Target > or FC6Blockers) or the above criteria. Once we've deep frozen for FC6 we'd > be back to 'prevents installation' or 'eats users data upon execution' > criteria to get it pulled out of -HEAD and into dist-fc6 for the release. > After that, the contents of dist-fc6-HEAD would be moved to > dist-fc6-updates-candidate to be processed as possible updates. Thanks for the inputs :) :) Mayank From pertusus at free.fr Wed Sep 6 13:35:49 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Sep 2006 15:35:49 +0200 Subject: Reminder: FC6 release notes last possible date 20 Sep. In-Reply-To: <1157507088.22766.66.camel@erato.phig.org> References: <1157507088.22766.66.camel@erato.phig.org> Message-ID: <20060906133549.GG2272@free.fr> On Tue, Sep 05, 2006 at 06:44:47PM -0700, Karsten Wade wrote: > Help us to again make the best Linux release notes. > > There are content holes we can see[1], and maybe you know something that > should be here: > > http://fedoraproject.org/wiki/Docs/Beats > > Please get your changes in by 20 September, so we have a chance to do > clean-up. There certainly should be something about the openmotif/lesstif transition. Would have been nice to have a repository for openmotif... -- Pat From rdieter at math.unl.edu Wed Sep 6 13:54:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Sep 2006 08:54:14 -0500 Subject: Reminder: FC6 release notes last possible date 20 Sep. In-Reply-To: <20060906133549.GG2272@free.fr> References: <1157507088.22766.66.camel@erato.phig.org> <20060906133549.GG2272@free.fr> Message-ID: <44FED306.8070201@math.unl.edu> On Wed, 6 Sep 2006, Patrice Dumas wrote: > On Tue, Sep 05, 2006 at 06:44:47PM -0700, Karsten Wade wrote: >> Help us to again make the best Linux release notes. >> >> There are content holes we can see[1], and maybe you know something that >> should be here: >> >> http://fedoraproject.org/wiki/Docs/Beats >> >> Please get your changes in by 20 September, so we have a chance to do >> clean-up. > > There certainly should be something about the openmotif/lesstif transition. > Would have been nice to have a repository for openmotif... Sure, maybe somebody could host it on some *non oss/free* repo (like livna). -- Rex From alexl at redhat.com Wed Sep 6 15:53:29 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 06 Sep 2006 17:53:29 +0200 Subject: devel packages with only one .pc file In-Reply-To: <44FEBC7C.9010904@math.unl.edu> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> <44FEBC7C.9010904@math.unl.edu> Message-ID: <1157558009.4016.172.camel@greebo> On Wed, 2006-09-06 at 07:18 -0500, Rex Dieter wrote: > Jesse Keating wrote: > > On Wednesday 06 September 2006 05:07, Alexander Larsson wrote: > >> The bug above proposes to further split out this .pc file into a > >> separate subpackage. However, the gapi package itself will never be > >> installed on a user system, and no developer needing it would ever not > >> want the .pc files. So, what use is splitting out this .pc file? > > > > This bug may be a misunderstanding of what the package actually does. Given > > that gapi is already a "-devel" type package, I think its acceptable to keep > > the pc file there. > > OTOH, it could be argued that since it is already -devel type package, > (with apparently no runtime/non-devel bits), then it's *name* should > reflect that. You mean we should call things gcc-devel, gdb-devel, valgrind-devel, memprof-devel, nasm-devel, etc? Sounds pretty silly to me. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding soccer-playing Green Beret on the edge. She's a cynical renegade lawyer who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! From rdieter at math.unl.edu Wed Sep 6 16:02:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Sep 2006 11:02:52 -0500 Subject: devel packages with only one .pc file In-Reply-To: <1157558009.4016.172.camel@greebo> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> <44FEBC7C.9010904@math.unl.edu> <1157558009.4016.172.camel@greebo> Message-ID: <44FEF12C.7000008@math.unl.edu> Alexander Larsson wrote: > On Wed, 2006-09-06 at 07:18 -0500, Rex Dieter wrote: >> Jesse Keating wrote: >>> On Wednesday 06 September 2006 05:07, Alexander Larsson wrote: >>>> The bug above proposes to further split out this .pc file into a >>>> separate subpackage. However, the gapi package itself will never be >>>> installed on a user system, and no developer needing it would ever not >>>> want the .pc files. So, what use is splitting out this .pc file? >>> This bug may be a misunderstanding of what the package actually does. Given >>> that gapi is already a "-devel" type package, I think its acceptable to keep >>> the pc file there. >> OTOH, it could be argued that since it is already -devel type package, >> (with apparently no runtime/non-devel bits), then it's *name* should >> reflect that. > > You mean we should call things gcc-devel, gdb-devel, valgrind-devel, > memprof-devel, nasm-devel, etc? > > Sounds pretty silly to me. Rhetorical: Is gcc, gdb, valgrind, nasm, memprof a subpackage of something else? (hint: no) -- Rex From toshio at tiki-lounge.com Wed Sep 6 17:01:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 06 Sep 2006 10:01:20 -0700 Subject: devel packages with only one .pc file In-Reply-To: <1157463952.6098.16.camel@zod.rchland.ibm.com> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> <1157463952.6098.16.camel@zod.rchland.ibm.com> Message-ID: <1157562080.2809.55.camel@localhost> On Tue, 2006-09-05 at 08:45 -0500, Josh Boyer wrote: > You all realize that the amount of time spent on this thread so far is > about 10x greater than it would have been to just fix the packages to > match the policy, right? It's important to understand why a policy exists. Then you can question whether it applies to all the circumstances it states or come up with a better way of achieving the end-goal. And that can lead to better guidelines. In this case I'm leaning towards changing the rules because it seems the reason for the policy might not apply to Mono packages: Mono packages contain two type of pkgconfig files. One type is for C glue libraries that link C code and Mono code. These should be treated just like normal pkgconfig files and be placed into a -devel subpackage along with the C headers and .so file. This is what is done in libbeagle and libbeagle-devel (subpackages of beagle), for instance. The other type is for programs linking together Mono libraries. In this case, the .pc will have lines which look like this (cut from banshee): Requires: gtk-sharp-2.0 gconf-sharp-2.0 Libs: -r:/usr/lib64/banshee/Banshee.Base.dll \ -r:/usr/lib64/banshee/Banshee.Widgets.dll \ -r:/usr/lib64/banshee/entagged-sharp.dll \ -r:/usr/lib64/banshee/hal-sharp.dll \ -r:/usr/lib64/banshee/MusicBrainz.dll -r:Mono.Posix The Libs: line refers to Mono .dll files which are needed at runtime as well as build time. The Requires: line references other Mono pkgconfig files which are similar. These files do not appear to drag in dependencies on C pkg-config files and their -devel packages. AFAICS, by their nature, they never will (alexl, please correct me if that is incorrect.) So a mono package with only a pkgconfig file as development information won't drag in -devel type information from other packages. Now we have Ralf's point. A package may have other types of information that qualify as -devel at some later point in time (api doc, for instance) or it may depend on a package which later gains the same and needs to split off a devel package. For the specific case of docs, I think we'd want to split large development documentation into its own -doc or -apidoc subpackage anyway. For the general case there is a bit of trouble. Say foo-1.0.pc Requires: bar-1.0.pc Requires: baz-1.0. When I initially package this there is no other devel information so all is well. But down the road baz adds more developer-relevant information. Suddenly, foo is pulling in files it shouldn't on end-user systems. How can we work around this? 1) Do as the guideline suggests. .pc files go in a separate -devel subpackage. 2) Make an exception for packages whose only -devel type file is a .pc so they can stay the way they are. Add Matthias Saou's suggested virtual Provides: %{name}-devel = %{version}-%{release} and have consumers of pkgconfig files use the virtual provides. If other -devel type files are added we make the virtual provide into a real subpackage. Other packages which depend on the package for their pkgconfig files have to periodically check for the existence of real -devel packages and if they exist, spawn new -devel packages of their own that just have a single pkgconfig file and the dependencies on the -devel otherwise the runtime package will drag in the pkgconfig dependency tree. 3) Make an exception for packages whose only -devel type file is a .pc so they can stay the way they are. If other -devel type files are added, we have to split off a new subpackage and fix all the BuildRequires: in dependent packages to point to the new -devel. Every package that has a Require on that package because of pkgconfig dependencies has to grow a -devel package with just the pkgconfig file inside it and the proper dependencies otherwise the pkgconfig files will break. 4) For Mono applications, pkgconfig files that deal with informing the mono build chain of the location of the .dlls belong in the main package. Other -devel files belong in a subpackage. I think #1 is the most robust solution and the friendliest to reviewers because there are fewer special cases. #2 is going to result in too much work for packagers (who have to watch for their dependent packages changing) and reviewers. #3 requires reviewers to understand the special case of pkgconfig files not dragging in extra dependencies but allows us to stop having "ridiculous" single file subpackages in many cases. It requires packagers to fix their packages if a -devel package is created further up the dep chain (so if glib-sharp grew the need for a -devel package, the whole gtk stack would need to be changed to have -devel packages.) Reviewers and packagers must understand that mono packages can have pkgconfig files for the C bindings and for the mono .dll and they need to be treated differently. #4 is kludgy as written because it only applies to packages written in Mono rather than being generalizable to packages which have/don't have a certain feature. But we have certain unwritten guidelines which are similar (In python, we could put .py files from %{python_sitelib} into a -devel or -debuginfo package because they are not needed for running the programs but we don't) It is directly opposite to the treatment of pkgconfig files from C (in C, pkgconfig files MUST go in a -devel subpackage. In Mono, pkgconfig files MUST be placed in the main package.) It requires reviewers and packagers to understand that mono packages may have two different sets of pkgconfig files with different rules. This supposes that a mono pkgconfig file will only drag in files that are also needed at runtime. (alexl, please correct me if I'm wrong.) I think #1 is the best for clarity. But I would also be willing to see the rule revised to something like #3 or #4 because I don't think most mono packages are going to have -devel files other than the pkgconfig file (alexl, please correct me if you see this differently.) Compared against each other, I think #3's major drawback is psychological: mono packagers may be hesitant to create -devel subpackages because the change will cascade to other packages, causing more work. #4's main drawback is its direct conflict with the guidelines for C pkgconfig files. -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 alexl at redhat.com Thu Sep 7 08:21:19 2006 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 07 Sep 2006 10:21:19 +0200 Subject: devel packages with only one .pc file In-Reply-To: <44FEF12C.7000008@math.unl.edu> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> <44FEBC7C.9010904@math.unl.edu> <1157558009.4016.172.camel@greebo> <44FEF12C.7000008@math.unl.edu> Message-ID: <1157617279.4016.184.camel@greebo> On Wed, 2006-09-06 at 11:02 -0500, Rex Dieter wrote: > Alexander Larsson wrote: > > On Wed, 2006-09-06 at 07:18 -0500, Rex Dieter wrote: > >> Jesse Keating wrote: > >>> On Wednesday 06 September 2006 05:07, Alexander Larsson wrote: > >>>> The bug above proposes to further split out this .pc file into a > >>>> separate subpackage. However, the gapi package itself will never be > >>>> installed on a user system, and no developer needing it would ever not > >>>> want the .pc files. So, what use is splitting out this .pc file? > >>> This bug may be a misunderstanding of what the package actually does. Given > >>> that gapi is already a "-devel" type package, I think its acceptable to keep > >>> the pc file there. > >> OTOH, it could be argued that since it is already -devel type package, > >> (with apparently no runtime/non-devel bits), then it's *name* should > >> reflect that. > > > > You mean we should call things gcc-devel, gdb-devel, valgrind-devel, > > memprof-devel, nasm-devel, etc? > > > > Sounds pretty silly to me. > > Rhetorical: Is gcc, gdb, valgrind, nasm, memprof a subpackage of > something else? (hint: no) I'm aware that it is a subpackage, yes. Real question: How does being a subpackage affect this at all? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fiendish chivalrous firefighter with nothing left to lose. She's a beautiful cigar-chomping mercenary in the wrong place at the wrong time. They fight crime! From alexl at redhat.com Thu Sep 7 08:36:01 2006 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 07 Sep 2006 10:36:01 +0200 Subject: devel packages with only one .pc file In-Reply-To: <1157562080.2809.55.camel@localhost> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> <1157463952.6098.16.camel@zod.rchland.ibm.com> <1157562080.2809.55.camel@localhost> Message-ID: <1157618161.4016.194.camel@greebo> On Wed, 2006-09-06 at 10:01 -0700, Toshio Kuratomi wrote: > > I think #1 is the best for clarity. But I would also be willing to see > the rule revised to something like #3 or #4 because I don't think most > mono packages are going to have -devel files other than the pkgconfig > file (alexl, please correct me if you see this differently.) Compared > against each other, I think #3's major drawback is psychological: mono > packagers may be hesitant to create -devel subpackages because the > change will cascade to other packages, causing more work. #4's main > drawback is its direct conflict with the guidelines for C pkgconfig > files. I'm ok with rule #1 in most cases, the other ones just seem kludgy. And i actually agree with the risk that other "devel" style files might be added to the package. However, there is one exception that i still would like to have, and that is the case of development packages. I like to avoid mono-nunit-devel and gtk-sharp2-gapi-devel, because i think they are actually harmful. Developers will not expect that you get a full working gapi enought to satisfy the buildrequirements of a module if you install the gtk-sharp2-gapi, but configure will fail to find it because you didn't install gtk-sharp2-gapi-devel. So, I'd like to see the rule be: Any .pc files must be in a -devel subpackage, unless the package itself is a development tool not installed in a user runtime. If the package has a -devel subpackage for other reasons the place for the pc file is up to the package owner (as it generaly depends on the usecase for the pc file). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a suave misogynist vagrant with a mysterious suitcase handcuffed to his arm. She's a brilliant hypochondriac doctor who don't take no shit from nobody. They fight crime! From rdieter at math.unl.edu Thu Sep 7 13:28:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Sep 2006 08:28:59 -0500 Subject: devel packages with only one .pc file In-Reply-To: <1157617279.4016.184.camel@greebo> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> <44FEBC7C.9010904@math.unl.edu> <1157558009.4016.172.camel@greebo> <44FEF12C.7000008@math.unl.edu> <1157617279.4016.184.camel@greebo> Message-ID: <45001E9B.3060504@math.unl.edu> Alexander Larsson wrote: > On Wed, 2006-09-06 at 11:02 -0500, Rex Dieter wrote: >> Alexander Larsson wrote: >> >> OTOH, it could be argued that since it is already -devel type package, >> >> (with apparently no runtime/non-devel bits), then it's name should >> >> reflect that. >> > You mean we should call things gcc-devel, gdb-devel, valgrind-devel, >> > memprof-devel, nasm-devel, etc? >> Rhetorical: Is gcc, gdb, valgrind, nasm, memprof a subpackage of >> something else? (hint: no) > Real question: How does being a subpackage affect this at all? You mentioned gcc, gdb, etc... as a counter-argument. I was simply highlighting a difference between them and this case... (hoping that it went without saying, but...) in most(95%-99%?) cases, imo, a foo-devel without a foo doesn't make much sense. -- Rex From rdieter at math.unl.edu Thu Sep 7 16:53:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Sep 2006 11:53:08 -0500 Subject: devel packages with only one .pc file In-Reply-To: <1157618161.4016.194.camel@greebo> References: <1157375487.4016.112.camel@greebo> <20060904164320.39ca6ded.bugs.michael@gmx.net> <1157384530.4016.136.camel@greebo> <1157389333.2047.12.camel@ender> <1157453039.4016.142.camel@greebo> <19944.192.54.193.51.1157462388.squirrel@rousalka.dyndns.org> <1157462721.4016.156.camel@greebo> <1157463952.6098.16.camel@zod.rchland.ibm.com> <1157562080.2809.55.camel@localhost> <1157618161.4016.194.camel@greebo> Message-ID: <45004E74.90409@math.unl.edu> Alexander Larsson wrote: > So, I'd like to see the rule be: > > Any .pc files must be in a -devel subpackage, unless the package itself > is a development tool not installed in a user runtime. If the package > has a -devel subpackage for other reasons the place for the pc file is > up to the package owner (as it generaly depends on the usecase for the > pc file). Very reasonable, I've added this (something very close to it anyway) to http://fedoraproject.org/wiki/Packaging/GuidelinesTodo -- Rex From rdieter at math.unl.edu Thu Sep 7 19:17:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Sep 2006 14:17:58 -0500 Subject: OpenEXR-1.4.x update Message-ID: <45007066.2060301@math.unl.edu> FYI, I plan on updating to OpenEXR-1.4.0 soon (see bug #201841), so just a heads up to those currently with OpenEXR dependencies(*), this new release is not ABI compatible. -- Rex (*) on fc5 box, $ repoquery --whatrequires \ OpenEXR libIex.so.2 libImath.so.2 libIlmImf.so.2 libHalf.so.2 returned: blender fyre k3d kdegraphics-extras koffice From notting at redhat.com Thu Sep 7 19:56:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Sep 2006 15:56:02 -0400 Subject: Fun with python and multilib Message-ID: <20060907195602.GA6752@nostromo.devel.redhat.com> Example bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205216 What's happening here (in the python side) is that the .pyc/.pyo file is storing the timestamp of the .py file - since aotcompile.py is made by config.status from aotcompile.py.in, it's almost guaranteed that its timestamp will be different between arches. Ideas on how to handle/fix this? Bill From jakub at redhat.com Thu Sep 7 20:16:19 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 7 Sep 2006 16:16:19 -0400 Subject: Fun with python and multilib In-Reply-To: <20060907195602.GA6752@nostromo.devel.redhat.com> References: <20060907195602.GA6752@nostromo.devel.redhat.com> Message-ID: <20060907201619.GE12531@devserv.devel.redhat.com> On Thu, Sep 07, 2006 at 03:56:02PM -0400, Bill Nottingham wrote: > Example bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205216 > > What's happening here (in the python side) is that the .pyc/.pyo file > is storing the timestamp of the .py file - since aotcompile.py is > made by config.status from aotcompile.py.in, it's almost guaranteed > that its timestamp will be different between arches. > > Ideas on how to handle/fix this? touch -r aotcompile.py.in aotcompile.py after configure? Jakub From notting at redhat.com Thu Sep 7 20:28:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Sep 2006 16:28:08 -0400 Subject: Fun with python and multilib In-Reply-To: <20060907201619.GE12531@devserv.devel.redhat.com> References: <20060907195602.GA6752@nostromo.devel.redhat.com> <20060907201619.GE12531@devserv.devel.redhat.com> Message-ID: <20060907202808.GA7553@nostromo.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > > What's happening here (in the python side) is that the .pyc/.pyo file > > is storing the timestamp of the .py file - since aotcompile.py is > > made by config.status from aotcompile.py.in, it's almost guaranteed > > that its timestamp will be different between arches. > > > > Ideas on how to handle/fix this? > > touch -r aotcompile.py.in aotcompile.py > after configure? Won't that screw up Makefile deps? (aside from it being a pain to implement across the entirety of the distro) Bill From misa at redhat.com Fri Sep 8 03:06:51 2006 From: misa at redhat.com (Mihai Ibanescu) Date: Thu, 7 Sep 2006 23:06:51 -0400 Subject: Fun with python and multilib In-Reply-To: <20060907195602.GA6752@nostromo.devel.redhat.com> References: <20060907195602.GA6752@nostromo.devel.redhat.com> Message-ID: <20060908030651.GB28910@abulafia.devel.redhat.com> On Thu, Sep 07, 2006 at 03:56:02PM -0400, Bill Nottingham wrote: > Example bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205216 > > What's happening here (in the python side) is that the .pyc/.pyo file > is storing the timestamp of the .py file - since aotcompile.py is > made by config.status from aotcompile.py.in, it's almost guaranteed > that its timestamp will be different between arches. > > Ideas on how to handle/fix this? Another possible approach to what Jakub suggested would be to install the stuff coming from the x86_64 package in /usr/lib64. Technically speaking, if you had a 32-bit python on a 64-bit platform, would you expect it to be able to run aotcompile.py from the 64-bit java-compat-devel package? Since I know nothing about aotcompile.py, maybe that's ok. There is a pending bug against python that is sort of similar (package tries to install all .py files under /usr/lib and all .so files under /usr/lib64). The distutils manual classifies python modules as 'pure' and non-pure. As soon as you have a .so in your module, your module is not pure anymore and has to go completely under /usr/lib64. This makes sense, because if you were to install your .py files under /usr/lib and .so under /usr/lib64, someone using a 32-bit python might try to import the .py files which won't be able to find the .so, so they'd be useless. But I digress... Misa From denis at poolshark.org Fri Sep 8 05:48:18 2006 From: denis at poolshark.org (Denis Leroy) Date: Fri, 08 Sep 2006 07:48:18 +0200 Subject: OpenEXR-1.4.x update In-Reply-To: <45007066.2060301@math.unl.edu> References: <45007066.2060301@math.unl.edu> Message-ID: <45010422.5060507@poolshark.org> Rex Dieter wrote: > FYI, I plan on updating to OpenEXR-1.4.0 soon (see bug #201841), so just > a heads up to those currently with OpenEXR dependencies(*), this new > release is not ABI compatible. Thanks, can you send an email when you you queue the actual build ? -denis, k3d maintainer From jkeating at redhat.com Fri Sep 8 17:35:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Sep 2006 13:35:50 -0400 Subject: Fwd: Tree Testing for FC6 Test3 Message-ID: <200609081335.50261.jkeating@redhat.com> ---------- Forwarded Message ---------- Subject: Tree Testing for FC6 Test3 Date: Friday 08 September 2006 13:35 From: Jesse Keating To: For testers of Fedora Core development releases We have a test grid up at http://fedoraproject.org/wiki/QA/FC6Test3TreeTesting If you can do some testing, we'd greatly appreciate it! -- Jesse Keating Release Engineer: Fedora ------------------------------------------------------- -- 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 mharris at mharris.ca Sat Sep 9 07:15:15 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 09 Sep 2006 03:15:15 -0400 Subject: devel packages with only one .pc file In-Reply-To: <45001E9B.3060504@math.unl.edu> References: <1157375487.4016.112.camel@greebo> <1157462569.4016.153.camel@greebo> <1157533678.4016.168.camel@greebo> <200609060812.39917.jkeating@redhat.com> <44FEBC7C.9010904@math.unl.edu> <1157558009.4016.172.camel@greebo> <44FEF12C.7000008@math.unl.edu> <1157617279.4016.184.camel@greebo> <45001E9B.3060504@math.unl.edu> Message-ID: <45026A03.5070507@mharris.ca> Rex Dieter wrote: > Alexander Larsson wrote: > >> On Wed, 2006-09-06 at 11:02 -0500, Rex Dieter wrote: >>> Alexander Larsson wrote: > >>> >> OTOH, it could be argued that since it is already -devel type >>> package, >>> >> (with apparently no runtime/non-devel bits), then it's name should >>> >> reflect that. > >>> > You mean we should call things gcc-devel, gdb-devel, valgrind-devel, >>> > memprof-devel, nasm-devel, etc? > >>> Rhetorical: Is gcc, gdb, valgrind, nasm, memprof a subpackage of >>> something else? (hint: no) > >> Real question: How does being a subpackage affect this at all? > > You mentioned gcc, gdb, etc... as a counter-argument. I was simply > highlighting a difference between them and this case... (hoping that it > went without saying, but...) in most(95%-99%?) cases, imo, a foo-devel > without a foo doesn't make much sense. xorg-x11-proto-devel - contains X extension headers used by various things. They are only used for development, and come this way from upstream. This is the only sensible way to ship them. xorg-x11-xtrans-devel - contains the source code for Xtrans, which is included by the server and other things that use Xtrans at build time. There is no library. Both of these make perfect sense. I'm sure there are others. Xtrans really should be a shared library mind you, but it is not, and so of course it has to be packaged for what it is, rather than what it could be. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Linux fans: Check out Tym Morrison's hit new heavy metal single "Only Linux" at http://tymmorrison.com - If you would like to support this great Canadian metal artist and open source fanatic, you can buy a copy of Tym's Solo Project CD at the "Buy CD" link on his site. From tcallawa at redhat.com Sat Sep 9 16:06:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 09 Sep 2006 11:06:24 -0500 Subject: Japanese speaker/writer needed Message-ID: <1157817985.21085.69.camel@dhcp-32-122.ord.redhat.com> If anyone here is fluent (not just babelfish/translate.google.com) in Japanese and English, and is willing to help me out with a licensing issue, please contact me offlist. Thanks in advance, ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From chris.stone at gmail.com Sun Sep 10 09:41:34 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 10 Sep 2006 02:41:34 -0700 Subject: .so files in main package for python packages Message-ID: Upstream says there is a packaging error in one of my packages, pypoker-eval-devel. Upstream claims that the .so file should not be in the devel package but should be in the main package. I told upstream about our .so rule saying .so files should be in -devel, but he said this is not the case for python packages, and promptly demonstrated that the libxml2-python package is similar and that this package puts the .so files in the main pacakge on Fedora as well. So is libxml2-python package in error, or is upstream correct and there are exceptions to the .so rule for python packages? Upstream informs me that my package will break unless I put the .so file in the main package. From pertusus at free.fr Sun Sep 10 10:29:31 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 10 Sep 2006 12:29:31 +0200 Subject: .so files in main package for python packages In-Reply-To: References: Message-ID: <20060910102931.GA2267@free.fr> On Sun, Sep 10, 2006 at 02:41:34AM -0700, Christopher Stone wrote: > Upstream says there is a packaging error in one of my packages, > pypoker-eval-devel. > > Upstream claims that the .so file should not be in the devel package > but should be in the main package. > > I told upstream about our .so rule saying .so files should be in > -devel, but he said this is not the case for python packages, and > promptly demonstrated that the libxml2-python package is similar and > that this package puts the .so files in the main pacakge on Fedora as > well. I think that upstream is right in that case. The rule should be that .so file in %_libdir (or in directory searched for by the linker) should be in -devel packages. The .so that are not in these dirs are not used when linking, but are there to be dlopened, so should, in the general case be in the main package. > Upstream informs me that my package will break unless I put the .so > file in the main package. Indeed, since the file is certainly delopened. -- Pat From misa at redhat.com Sun Sep 10 18:08:57 2006 From: misa at redhat.com (Mihai Ibanescu) Date: Sun, 10 Sep 2006 14:08:57 -0400 Subject: .so files in main package for python packages In-Reply-To: References: Message-ID: <20060910180857.GB25506@abulafia.devel.redhat.com> On Sun, Sep 10, 2006 at 02:41:34AM -0700, Christopher Stone wrote: > Upstream says there is a packaging error in one of my packages, > pypoker-eval-devel. > > Upstream claims that the .so file should not be in the devel package > but should be in the main package. Would you mind providing a bit more context about the package, maybe a source rpm? > I told upstream about our .so rule saying .so files should be in > -devel, but he said this is not the case for python packages, and > promptly demonstrated that the libxml2-python package is similar and > that this package puts the .so files in the main pacakge on Fedora as > well. > > So is libxml2-python package in error, or is upstream correct and > there are exceptions to the .so rule for python packages? > > Upstream informs me that my package will break unless I put the .so > file in the main package. Which .so file are you talking about? python will dlopen modules that are .so. In the case of libxml2-python, I see a libxml2mod.so. Well, that's a library that is directly imported by python, it is _not_ a library used by other binaries that would link against it. Here's the example: >>> import libxml2mod >>> libxml2mod If that's the case with your .so file, then yes, upstream is right, it makes absolutely no sense to put the .so file in the -devel package, because it provides functionality required by that python module. In general, python modules don't have to have a -devel package (there may be exceptions to this rule but I can't think of one off the top of my head). Before you ask 'then why is there a libxml2-devel', that is for applications linking against libxml2.so in /usr/lib, or including header files from the C API, it has absolutely nothing to do with python. HTH, Misa From chris.stone at gmail.com Sun Sep 10 18:17:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 10 Sep 2006 11:17:35 -0700 Subject: .so files in main package for python packages In-Reply-To: <20060910180857.GB25506@abulafia.devel.redhat.com> References: <20060910180857.GB25506@abulafia.devel.redhat.com> Message-ID: On 9/10/06, Mihai Ibanescu wrote: > On Sun, Sep 10, 2006 at 02:41:34AM -0700, Christopher Stone wrote: > > Upstream says there is a packaging error in one of my packages, > > pypoker-eval-devel. > > > > Upstream claims that the .so file should not be in the devel package > > but should be in the main package. > > Would you mind providing a bit more context about the package, maybe a source > rpm? This is a package that is in Fedora Extras and the source is located in the Fedora Extras CVS under the pypoker-eval module. > > > I told upstream about our .so rule saying .so files should be in > > -devel, but he said this is not the case for python packages, and > > promptly demonstrated that the libxml2-python package is similar and > > that this package puts the .so files in the main pacakge on Fedora as > > well. > > > > So is libxml2-python package in error, or is upstream correct and > > there are exceptions to the .so rule for python packages? > > > > Upstream informs me that my package will break unless I put the .so > > file in the main package. > > Which .so file are you talking about? > python will dlopen modules that are .so. In the case of libxml2-python, I see > a libxml2mod.so. Well, that's a library that is directly imported by python, > it is _not_ a library used by other binaries that would link against it. > Here's the example: > > >>> import libxml2mod > >>> libxml2mod > > > If that's the case with your .so file, then yes, upstream is right, it makes > absolutely no sense to put the .so file in the -devel package, because it > provides functionality required by that python module. In general, python > modules don't have to have a -devel package (there may be exceptions to this > rule but I can't think of one off the top of my head). I believe this is the case for me: >>> import _pokereval_2_4 >>> _pokereval_2_4 Then after "yum remove pypoker-eval-devel": >>> import _pokereval_2_4 Traceback (most recent call last): File "", line 1, in ? ImportError: No module named _pokereval_2_4 From chris.stone at gmail.com Sun Sep 10 18:32:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 10 Sep 2006 11:32:45 -0700 Subject: .so files in main package for python packages In-Reply-To: References: <20060910180857.GB25506@abulafia.devel.redhat.com> Message-ID: One final question, what about the .la file? libxml2-python includes its .la file, should I include mine also? From rdieter at math.unl.edu Sun Sep 10 19:54:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 10 Sep 2006 14:54:27 -0500 Subject: .so files in main package for python packages In-Reply-To: References: <20060910180857.GB25506@abulafia.devel.redhat.com> Message-ID: <45046D73.8080607@math.unl.edu> On Sun, 10 Sep 2006, Christopher Stone wrote: > One final question, what about the .la file? libxml2-python includes > its .la file, should I include mine also? In general, .la files associated with shared libraries should be avoided if at all possible. Others are (relatively) harmless. -- Rex From rdieter at math.unl.edu Mon Sep 11 01:16:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 10 Sep 2006 20:16:34 -0500 Subject: OpenEXR-1.4.x update In-Reply-To: <45007066.2060301@math.unl.edu> References: <45007066.2060301@math.unl.edu> Message-ID: <4504B8F2.5040602@math.unl.edu> Rex Dieter wrote: > FYI, I plan on updating to OpenEXR-1.4.0 soon (see bug #201841), so just > a heads up to those currently with OpenEXR dependencies(*), this new > release is not ABI compatible. OK, the deed is done. 16925 (OpenEXR): Build on target fedora-development-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/16925-OpenEXR-1.4.0a-1.fc6/ -- Rex From denis at poolshark.org Mon Sep 11 09:25:40 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 11 Sep 2006 11:25:40 +0200 Subject: OpenEXR-1.4.x update In-Reply-To: <4504B8F2.5040602@math.unl.edu> References: <45007066.2060301@math.unl.edu> <4504B8F2.5040602@math.unl.edu> Message-ID: <45052B94.8080603@poolshark.org> Rex Dieter wrote: > Rex Dieter wrote: > >>FYI, I plan on updating to OpenEXR-1.4.0 soon (see bug #201841), so just >>a heads up to those currently with OpenEXR dependencies(*), this new >>release is not ABI compatible. > > > OK, the deed is done. > > 16925 (OpenEXR): Build on target fedora-development-extras succeeded. > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/16925-OpenEXR-1.4.0a-1.fc6/ Thank you, k3d rebuilt. From notting at redhat.com Mon Sep 11 14:05:46 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Sep 2006 10:05:46 -0400 Subject: .so files in main package for python packages In-Reply-To: <45046D73.8080607@math.unl.edu> References: <20060910180857.GB25506@abulafia.devel.redhat.com> <45046D73.8080607@math.unl.edu> Message-ID: <20060911140546.GB9038@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > On Sun, 10 Sep 2006, Christopher Stone wrote: > > > One final question, what about the .la file? libxml2-python includes > > its .la file, should I include mine also? > > In general, .la files associated with shared libraries should be avoided > if at all possible. Others are (relatively) harmless. However, if it refers to a .so python module, the .la file is completely superfluous - python will never look at it. Bill From andreas.bierfert at lowlatency.de Mon Sep 11 14:49:24 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 11 Sep 2006 16:49:24 +0200 Subject: Rebuild of my packages for fc6 Message-ID: <20060911164924.101d27af@alkaid.a.lan> Hi, starting today I will rebuild all my packages (where necessary) for fc6. If you have trouble with the builds please let me know as it will take me another week to get a fc6 box here... Thanks Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred From jkeating at redhat.com Tue Sep 12 15:27:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Sep 2006 11:27:23 -0400 Subject: Fwd: Broken upgrade paths in FC+FE 2006-09-12 Message-ID: <200609121127.23157.jkeating@redhat.com> These really need to get fixed by FC6 Final. ---------- Forwarded Message ---------- Subject: Broken upgrade paths in FC+FE 2006-09-12 Date: Tuesday 12 September 2006 11:08 From: buildsys at fedoraproject.org To: fedora-extras-list at redhat.com UNKNOWN OWNER (possibly Core package): db4 5: 0:4.3.29-8.fc5 (FC5-updates) 6: 0:4.3.29-7.fc6 (FC6) frysk 5: 0:0.0.1.2006.09.08.rh1-2.fc5 (FC5-updates) 6: 0:0.0.1.2006.08.30.rh1-1.fc6 (FC6) ftp 5: 0:0.17-33.fc5 (FC5-updates) 6: 0:0.17-32.1.2.4 (FC6) -- 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 bugs.michael at gmx.net Wed Sep 13 11:26:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Sep 2006 13:26:32 +0200 Subject: .so files in main package for python packages In-Reply-To: References: Message-ID: <20060913132632.495c85f4.bugs.michael@gmx.net> On Sun, 10 Sep 2006 02:41:34 -0700, Christopher Stone wrote: > Upstream says there is a packaging error in one of my packages, > pypoker-eval-devel. > > Upstream claims that the .so file should not be in the devel package > but should be in the main package. > > I told upstream about our .so rule saying .so files should be in > -devel, Kindly point to that rule in the Wiki. If it exists, it is wrong and ought to be reworded. We do not put all ".so files" into -devel packages. We put .so symlinks into -devel packages when a system library package contains the versioned .so.N.M file. We do that because for normal libraries, in particular system libraries, the .so symlink/name is only needed at build-time by the linker. "-lfoo" translates to "link against libfoo.so, following symlinks". If we didn't, multiple versions of system libraries could not coexist nicely, because the .so symlinks would conflict. For system libraries, it is also discouraged to use non-versioned .so symlinks/files for anything else than linking against them at build-time. Of course, no such guidelines with exceptions and with the risk of getting complex and requiring more experience the more complex it gets. There are valid reasons for a library to be called libfoo.so and to be put into the main package. For instance, if it's a plugin which is dlopened at run-time, or a private library outside run-time linker's default search-path. To add to the complexity, some applications still dlopen system libraries as *.so instead of *.so.N (expecting the *.so symlinks/files to be present), and they ought to be patched to open and "Requires" the versioned library in order to create a proper dependency. From michael at knox.net.nz Fri Sep 15 23:22:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 16 Sep 2006 11:22:21 +1200 Subject: [Fwd: Some bad news (well.. maybe)] Message-ID: <450B35AD.2080308@knox.net.nz> I probably should have sent this here too. Michael -------- Original Message -------- Subject: Some bad news (well.. maybe) Date: Sat, 16 Sep 2006 10:53:01 +1200 From: Michael J. Knox Reply-To: Discussion related to Fedora Extras To: Discussion related to Fedora Extras Hello All, I am regrettably going to be with drawning my packaging efforts post Fedora Core/Extras 6. I am now working 2 jobs and have little time for my, soon to be wife, let alone Fedora. I will complete the packages I have that are required for FE6 (HelixPlayer and gdk-pixbuf). Once Fedora Core/Extras 6 is released, I will put all my packages up on the orphans wiki page. Thanks Michael -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list From jpo at di.uminho.pt Sat Sep 16 22:06:55 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 16 Sep 2006 23:06:55 +0100 Subject: FE-5 perl modules status (2006-09-16) Message-ID: <450C757F.7020402@di.uminho.pt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fe5_perl_report_20060916.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From jpo at di.uminho.pt Sat Sep 16 22:07:44 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 16 Sep 2006 23:07:44 +0100 Subject: FE-6 perl modules status (2006-09-16) Message-ID: <450C75B0.9050108@di.uminho.pt> An embedded and charset-unspecified text was scrubbed... Name: fe6_perl_report_20060916.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From jpo at di.uminho.pt Sat Sep 16 22:08:55 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 16 Sep 2006 23:08:55 +0100 Subject: Rawhide perl modules status (2006-09-16) Message-ID: <450C75F7.6010801@di.uminho.pt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rawhide_perl_report_20060916.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Sun Sep 17 09:03:54 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Sep 2006 11:03:54 +0200 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <450C75B0.9050108@di.uminho.pt> References: <450C75B0.9050108@di.uminho.pt> Message-ID: <450D0F7A.8020901@laposte.net> Jose Pedro Oliveira a ?crit : > Fedora Extras development CPAN > Older Newer > ---------------------------------------------------------------------- > Font-TTF-0.40.0 (Font-TTF-0.40.tar.gz) Methinks your version parser needs a little more work? -- Nicolas Mailhot From jpo at di.uminho.pt Sun Sep 17 11:14:17 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 17 Sep 2006 12:14:17 +0100 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <450D0F7A.8020901@laposte.net> References: <450C75B0.9050108@di.uminho.pt> <450D0F7A.8020901@laposte.net> Message-ID: <450D2E09.60708@di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: > Jose Pedro Oliveira a ?crit : > >> Fedora Extras development CPAN >> Older Newer >> ---------------------------------------------------------------------- > >> Font-TTF-0.40.0 (Font-TTF-0.40.tar.gz) >> > > Methinks your version parser needs a little more work? Yes it needs (there are too many exceptions to handle). But I see this case as a packaging bug: I fail to understand why you had to append an extra ".0" to the upstream version number. I already have in my blacklist other examples of "creative" packaging version number conversions. For example: * Smart-Comments-v1.0.2 -> perl-Smart-Comments-1.000002-1 (same thing for Module-Starter-PBP-v0.0.3) I'm ok with removing the 'v' character but I'm not ok with the version number expansion from 1.0.2 to 1.000002. This kind of version number expansion is only valid for the main perl package but not for CPAN modules. jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFDS4Il0metZG9hRsRAn43AJ40vgkdpYj/OrF7EXth5P2pb0eSzQCgpjt5 G7UYeAxlQDGdYob5sLa6pyA= =uWoX -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Sun Sep 17 11:36:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Sep 2006 13:36:43 +0200 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <450D2E09.60708@di.uminho.pt> References: <450C75B0.9050108@di.uminho.pt> <450D0F7A.8020901@laposte.net> <450D2E09.60708@di.uminho.pt> Message-ID: <1158493003.20064.2.camel@rousalka.dyndns.org> Le dimanche 17 septembre 2006 ? 12:14 +0100, Jose Pedro Oliveira a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicolas Mailhot wrote: > > Jose Pedro Oliveira a ?crit : > > > >> Fedora Extras development CPAN > >> Older Newer > >> ---------------------------------------------------------------------- > > > >> Font-TTF-0.40.0 (Font-TTF-0.40.tar.gz) > >> > > > > Methinks your version parser needs a little more work? > > Yes it needs (there are too many exceptions to handle). > > But I see this case as a packaging bug: I fail to understand > why you had to append an extra ".0" to the upstream version number. It's there because upstream has been known to release bugfixes as .1 versions, and skipping the implicit .0 screws up rpm ordering Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jpo at di.uminho.pt Sun Sep 17 12:04:00 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 17 Sep 2006 13:04:00 +0100 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <1158493003.20064.2.camel@rousalka.dyndns.org> References: <450C75B0.9050108@di.uminho.pt> <450D0F7A.8020901@laposte.net> <450D2E09.60708@di.uminho.pt> <1158493003.20064.2.camel@rousalka.dyndns.org> Message-ID: <450D39B0.5000401@di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: > Le dimanche 17 septembre 2006 ? 12:14 +0100, Jose Pedro Oliveira a > ?crit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Nicolas Mailhot wrote: >>> Jose Pedro Oliveira a ?crit : >>> >>>> Fedora Extras development CPAN >>>> Older Newer >>>> ---------------------------------------------------------------------- >>>> Font-TTF-0.40.0 (Font-TTF-0.40.tar.gz) >>>> >>> Methinks your version parser needs a little more work? >> Yes it needs (there are too many exceptions to handle). >> >> But I see this case as a packaging bug: I fail to understand >> why you had to append an extra ".0" to the upstream version number. > > It's there because upstream has been known to release bugfixes as .1 > versions, and skipping the implicit .0 screws up rpm ordering No it doesn't. Available perl-Font-FFT RPMS in FE repos: ./4/SRPMS/perl-Font-TTF-0.38.1-1.fc4.src.rpm ./5/SRPMS/perl-Font-TTF-0.38.1-1.fc5.src.rpm ./development/SRPMS/perl-Font-TTF-0.40.0-2.fc6.src.rpm Comparing version 0.38.1 against 0.40 $ fedora-rpmvercmp 0 0.38.1 1 0 0.40 1 0:0.40-1 is newer Comparing version 0.40 against 0.40.0 $ fedora-rpmvercmp 0 0.40 1 0 0.40.0 1 0:0.40.0-1 is newer And even if it did screw the RPM ordering you could always bump the epoch. jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFDTmwl0metZG9hRsRApjXAJ9ZOrK9K6GZViXD6ow6e0WzfUFQowCgu+fX TDR+KzBsOMIDgbMASWJ46/k= =K1JB -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Sun Sep 17 13:14:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Sep 2006 15:14:56 +0200 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <450D39B0.5000401@di.uminho.pt> References: <450C75B0.9050108@di.uminho.pt> <450D0F7A.8020901@laposte.net> <450D2E09.60708@di.uminho.pt> <1158493003.20064.2.camel@rousalka.dyndns.org> <450D39B0.5000401@di.uminho.pt> Message-ID: <1158498896.20064.5.camel@rousalka.dyndns.org> Le dimanche 17 septembre 2006 ? 13:04 +0100, Jose Pedro Oliveira a ?crit : > Nicolas Mailhot wrote: > > It's there because upstream has been known to release bugfixes as .1 > > versions, and skipping the implicit .0 screws up rpm ordering > > No it doesn't. Ok, seems I were overcautious there, will fix when 0.41 is out > And even if it did screw the RPM ordering you could > always bump the epoch. epoch: just say no -- 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 jpo at di.uminho.pt Sun Sep 17 14:15:05 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 17 Sep 2006 15:15:05 +0100 Subject: FE-6 perl modules status (2006-09-16) In-Reply-To: <1158498896.20064.5.camel@rousalka.dyndns.org> References: <450C75B0.9050108@di.uminho.pt> <450D0F7A.8020901@laposte.net> <450D2E09.60708@di.uminho.pt> <1158493003.20064.2.camel@rousalka.dyndns.org> <450D39B0.5000401@di.uminho.pt> <1158498896.20064.5.camel@rousalka.dyndns.org> Message-ID: <450D5869.9030005@di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: >> And even if it did screw the RPM ordering you could >> always bump the epoch. > > epoch: just say no Unfortunately you can't always avoid bump it. For example, check the version history of the following perl packages: * perl-LDAP * perl-Error * perl-HTML-Mason * perl-HTML-Tree jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFDVhpl0metZG9hRsRAp/UAJ9au/G62agwuLBNe5JLnlxrmEcGTwCgtb8S 2aF71xsue57bmLgSbcQ0w1M= =//FA -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Mon Sep 18 20:52:55 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 18 Sep 2006 23:52:55 +0300 Subject: Extras packages queued for removal after (non-)rebuild Message-ID: <1158612775.2902.140.camel@viper.local> Hi, The deadline for the FE mass rebuild for FC6 was today, 153 packages which are still in the devel (package) repo have not had their needs.rebuild file treated in CVS. Attachments: - not-treated.txt: the 153 packages above - not-treated-already-removed.txt: not treated, but already removed - not-treated-deps.txt: packages that have dependencies to the above or subpackages of the above, but are not listed in the above The not-treated-deps.txt list is informational -- it may contain false positives and lack some packages, and it does not take build dependencies into account. Maintainers of packages listed in it may want to look into it anyway. Cleanup of packages listed in not-treated.txt from the devel package repo will start today. Changing their status to orphaned and removing them from comps will be done a bit later, and packages that have dependencies to those removed will be cleaned up incrementally in the next few days. Package dirs in CVS will be taken care of later, but anyway I suppose before FC-6 is branched. -------------- next part -------------- adns alacarte alsa-tools amaya artwiz-aleczapka-fonts autotrace banner blam blktool bwm-ng camstream cdlabelgen cfs charis-fonts cpan2rpm ctorrent cvsplot daap-sharp darcs ddclient ddskk doulos-fonts ecore edb edje eet embryo evas firestarter flim fontforge fonttools FreeWnn fslint gai gaim-guifications gaim-otr gai-pal gdeskcal gdl gentium-fonts gfontview ghc gnet2 gnome-build gnomesword gnome-yum gnugo gourmet grhino gstreamer08-python gstreamer-python gtk2hs gtkhtml36 gtranslator haddock hexter-dssi html-xml-utils ifplugd jakarta-commons-cli jikes jlint john koffice koffice-langpack lcdf-typetools lcov lft libannodex libcmml libdnet libifp liblrdf liboggz librsync libstatgrab libuninameslist libvisual-plugins linux-libertine-fonts lsscsi mach MagicPoint mantis mediawiki mod_annodex NetworkManager-vpnc notecase nucleo opencv openmpi pan pdsh pengupop perl-Apache-LogRegex perl-File-BOM perl-Gnome2-Canvas perl-Gtk2-GladeXML perl-Imager perl-Mail-Alias perl-Readonly perl-Readonly-XS perl-Spoon perl-Spreadsheet-ParseExcel perl-Unix-Statgrab perl-YAML-Parser-Syck polyxmass-common polyxmass-data polyxmass-doc PyRTF python-adns python-cherrypy python-cherrytemplate python-enchant python-nltk python-twisted PyX pyxdg qascade quadkonsole quarry rblcheck rdiff-backup repoml rkhunter rman rpmDirectoryCheck ruby-mysql sabayon scanssh scim-chinese-standard scim-fcitx scribus-templates skkdic spicctrl Sprog ss5 straw sword synce-software-manager synce-trayicon system-config-control t1lib t1utils taskjuggler tetex-fontools tetex-prosper translate-toolkit ttf2pt1 v2strip vorbisgain xplanet z88dk zeroinstall-injector -------------- next part -------------- alsa-firmware dogtail dxpc gnome-applet-netmon Gtk-Perl icmpdn initng leafnode libevent libmatchbox oooqs2 pyspi R-RScaLAPACK silky zoo -------------- next part -------------- amarok amarok-visualisation ardour azureus blacs blacs-devel buildbot duplicity fbdesk flumotion fluxbox fluxconf fyre gai-temp gcombust gnash-plugin grace grace-devel gurlchecker ip6sic istanbul kadu-amarok mftrace mod_annodex paraview paraview-data paraview-mpi perl-Kwiki perl-Kwiki-Archive-Rcs perl-Kwiki-Attachments perl-Kwiki-Diff perl-Kwiki-ModPerl perl-Kwiki-NewPage perl-Kwiki-Raw perl-Kwiki-RecentChanges perl-Kwiki-Revisions perl-Kwiki-Search perl-Kwiki-UserName perl-Kwiki-UserPreferences perl-Kwiki-Users-Remote pyicq-t pyicq-t-mysql python-cvstoys rosegarden4 scalapack scalapack-devel scim-skk serpentine smeg soundconverter statgrab-tools TurboGears From orion at cora.nwra.com Mon Sep 18 21:16:54 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 18 Sep 2006 15:16:54 -0600 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <450F0CC6.5040702@cora.nwra.com> Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. > > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later, and packages that have > dependencies to those removed will be cleaned up incrementally in the > next few days. Package dirs in CVS will be taken care of later, but > anyway I suppose before FC-6 is branched. So, if I want to take over maintaining any of these, when can I do it? When they are officially orphaned? Will this be done before being removed from comps (to avoid having to re-add them)? -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From tcallawa at redhat.com Mon Sep 18 21:43:49 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Sep 2006 16:43:49 -0500 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158615829.7015.72.camel@localhost.localdomain> On Mon, 2006-09-18 at 23:52 +0300, Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. scalapack/scalapack-devel were built on Friday, needs.rebuild was removed then. I've finally managed to figure out why R-RScaLAPACK wasn't building, its now built for development, and needs.rebuild is removed. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From steve at kspei.com Mon Sep 18 21:54:06 2006 From: steve at kspei.com (Steven Pritchard) Date: Mon, 18 Sep 2006 16:54:06 -0500 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <20060918215406.GA13257@osiris.silug.org> On Mon, Sep 18, 2006 at 11:52:55PM +0300, Ville Skytt? wrote: > perl-Spoon That was an oversight. Apparently I made a spec change and cvs rm'd needs.rebuild, and for some reason didn't actually commit the change. Oops. It's fixed now. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From tcallawa at redhat.com Mon Sep 18 21:59:46 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Sep 2006 16:59:46 -0500 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158616786.7015.78.camel@localhost.localdomain> gaim-guifications was on the list of packages not rebuilt. Since I'm a happy user of this and would rather not see it die, is it OK if I take over maintainership of this and rebuild it? I've already got a working SRPM for FC-6. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jgarzik at redhat.com Mon Sep 18 22:01:23 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Mon, 18 Sep 2006 18:01:23 -0400 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <20060918220123.GB16236@devserv.devel.redhat.com> On Mon, Sep 18, 2006 at 11:52:55PM +0300, Ville Skytt? wrote: > blktool This will get done today or tomorrow, depending on whether I continue to have a staple-induced headache :) Jeff From denis at poolshark.org Mon Sep 18 22:18:01 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 Sep 2006 00:18:01 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <450F1B19.2000504@poolshark.org> Ville Skytt? wrote: > gstreamer-python I'll pick up this one, as one of my packages depend on it. > amarok > ardour > azureus > gnash-plugin Whoah, hold your horses here. There are some pretty big names in this list. Can we dissect the culprits before we start cvs-removing things willy nilly ? From pertusus at free.fr Mon Sep 18 22:34:53 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 Sep 2006 00:34:53 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <450F1B19.2000504@poolshark.org> References: <1158612775.2902.140.camel@viper.local> <450F1B19.2000504@poolshark.org> Message-ID: <20060918223453.GB6181@free.fr> On Tue, Sep 19, 2006 at 12:18:01AM +0200, Denis Leroy wrote: > Ville Skytt? wrote: > > >amarok > >ardour > >azureus > >gnash-plugin > > Whoah, hold your horses here. There are some pretty big names in this > list. Can we dissect the culprits before we start cvs-removing things > willy nilly ? These won't be removed, they are listed because some of their dependencies are to be removed (as a side note for gnash-plugin it seems to be a false positive...). -- Pat From bugs.michael at gmx.net Mon Sep 18 23:38:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Sep 2006 01:38:21 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <20060919013821.f13efb27.bugs.michael@gmx.net> On Mon, 18 Sep 2006 23:52:55 +0300, Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. > > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later, and packages that have > dependencies to those removed will be cleaned up incrementally in the > next few days. Package dirs in CVS will be taken care of later, but > anyway I suppose before FC-6 is branched. I see "gai" on the list, and removing it would break my "gai-temp", which would suck very much as I don't want to be confronted with unexpected wreckage. I don't know where the maintainer is, but I've queued rebuilds of gai and gai-pal for now and added myself to Cc in owners.list. From dominik at greysector.net Tue Sep 19 00:52:22 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 19 Sep 2006 02:52:22 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <20060919005222.GA18605@rathann.pekin.waw.pl> On Monday, 18 September 2006 at 22:52, Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. > > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later, and packages that have > dependencies to those removed will be cleaned up incrementally in the > next few days. Package dirs in CVS will be taken care of later, but > anyway I suppose before FC-6 is branched. I'll happily take over the following: > openmpi > rblcheck > tetex-prosper What's the problem with: > grace > grace-devel ? -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 19 00:59:57 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 19 Sep 2006 09:59:57 +0900 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <450F410D.4030305@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. > > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later, and packages that have > dependencies to those removed will be cleaned up incrementally in the > next few days. Package dirs in CVS will be taken care of later, but > anyway I suppose before FC-6 is branched. > I would like to take over the following package: > xplanet It seems that this package is not maintained by current maintainer. Mamoru Tasaka From orion at cora.nwra.com Tue Sep 19 03:03:53 2006 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Mon, 18 Sep 2006 21:03:53 -0600 (MDT) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060919005222.GA18605@rathann.pekin.waw.pl> References: <1158612775.2902.140.camel@viper.local> <20060919005222.GA18605@rathann.pekin.waw.pl> Message-ID: <1372.71.208.225.44.1158635033.squirrel@www.cora.nwra.com> > On Monday, 18 September 2006 at 22:52, Ville Skytt? wrote: > > I'll happily take over the following: > >> openmpi This is (apparently) moving to core. - Orion From green at redhat.com Tue Sep 19 05:35:39 2006 From: green at redhat.com (Anthony Green) Date: Mon, 18 Sep 2006 22:35:39 -0700 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <450F1B19.2000504@poolshark.org> References: <1158612775.2902.140.camel@viper.local> <450F1B19.2000504@poolshark.org> Message-ID: <1158644139.8157.46.camel@localhost.localdomain> On Tue, 2006-09-19 at 00:18 +0200, Denis Leroy wrote: > > amarok > > ardour > > azureus > > gnash-plugin > > Whoah, hold your horses here. There are some pretty big names in this > list. Ardour, azureus and all of my other Extras packages were rebuilt today (it's still Sep 18 here on the west coast :-) AG From alexl at redhat.com Tue Sep 19 09:52:49 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 19 Sep 2006 11:52:49 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158659570.2747.0.camel@greebo> On Mon, 2006-09-18 at 23:52 +0300, Ville Skytt? wrote: > sabayon Sorry, I forgot about this one. I'm taking care of it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a shy arachnophobic master criminal She's a sharp-shooting renegade research scientist with the power to see death. They fight crime! From triad at df.lth.se Tue Sep 19 13:30:08 2006 From: triad at df.lth.se (Linus Walleij) Date: Tue, 19 Sep 2006 15:30:08 +0200 (CEST) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: On Mon, 18 Sep 2006, Ville Skytt? wrote: > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above Packages that have BR on one of the removed packages doesn't seem to be included. For example I believe wine has a BR on fontforge. (Could have been changed tho, I don't have access to the CVS here.) Linus From coldwell at redhat.com Tue Sep 19 13:46:07 2006 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 19 Sep 2006 09:46:07 -0400 (EDT) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: On Mon, 18 Sep 2006, Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above Sorry; lsscsi has been rebuilt. From buildsys at fedoraproject.org Tue Sep 19 09:41:32 2006 Date: Tue, 19 Sep 2006 09:41:08 -0400 (EDT) From: buildsys at fedoraproject.org To: coldwell at redhat.com Subject: Build Result: 18042 - lsscsi on fedora-development-extras 18042 (lsscsi): Build on target fedora-development-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/18042-lsscsi-0.17-2/ Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jima at beer.tclug.org Tue Sep 19 13:48:04 2006 From: jima at beer.tclug.org (Jima) Date: Tue, 19 Sep 2006 08:48:04 -0500 (CDT) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060919005222.GA18605@rathann.pekin.waw.pl> References: <1158612775.2902.140.camel@viper.local> <20060919005222.GA18605@rathann.pekin.waw.pl> Message-ID: On Tue, 19 Sep 2006, Dominik 'Rathann' Mierzejewski wrote: > I'll happily take over the following: > >> openmpi >> rblcheck >> tetex-prosper I think I may have undercut you on rblcheck. I emailed Oliver Falk and got his approval to take over banner, bwm-ng, graphviz, ngrep, rblcheck, and scanssh. All of these packages (except graphviz, which was a couple days ago) have been rebuilt as of his morning, as he just gave me his okay. If you really do want rblcheck, or want to co-maintain, feel free to let me know. Jima From tcallawa at redhat.com Tue Sep 19 14:57:42 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 09:57:42 -0500 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158616786.7015.78.camel@localhost.localdomain> References: <1158612775.2902.140.camel@viper.local> <1158616786.7015.78.camel@localhost.localdomain> Message-ID: <1158677862.6156.9.camel@localhost.localdomain> On Mon, 2006-09-18 at 16:59 -0500, Tom 'spot' Callaway wrote: > gaim-guifications was on the list of packages not rebuilt. Since I'm a > happy user of this and would rather not see it die, is it OK if I take > over maintainership of this and rebuild it? I've already got a working > SRPM for FC-6. Since no one objected, I added myself to the CC list of gaim-guifications as a co-maintainer, successfully rebuilt this package, and nuked the needs.rebuild. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From ville.skytta at iki.fi Tue Sep 19 15:46:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 19 Sep 2006 18:46:50 +0300 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158680810.2902.178.camel@viper.local> On Tue, 2006-09-19 at 09:46 -0400, Chip Coldwell wrote: > Sorry; lsscsi has been rebuilt. But improperly: > 18042 (lsscsi): Build on target fedora-development-extras succeeded. > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/18042-lsscsi-0.17-2/ There is already lsscsi-0.17-2 built on Jul 26 in the repository. You need to bump the package's EVR, otherwise the newly built duplicate rpms will be just discarded. http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild https://www.redhat.com/archives/fedora-extras-list/2006-September/msg00293.html From ville.skytta at iki.fi Tue Sep 19 15:51:29 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 19 Sep 2006 18:51:29 +0300 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158681089.2902.184.camel@viper.local> On Tue, 2006-09-19 at 15:30 +0200, Linus Walleij wrote: > On Mon, 18 Sep 2006, Ville Skytt? wrote: > > > - not-treated-deps.txt: packages that have dependencies to the above or > > subpackages of the above, but are not listed in the above > > Packages that have BR on one of the removed packages doesn't seem to be > included. Right, that was noted in the original message. From rc040203 at freenet.de Tue Sep 19 15:52:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Sep 2006 17:52:48 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158681168.5044.258.camel@mccallum.corsepiu.local> On Tue, 2006-09-19 at 16:54 +0200, Paul Wouters wrote: > On Mon, 18 Sep 2006, Ville Skytt? wrote: > > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > > which are still in the devel (package) repo have not had their > > needs.rebuild file treated in CVS. > > > > Attachments: > > - not-treated.txt: the 153 packages above > > > Cleanup of packages listed in not-treated.txt from the devel package > > repo will start today. Changing their status to orphaned and removing > > them from comps will be done a bit later > > gaim-otr does not build in mock. It seems the configure script is not > generated. I cannot reproduce this, as it builds fine on my machines. > So it is not a lack of maintaining that is causing gaim-otr to have not > been rebuild. So please don't orphan the package. Did you read http://www.redhat.com/archives/fedora-extras-list/2006-August/msg00108.html Your tarball is mal-packaged, your spec is broken. Fixing this is straight forward. Ralf From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 19 15:57:59 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 20 Sep 2006 00:57:59 +0900 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <45101387.1070404@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above > > The not-treated-deps.txt list is informational -- it may contain false > positives and lack some packages, and it does not take build > dependencies into account. Maintainers of packages listed in it may > want to look into it anyway. > > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later, and packages that have > dependencies to those removed will be cleaned up incrementally in the > next few days. Package dirs in CVS will be taken care of later, but > anyway I suppose before FC-6 is branched. > > > ------------------------------------------------------------------------ > xplanet Now I could contact xplanet maintainer and he agreed that I will maintain this package with him. I upgraded xplanet to 1.2.0 and so I removed needs.rebuild. Mamoru Tasaka From coldwell at redhat.com Tue Sep 19 16:01:54 2006 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 19 Sep 2006 12:01:54 -0400 (EDT) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158680810.2902.178.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> <1158680810.2902.178.camel@viper.local> Message-ID: On Tue, 19 Sep 2006, Ville Skytt? wrote: > On Tue, 2006-09-19 at 09:46 -0400, Chip Coldwell wrote: > >> Sorry; lsscsi has been rebuilt. > > But improperly: > >> 18042 (lsscsi): Build on target fedora-development-extras succeeded. >> Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/18042-lsscsi-0.17-2/ > > There is already lsscsi-0.17-2 built on Jul 26 in the repository. You > need to bump the package's EVR, otherwise the newly built duplicate rpms > will be just discarded. OK, fixed. From buildsys at fedoraproject.org Tue Sep 19 11:59:01 2006 Date: Tue, 19 Sep 2006 11:58:55 -0400 (EDT) From: buildsys at fedoraproject.org To: coldwell at redhat.com Subject: Build Result: 18051 - lsscsi on fedora-development-extras 18051 (lsscsi): Build on target fedora-development-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/18051-lsscsi-0.17-3/ -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From fedora at leemhuis.info Tue Sep 19 17:47:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Sep 2006 19:47:17 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <45102D25.2010201@leemhuis.info> Ville Skytt? schrieb: > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > Attachments: > - not-treated.txt: the 153 packages above > [...] > > alacarte > openmpi Those two should simply be removed and marked as dead.package in cvs -- they are in core now. paps is also still in the repo, but already marked as dead.package in cvs. Cu thl From rdieter at math.unl.edu Tue Sep 19 17:54:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Sep 2006 12:54:13 -0500 Subject: libtunepimp-0.5.1 coming (soon) to Extras Message-ID: <45102EC5.9040702@math.unl.edu> Just a heads up that I plan on upgrading to libtunepimp-0.5.1 (in Extras) sson (probably within a couple of days). It is API/ABI-incompatible with previous releases. AFAICT, the only affected Extras packages are: amarok (1) kdemultimedia-extras (mine) (2) kid3 (2) (1) confirmed to work with libtunepimp-0.5 (2) doesn't (yet) support libtunepimp-0.5 (but still buildable). If there's enough interest, I can make a parallel-installable compat-libtunepimp-0.4 (or something like that). Frankly, libtunepimp-0.4 is/was buggy enough that it probably isn't worth the effort. -- Rex From dominik at greysector.net Tue Sep 19 22:49:49 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 20 Sep 2006 00:49:49 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: References: <1158612775.2902.140.camel@viper.local> <20060919005222.GA18605@rathann.pekin.waw.pl> Message-ID: <20060919224949.GB24745@rathann.pekin.waw.pl> On Tuesday, 19 September 2006 at 15:48, Jima wrote: > On Tue, 19 Sep 2006, Dominik 'Rathann' Mierzejewski wrote: > >I'll happily take over the following: > > > >>openmpi > >>rblcheck > >>tetex-prosper > > I think I may have undercut you on rblcheck. I emailed Oliver Falk and > got his approval to take over banner, bwm-ng, graphviz, ngrep, rblcheck, > and scanssh. All of these packages (except graphviz, which was a couple > days ago) have been rebuilt as of his morning, as he just gave me his > okay. > If you really do want rblcheck, or want to co-maintain, feel free to let > me know. Not a problem. That leaves tetex-prosper for me, yes? I'll contact the maintainer. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Tue Sep 19 23:56:08 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 20 Sep 2006 01:56:08 +0200 Subject: Fwd: Re: tetex-prosper package in Fedora Extras In-Reply-To: <20060919224949.GB24745@rathann.pekin.waw.pl> Message-ID: <20060919235605.GA32347@rathann.pekin.waw.pl> Taken. ----- Forwarded message from "Michael A. Peters" ----- Subject: Re: tetex-prosper package in Fedora Extras From: "Michael A. Peters" To: Dominik 'Rathann' Mierzejewski Date: Tue, 19 Sep 2006 16:20:00 -0700 You may take it. On Wed, 2006-09-20 at 00:59 +0200, Dominik 'Rathann' Mierzejewski wrote: > Hi. > > Looks like you've dropped out of net-existence. None of the packages > maintained by you in Fedora Extras have been rebuilt during the latest Mass > Rebuild before FC6. Since the time is up, I'd like to take over your > tetex-prosper package. Feel free to tell me if you want it back. > > Best regards, > R. > ----- End forwarded message ----- -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jonathan.underwood at gmail.com Mon Sep 4 23:05:23 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 04 Sep 2006 23:05:23 -0000 Subject: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff) In-Reply-To: <1157400436.16129.134.camel@viper.local> References: <1157400436.16129.134.camel@viper.local> Message-ID: <645d17210609041605l273801a0g834a01effdbb3830@mail.gmail.com> On 04/09/06, Ville Skytt? wrote: > First, one plan is to split xemacs-sumo to two. The smaller bit, > xemacs-packages-base, will contain packages that upstream considers the > minimal set: xemacs-base, efs, and mule-base. This will be compiled > with xemacs-nox, and will be enough for people who choose to manage rest > of the upstream lisp packages using XEmacs's built in tools instead of > installing them from rpms. The second part, xemacs-packages, will > contain practically rest of the current sumo and it will be compiled > with the main X-enabled xemacs. These packages will not be called > "sumo" because they no longer quite represent what upstream calls sumo > either. Backwards compat Provides/Obsoletes will be there, naturally. > I think these packages would be much more sensibly named something like xemacs-sumo-base and xemacs-sumo-extras or somesuch - both should have sumo in the name. A package called xemacs-packages to Joe User might imply "install all xemacs packages that are available" i.e. some sort of meta package. sumo should definately be in the name. > Second part of the above plan is that the main xemacs package will no > longer have a dependency to xemacs-packages (ex-sumo, due to the build > dep loop above); it will have a dependency on xemacs-packages-base only. > Why is even this dependency necessary? Does upstream xemacs really require xemacs-sumo to build? If so, upstream should fix that, the xemacs tarball should build without the presence of xemacs-sumo. > So this is what it would look like (versions dropped for brevity): > > xemacs: dep on xemacs-common, xemacs-packages-base, provides xemacs(bin) > xemacs-nox: depends on xemacs-common, provides xemacs(bin) > xemacs-common: no xemacs* deps > xemacs-packages-base: depends on xemacs-common > xemacs-packages: depends on xemacs-packages-base To repeat - there is nothing in these package names that tells the user that sumo is installed. Also, please strip out the source .el files into separate packages, as is done with emacs. Best wishes, Jonathan From i.pilcher at comcast.net Sun Sep 17 14:43:38 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sun, 17 Sep 2006 09:43:38 -0500 Subject: Bump EVR for FC6 - dist tag? Message-ID: <450D5F1A.7030004@comcast.net> I was about to manually bump the release of wifi-radar, when I noticed the dist tag sitting there. Shouldn't it take care of the upgrade path? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From P at draigBrady.com Tue Sep 19 09:15:59 2006 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 19 Sep 2006 10:15:59 +0100 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <450FB54F.1080007@draigBrady.com> Ville Skytt? wrote: > Hi, > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > fslint Eek! This is the first I've heard about this. What do you require me to do the keep fslint in there? thanks, P?draig. From paul at xelerance.com Tue Sep 19 14:54:13 2006 From: paul at xelerance.com (Paul Wouters) Date: Tue, 19 Sep 2006 16:54:13 +0200 (CEST) Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: On Mon, 18 Sep 2006, Ville Skytt? wrote: > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > Cleanup of packages listed in not-treated.txt from the devel package > repo will start today. Changing their status to orphaned and removing > them from comps will be done a bit later gaim-otr does not build in mock. It seems the configure script is not generated. I cannot reproduce this, as it builds fine on my machines. So it is not a lack of maintaining that is causing gaim-otr to have not been rebuild. So please don't orphan the package. Paul From tcallawa at redhat.com Wed Sep 20 04:07:22 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 23:07:22 -0500 Subject: Bump EVR for FC6 - dist tag? In-Reply-To: <450D5F1A.7030004@comcast.net> References: <450D5F1A.7030004@comcast.net> Message-ID: <1158725242.6156.91.camel@localhost.localdomain> On Sun, 2006-09-17 at 09:43 -0500, Ian Pilcher wrote: > I was about to manually bump the release of wifi-radar, when I noticed > the dist tag sitting there. Shouldn't it take care of the upgrade path? If you've never built in devel before, yes. If you have, no. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From stickster at gmail.com Wed Sep 20 14:16:03 2006 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 20 Sep 2006 10:16:03 -0400 Subject: [Fwd: Release Notes freeze for FC6] Message-ID: <1158761763.10989.12.camel@localhost.localdomain> Oops, got the addy wrong in the original. Please keep reading... -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- An embedded message was scrubbed... From: "Paul W. Frields" Subject: Release Notes freeze for FC6 Date: Wed, 20 Sep 2006 10:01:05 -0400 Size: 2254 URL: -------------- 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 kwade at redhat.com Wed Sep 20 22:25:45 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Sep 2006 15:25:45 -0700 Subject: Final release notes deadline - 23 Sep Wiki freeze Message-ID: <1158791145.2714.334.camel@erato.phig.org> The release notes Wiki for FC6 are frozen on 23 Sep. 23:59 UTC for translation and inclusion in the ISO. This is your last chance to get content into the actual ISO. http://fedoraproject.org/wiki/Docs/Beats See below for a complete list of all beats that have no content for FC6[1]. These beats are going to be *dropped* from the final release notes, so no heading or content will appear. If you have anything that needs to be in the release notes, now is the time. After that, 07 Oct. is the next snapshot of the Wiki for the Web-only release of the notes. The Web-only release is not guaranteed to be translated. If you have filed any bugs or sent email to relnotes at fedoraproject.org, etc., that content is going to be included in the next few days. Any bugs must block 197471[2]. Best idea is to just edit the Wiki. :) Thanks again to all contributors; we set the bar high and once again made the hurdle to produce the best release notes in all Linux. - Karsten [1] Beats with no new content for FC6: http://fedoraproject.org/wiki/Docs/Beats/Printing http://fedoraproject.org/wiki/Docs/Beats/Samba http://fedoraproject.org/wiki/Docs/Beats/Security http://fedoraproject.org/wiki/Docs/Beats/DatabaseServers http://fedoraproject.org/wiki/Docs/Beats/ServerTools http://fedoraproject.org/wiki/Docs/Beats/Xorg http://fedoraproject.org/wiki/Docs/Beats/FileServers http://fedoraproject.org/wiki/Docs/Beats/PackageChanges http://fedoraproject.org/wiki/Docs/Beats/SystemDaemons http://fedoraproject.org/wiki/Docs/Beats/Legacy http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/x86 http://fedoraproject.org/wiki/Docs/Beats/Networking [2] https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=197471&hide_resolved=1 -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 Wed Sep 20 22:34:16 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 20 Sep 2006 17:34:16 -0500 Subject: Final release notes deadline - 23 Sep Wiki freeze In-Reply-To: <1158791145.2714.334.camel@erato.phig.org> References: <1158791145.2714.334.camel@erato.phig.org> Message-ID: <1158791656.28286.25.camel@localhost.localdomain> On Wed, 2006-09-20 at 15:25 -0700, Karsten Wade wrote: > The release notes Wiki for FC6 are frozen on 23 Sep. 23:59 UTC for > translation and inclusion in the ISO. This is your last chance to get > content into the actual ISO. > http://fedoraproject.org/wiki/Docs/Beats/PackageChanges I don't think any of the audit changes have been documented here. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From rc040203 at freenet.de Thu Sep 21 02:51:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Sep 2006 04:51:43 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158807103.24566.73.camel@mccallum.corsepiu.local> I would be happy to co-maintain and take care about rebuilding opencv should the maintainer not re-appear. Ralf From lmacken at redhat.com Thu Sep 21 04:00:36 2006 From: lmacken at redhat.com (Luke Macken) Date: Thu, 21 Sep 2006 00:00:36 -0400 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <20060921040035.GG7967@tomservo.nc.rr.com> On Mon, Sep 18, 2006 at 11:52:55PM +0300, Ville Skytt? wrote: [...] > python-cherrypy > python-cherrytemplate I will be taking these over. luke From nomis80 at nomis80.org Thu Sep 21 11:42:16 2006 From: nomis80 at nomis80.org (Simon Perreault) Date: Thu, 21 Sep 2006 07:42:16 -0400 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158807103.24566.73.camel@mccallum.corsepiu.local> References: <1158612775.2902.140.camel@viper.local> <1158807103.24566.73.camel@mccallum.corsepiu.local> Message-ID: <200609210742.16624.nomis80@nomis80.org> On Wednesday September 20 2006 22:51, Ralf Corsepius wrote: > I would be happy to co-maintain and take care about rebuilding > > opencv > > should the maintainer not re-appear. Go ahead. I confirm my awolness. From nphilipp at redhat.com Fri Sep 22 11:32:19 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 22 Sep 2006 13:32:19 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <1158924739.29188.17.camel@gibraltar.stuttgart.redhat.com> On Mon, 2006-09-18 at 23:52 +0300, Ville Skytt? wrote: > The deadline for the FE mass rebuild for FC6 was today, 153 packages > which are still in the devel (package) repo have not had their > needs.rebuild file treated in CVS. > > Attachments: > - not-treated.txt: the 153 packages above > - not-treated-already-removed.txt: not treated, but already removed > - not-treated-deps.txt: packages that have dependencies to the above or > subpackages of the above, but are not listed in the above As I use it regularly, I volunteer for NetworkManager-vpnc (unless davidz objects). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Sep 22 11:56:58 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Sep 2006 13:56:58 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158924739.29188.17.camel@gibraltar.stuttgart.redhat.com> References: <1158612775.2902.140.camel@viper.local> <1158924739.29188.17.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20060922135658.7759273e@python3.es.egwn.lan> Nils Philippsen wrote : > On Mon, 2006-09-18 at 23:52 +0300, Ville Skytt? wrote: > > > The deadline for the FE mass rebuild for FC6 was today, 153 packages > > which are still in the devel (package) repo have not had their > > needs.rebuild file treated in CVS. > > > > Attachments: > > - not-treated.txt: the 153 packages above > > - not-treated-already-removed.txt: not treated, but already removed > > - not-treated-deps.txt: packages that have dependencies to the above or > > subpackages of the above, but are not listed in the above > > As I use it regularly, I volunteer for NetworkManager-vpnc (unless > davidz objects). Bill Nottingham has already said on Tuesday (on extras-list) he'd take it over. Check with him first ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.17-1.2647.fc6 Load : 0.52 0.24 0.12 From jamatos at fc.up.pt Fri Sep 22 12:05:46 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 22 Sep 2006 13:05:46 +0100 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060921040035.GG7967@tomservo.nc.rr.com> References: <1158612775.2902.140.camel@viper.local> <20060921040035.GG7967@tomservo.nc.rr.com> Message-ID: <200609221305.47070.jamatos@fc.up.pt> On Thursday 21 September 2006 05:00, Luke Macken wrote: > I will be taking these over. Just for the record I agree. > luke -- Jos? Ab?lio From notting at redhat.com Fri Sep 22 16:16:00 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Sep 2006 12:16:00 -0400 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060922135658.7759273e@python3.es.egwn.lan> References: <1158612775.2902.140.camel@viper.local> <1158924739.29188.17.camel@gibraltar.stuttgart.redhat.com> <20060922135658.7759273e@python3.es.egwn.lan> Message-ID: <20060922161600.GA15947@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > As I use it regularly, I volunteer for NetworkManager-vpnc (unless > > davidz objects). > > Bill Nottingham has already said on Tuesday (on extras-list) he'd take > it over. Check with him first ;-) David told me off-list he was going to rebuild it. Bill From SteveD at redhat.com Fri Sep 22 18:01:56 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 14:01:56 -0400 Subject: Please add autoconf and automake to the buildroot Message-ID: <45142514.1000109@RedHat.com> Recently when trying to get out an rpm, a patch to a Makefile.am was not being applied because automake was not installed. The unapplied patch had to do with a version problem in which other rpms were depended on. Now the only way to tell that the rpm was corrupted was to install it and have a number of other rpms break.... Now the reason the patch was not applied was because the upstream configuration script *did not* fail when automake was not found, instead it used an already existing Makefile which caused the corruption. The truly scary part of this, was there was not one failure or warning or any type of signal that rpm was corrupted... This is not good... Yes... adding a build requirement did indeed fix the problem, but thats not point... The point is by not installing some of the most used package configuration tools (i.e. autoconf and automake), the build process has a huge whole in which silent failures of configuration patches can cause *undetectable* corrupted rpms that will land on our user's systems. Now I understand keeping the size of the build roots is important especially since they are now dynamic... but again... autoconf and automake are two most common build tools there are and not having them creates a hole that will continue plague us, especially with new packages... So please adding these very small but highly used packages to close the rpm corruption hole in the build process.... steved. From dennis at ausil.us Fri Sep 22 18:12:22 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Sep 2006 13:12:22 -0500 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142514.1000109@RedHat.com> References: <45142514.1000109@RedHat.com> Message-ID: <200609221312.22701.dennis@ausil.us> On Friday 22 September 2006 13:01, Steve Dickson wrote: > Yes... adding a build requirement did indeed fix the problem, but > thats not point... The point is by not installing some of the most > used package configuration tools (i.e. autoconf and automake), > the build process has a huge whole in which silent failures > of configuration patches can cause *undetectable* corrupted rpms > that will land on our user's systems. it is fairly well documented in the wiki the changes in the new build root and it has been tested alot. the guidelines are pretty clear on what is and is not included by default. If you call autoconf or outomake then you need to BR them its fairly simple. The problem should have shown up in your local mock build before you committed the build. Dennis From paul at city-fan.org Fri Sep 22 18:13:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 22 Sep 2006 19:13:56 +0100 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142514.1000109@RedHat.com> References: <45142514.1000109@RedHat.com> Message-ID: <1158948837.23008.4.camel@metropolis.intra.city-fan.org> On Fri, 2006-09-22 at 14:01 -0400, Steve Dickson wrote: > Recently when trying to get out an rpm, a patch to a Makefile.am was not > being applied because automake was not installed. The unapplied patch > had to do with a version problem in which other rpms were depended on. > Now the only way to tell that the rpm was corrupted was to > install it and have a number of other rpms break.... > > Now the reason the patch was not applied was because the upstream > configuration script *did not* fail when automake was not found, > instead it used an already existing Makefile which caused the > corruption. The truly scary part of this, was there was > not one failure or warning or any type of signal that rpm > was corrupted... This is not good... > > Yes... adding a build requirement did indeed fix the problem, but > thats not point... The point is by not installing some of the most > used package configuration tools (i.e. autoconf and automake), > the build process has a huge whole in which silent failures > of configuration patches can cause *undetectable* corrupted rpms > that will land on our user's systems. > > Now I understand keeping the size of the build roots is important > especially since they are now dynamic... but again... autoconf and > automake are two most common build tools there are and not having > them creates a hole that will continue plague us, especially > with new packages... > > So please adding these very small but highly used packages to close > the rpm corruption hole in the build process.... On the other hand, by including autotools in the minimal buildroot, people get away with not adding them as buildreqs of packages that need them, which would then have the result that people trying to rebuild these packages for themselves on systems without autotools installed would come across these tricky problems, and probably be less able to figure out what the problem is. So my vote would be keep the status quo; packagers patching autotools input files should either buildreq autotools, or, better still, also patch the autotools generated files so that the autotools aren't needed for the package build. Paul. From sgrubb at redhat.com Fri Sep 22 18:18:52 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 22 Sep 2006 14:18:52 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142514.1000109@RedHat.com> References: <45142514.1000109@RedHat.com> Message-ID: <200609221418.52338.sgrubb@redhat.com> On Friday 22 September 2006 14:01, Steve Dickson wrote: > Now the reason the patch was not applied was because the upstream > configuration script *did not* fail when automake was not found, > instead it used an already existing Makefile which caused the > corruption. If you patch Makefile.am, aren't you supposed to call automake, autoconf, & aclocal again to regenerate the Makefile.in & configure scripts? Your build should have failed calling them if you did not BR it. -Steve From SteveD at redhat.com Fri Sep 22 18:43:17 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 14:43:17 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <200609221312.22701.dennis@ausil.us> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> Message-ID: <45142EC5.3050703@RedHat.com> Dennis Gilmore wrote: > the guidelines are pretty clear on what is and is not included by default. If > you call autoconf or outomake then you need to BR them its fairly simple. > The problem should have shown up in your local mock build before you > committed the build. Thats the point... nothing error-ed out because there was an outdated makefile that already existed and so it was used... Again, this is an *undetectable* situation that will cause rpm corruption but is easily fixed by simply adding autoconf and automake to the buildroot.. steved. From SteveD at redhat.com Fri Sep 22 18:45:50 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 14:45:50 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <200609221418.52338.sgrubb@redhat.com> References: <45142514.1000109@RedHat.com> <200609221418.52338.sgrubb@redhat.com> Message-ID: <45142F5E.4060603@RedHat.com> Steve Grubb wrote: > If you patch Makefile.am, aren't you supposed to call automake, autoconf, & > aclocal again to regenerate the Makefile.in & configure scripts? Your build > should have failed calling them if you did not BR it. Again the point is the didn't fail because old, outdated configure files were used... steved. From coldwell at redhat.com Fri Sep 22 18:49:30 2006 From: coldwell at redhat.com (Chip Coldwell) Date: Fri, 22 Sep 2006 14:49:30 -0400 (EDT) Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142F5E.4060603@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221418.52338.sgrubb@redhat.com> <45142F5E.4060603@RedHat.com> Message-ID: On Fri, 22 Sep 2006, Steve Dickson wrote: > > > Steve Grubb wrote: >> If you patch Makefile.am, aren't you supposed to call automake, autoconf, & >> aclocal again to regenerate the Makefile.in & configure scripts? Your build >> should have failed calling them if you did not BR it. > Again the point is the didn't fail because old, outdated configure > files were used... The situation is a bit more subtle here. If a configure script discovers that the configure.in template is newer, it automatically runs autoconf to regenerate itself. (Similarly for Makefile.am and Makefile). That is, unless there is no autoconf, in which case it proceeds silently to (mis-)configure the build. One could argue (as Steve does) that since the rpm %configure macro implicitly invokes autoconf/automake, they should be part of the build root. I agree with Steve on this. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jkeating at redhat.com Fri Sep 22 18:49:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Sep 2006 14:49:32 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142EC5.3050703@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> Message-ID: <200609221449.32900.jkeating@redhat.com> On Friday 22 September 2006 14:43, Steve Dickson wrote: > Thats the point... nothing error-ed out because there was an > outdated makefile that already existed and so it was used... > Again, this is an *undetectable* situation that will cause > rpm corruption but is easily fixed by simply adding autoconf > and automake to the buildroot.. Or more properly it could be fixed by BuildRequiring it as you _know_ that you'll need to run autoconf. Assuming that a version of autoconf/make is already in the buildroot that would be suitable for your needs is a bad assumption to make. It's a bummer your package broke, but its a good time to fix your package. -- 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 ajackson at redhat.com Fri Sep 22 18:48:08 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 22 Sep 2006 14:48:08 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142EC5.3050703@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> Message-ID: <45142FE8.4030106@redhat.com> Steve Dickson wrote: > Dennis Gilmore wrote: >> the guidelines are pretty clear on what is and is not included by >> default. If you call autoconf or outomake then you need to BR them >> its fairly simple. The problem should have shown up in your local >> mock build before you committed the build. > Thats the point... nothing error-ed out because there was an > outdated makefile that already existed and so it was used... > Again, this is an *undetectable* situation that will cause > rpm corruption but is easily fixed by simply adding autoconf > and automake to the buildroot.. You patched Makefile.am, but didn't re-run automake? Your packaging already had a bug then. - ajax From SteveD at redhat.com Fri Sep 22 19:01:06 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 15:01:06 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142FE8.4030106@redhat.com> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> <45142FE8.4030106@redhat.com> Message-ID: <451432F2.8030609@RedHat.com> Adam Jackson wrote: > Steve Dickson wrote: >> Dennis Gilmore wrote: >>> the guidelines are pretty clear on what is and is not included by >>> default. If you call autoconf or outomake then you need to BR them >>> its fairly simple. The problem should have shown up in your local >>> mock build before you committed the build. >> Thats the point... nothing error-ed out because there was an >> outdated makefile that already existed and so it was used... >> Again, this is an *undetectable* situation that will cause >> rpm corruption but is easily fixed by simply adding autoconf >> and automake to the buildroot.. > > You patched Makefile.am, but didn't re-run automake? Your packaging > already had a bug then. I agree with both you and Jessie in the fact that it was a bug in my spec file, but that not the point... This point is there is a huge hole in the build process that will silently and cleanly produce a severely corrupted rpm that can have a ripple effect on the entire system... And there is an incredibly easy way to close that hole by simply adding two very small but highly used packages... I really don't seen the problem with this... steved. From a.badger at gmail.com Fri Sep 22 19:01:12 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 Sep 2006 12:01:12 -0700 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45142EC5.3050703@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> Message-ID: <1158951672.2866.5.camel@localhost> On Fri, 2006-09-22 at 14:43 -0400, Steve Dickson wrote: > > Dennis Gilmore wrote: > > the guidelines are pretty clear on what is and is not included by default. If > > you call autoconf or outomake then you need to BR them its fairly simple. > > The problem should have shown up in your local mock build before you > > committed the build. > Thats the point... nothing error-ed out because there was an > outdated makefile that already existed and so it was used... > Again, this is an *undetectable* situation that will cause > rpm corruption but is easily fixed by simply adding autoconf > and automake to the buildroot.. Where's your SRPM? It's hard to tell whether it is the case that autoconf and automake need to be installed in the buildroot or if there need to be other changes without your failure case. BTW, Steve Grubb and Paul Howarth had some points that I hope you reply to. -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 Fri Sep 22 19:18:09 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Sep 2006 15:18:09 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <451432F2.8030609@RedHat.com> References: <45142514.1000109@RedHat.com> <45142FE8.4030106@redhat.com> <451432F2.8030609@RedHat.com> Message-ID: <200609221518.09832.jkeating@redhat.com> On Friday 22 September 2006 15:01, Steve Dickson wrote: > This point is there is a huge hole in the build process that > will silently and cleanly produce a severely corrupted rpm > that can have a ripple effect on the entire system... And > there is an incredibly easy way to close that hole by simply > adding two very small but highly used packages... I really > don't seen the problem with this... The same hyperbole can be said of any package that doesn't list a BuildRequires it needs. It will silently build and have missing functionality. Without diligent checking of the results we would miss this. Should we then just do everything installs into the buildroots so that we won't miss any functionality? No, we properly list the BuildRequires so that we have the appropriate functionality we seek. The answer is not to continue fattening the buildroots and making assumptions, the answer is to use correct packaging, correct post build QA. -- 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 SteveD at redhat.com Fri Sep 22 19:36:02 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 15:36:02 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1158948837.23008.4.camel@metropolis.intra.city-fan.org> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> Message-ID: <45143B22.7070605@RedHat.com> Paul Howarth wrote: > > On the other hand, by including autotools in the minimal buildroot, > people get away with not adding them as buildreqs of packages that need > them, which would then have the result that people trying to rebuild > these packages for themselves on systems without autotools installed > would come across these tricky problems, and probably be less able to > figure out what the problem is. point... and not having the correct buildreqs in the spec file would be a bug in the spec file... and the person should report it as such... but that is not a reason to leave a corruption hole in our build process that can potentially destroy a system with a corrupt rpm... imho... > > So my vote would be keep the status quo; packagers patching autotools > input files should either buildreq autotools, or, better still, also > patch the autotools generated files so that the autotools aren't needed > for the package build. Patching the autotool generated files is not a good idea imho... You basically saying don't use *any* of the autoconf tools and just hack things to work... I've been down that path and I have found those hack become very unmaintainable in a very short time... It it much much easy to simple patch the autoconf files and rerun the tools.. steved. From a.badger at gmail.com Fri Sep 22 19:38:48 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 Sep 2006 12:38:48 -0700 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <451432F2.8030609@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> <45142FE8.4030106@redhat.com> <451432F2.8030609@RedHat.com> Message-ID: <1158953928.2866.25.camel@localhost> On Fri, 2006-09-22 at 15:01 -0400, Steve Dickson wrote: > > Adam Jackson wrote: > > Steve Dickson wrote: > >> Dennis Gilmore wrote: > >>> the guidelines are pretty clear on what is and is not included by > >>> default. If you call autoconf or outomake then you need to BR them > >>> its fairly simple. The problem should have shown up in your local > >>> mock build before you committed the build. > >> Thats the point... nothing error-ed out because there was an > >> outdated makefile that already existed and so it was used... > >> Again, this is an *undetectable* situation that will cause > >> rpm corruption but is easily fixed by simply adding autoconf > >> and automake to the buildroot.. > > > > You patched Makefile.am, but didn't re-run automake? Your packaging > > already had a bug then. > I agree with both you and Jessie in the fact that it was a bug > in my spec file, but that not the point... > > This point is there is a huge hole in the build process that > will silently and cleanly produce a severely corrupted rpm > that can have a ripple effect on the entire system... And > there is an incredibly easy way to close that hole by simply > adding two very small but highly used packages... I really > don't seen the problem with this... AFAIK they are very rarely used. One of autoconf's design goals is to not be needed from the dist tarball. I don't think automake makes this same guarantee but it makes an attempt. The buggy package was created by the bug in your spec and the question is whether there's any difference between this case and any other missing optional BuildRequire. -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 Sep 22 19:41:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Sep 2006 15:41:50 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: References: <45142514.1000109@RedHat.com> <200609221418.52338.sgrubb@redhat.com> <45142F5E.4060603@RedHat.com> Message-ID: <20060922194150.GA18315@nostromo.devel.redhat.com> Chip Coldwell (coldwell at redhat.com) said: > One could argue (as Steve does) that since the rpm %configure macro > implicitly invokes autoconf/automake, they should be part of the build > root. AFAIK, %configure does *not* invoke autoconf/automake. Bill From jakub at redhat.com Fri Sep 22 19:44:21 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 22 Sep 2006 15:44:21 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45143B22.7070605@RedHat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> Message-ID: <20060922194421.GC12531@devserv.devel.redhat.com> On Fri, Sep 22, 2006 at 03:36:02PM -0400, Steve Dickson wrote: > Patching the autotool generated files is not a good idea imho... I disagree. You should use autoconf/automake when you create the patch, but not at package build time. There are plenty of incompatible autoconf and automake versions, trusting that autoconf and/or automake in the buildroot happens to do the right thing with source written often for a different version of the autoconf/automake is overly optimistic. When autoconf generated output put the line numbers into configure script, patching it wasn't easy, but now that $LINENO is used, things work just fine when the patches include even changes to generated files. Jakub From jkeating at redhat.com Fri Sep 22 19:43:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Sep 2006 15:43:42 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45143B22.7070605@RedHat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> Message-ID: <200609221543.42974.jkeating@redhat.com> On Friday 22 September 2006 15:36, Steve Dickson wrote: > It it much much easy to simple patch the autoconf files and > rerun the tools.. But you didn't rerun the tools. You assumed that the buildprocess would and that assumption failed because you didn't ensure that automake/conf was in the buildroot. Had you explicitly ran automake, your build would have failed as the command wouldn't have been available. -- 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 pertusus at free.fr Fri Sep 22 19:43:47 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 22 Sep 2006 21:43:47 +0200 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45143B22.7070605@RedHat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> Message-ID: <20060922194347.GA2397@free.fr> On Fri, Sep 22, 2006 at 03:36:02PM -0400, Steve Dickson wrote: > > Patching the autotool generated files is not a good idea imho... > You basically saying don't use *any* of the autoconf tools and just > hack things to work... Not necessarily, the autotools have allready allready been used and the configure and Makefile.in should allready be in a good portability state. > I've been down that path and I have found > those hack become very unmaintainable in a very short time... > It it much much easy to simple patch the autoconf files and > rerun the tools.. It may be true when the configure and Makefile.in files have been generated with the same or similar autotool versions, but when it is not the case it is really asking for trouble. -- Pat From pertusus at free.fr Fri Sep 22 19:47:13 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 22 Sep 2006 21:47:13 +0200 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1158953928.2866.25.camel@localhost> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> <45142FE8.4030106@redhat.com> <451432F2.8030609@RedHat.com> <1158953928.2866.25.camel@localhost> Message-ID: <20060922194713.GB2397@free.fr> > > AFAIK they are very rarely used. One of autoconf's design goals is to > not be needed from the dist tarball. I don't think automake makes this > same guarantee but it makes an attempt. automake makes exactly the same guarantee. It is in perl, and perl isn't meant to be in all the environments. autoconf/automake dist should require only sh, make and basic unix commands. -- Pat From SteveD at redhat.com Fri Sep 22 19:53:37 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 15:53:37 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <200609221518.09832.jkeating@redhat.com> References: <45142514.1000109@RedHat.com> <45142FE8.4030106@redhat.com> <451432F2.8030609@RedHat.com> <200609221518.09832.jkeating@redhat.com> Message-ID: <45143F41.8050003@RedHat.com> Jesse Keating wrote: > The same hyperbole can be said of any package that doesn't list a > BuildRequires it needs. It will silently build and have missing > functionality. Without diligent checking of the results we would miss this. > Should we then just do everything installs into the buildroots so that we > won't miss any functionality? Of courses not... I think keeping a very small and condense buildroot is the right thing to do... And we should not be adding things to the buildroot to fix bugs... > No, we properly list the BuildRequires so that > we have the appropriate functionality we seek. The answer is not to continue > fattening the buildroots and making assumptions, the answer is to use correct > packaging, correct post build QA. Again I totally agree with you... but the question at what price? Is worth keep an buildroot the so small that it has the potential of silently creating corrupt rpms? Especially with the fix being as simple as adding two of the most common package used to do package configuration? I think the price of not added those two package much much more expensive than the disk space they will use... There is an old saying that comes to mind... penny wise and pound foolish... which I think applies here... steved. From jkeating at redhat.com Fri Sep 22 20:32:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Sep 2006 16:32:04 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45143F41.8050003@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> Message-ID: <200609221632.07777.jkeating@redhat.com> On Friday 22 September 2006 15:53, Steve Dickson wrote: > Again I totally agree with you... but the question at what price? > Is worth keep an buildroot the so small that it has the potential of > silently creating corrupt rpms? Especially with the fix being as simple > as adding two of the most common package used to do package > configuration? I think the price of not added those two package > much much more expensive than the disk space they will use... I don't accept your claim that these are the most common used packages to build our rpms. Sure they're used upstream and such, but not in our rpm build process. They should be viewed just like any other build requirement and listed as such. For you its two auto* packages. To somebody else, it's just pkgconfig, to yet another person its just intltool and gettext, so on and so forth. The line has to be drawn somewhere and it has been drawn. -- 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 tromey at redhat.com Fri Sep 22 20:58:29 2006 From: tromey at redhat.com (Tom Tromey) Date: 22 Sep 2006 14:58:29 -0600 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1158953928.2866.25.camel@localhost> References: <45142514.1000109@RedHat.com> <200609221312.22701.dennis@ausil.us> <45142EC5.3050703@RedHat.com> <45142FE8.4030106@redhat.com> <451432F2.8030609@RedHat.com> <1158953928.2866.25.camel@localhost> Message-ID: >>>>> "Toshio" == Toshio Kuratomi writes: Toshio> One of autoconf's design goals is to Toshio> not be needed from the dist tarball. I don't think automake makes this Toshio> same guarantee but it makes an attempt. Automake does make this guarantee. Tom From pertusus at free.fr Fri Sep 22 21:06:41 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 22 Sep 2006 23:06:41 +0200 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <200609221632.07777.jkeating@redhat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> Message-ID: <20060922210641.GC2397@free.fr> On Fri, Sep 22, 2006 at 04:32:04PM -0400, Jesse Keating wrote: > I don't accept your claim that these are the most common used packages to > build our rpms. Sure they're used upstream and such, but not in our rpm > build process. They should be viewed just like any other build requirement > and listed as such. For you its two auto* packages. To somebody else, it's > just pkgconfig, to yet another person its just intltool and gettext, so on > and so forth. The line has to be drawn somewhere and it has been drawn. I agree, and I also would like to point out that having to resort to a call to the autotools may be usefull, but in any case shows an issue in the upstream package. Therefore I think it is a good thing to require an explicit move of the packager as a remainder that something is wrong, and that it should better be fixed upstream. -- Pat From kzak at redhat.com Fri Sep 22 22:09:09 2006 From: kzak at redhat.com (Karel Zak) Date: Sat, 23 Sep 2006 00:09:09 +0200 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <20060922194421.GC12531@devserv.devel.redhat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> <20060922194421.GC12531@devserv.devel.redhat.com> Message-ID: <20060922220909.GH29409@petra.dvoda.cz> On Fri, Sep 22, 2006 at 03:44:21PM -0400, Jakub Jelinek wrote: > On Fri, Sep 22, 2006 at 03:36:02PM -0400, Steve Dickson wrote: > > Patching the autotool generated files is not a good idea imho... I agree ;-) > I disagree. You should use autoconf/automake when you create the > patch, but not at package build time. There are plenty of incompatible > autoconf and automake versions, trusting that autoconf and/or automake This is **regression** for stable distribution. We are patching against an exactly defined environment (=distribution). I hope we can believe that gcc and autotools are enough stable durring distribution lifetime. Karel -- Karel Zak From SteveD at redhat.com Fri Sep 22 23:57:40 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 19:57:40 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <200609221632.07777.jkeating@redhat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> Message-ID: <45147874.80704@RedHat.com> Jesse Keating wrote: > I don't accept your claim that these are the most common used packages to > build our rpms. These tools have been around since the early days of UNIX and have been used every since... so whether you accept that or not is.... well... indifferent... > They should be viewed just like any other build requirement > and listed as such. For you its two auto* packages. To somebody else, it's > just pkgconfig, to yet another person its just intltool and gettext, so on > and so forth. The line has to be drawn somewhere and it has been drawn. Personally I think we should a bit more flexible and open to consider adding packages that have very real potential of stopping undetectable rpm corruption. Call me crazy... but I think thats a good idea verses sticking to a policy that allows corruption... steved. From a.badger at gmail.com Sat Sep 23 01:02:54 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 Sep 2006 18:02:54 -0700 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45147874.80704@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> Message-ID: <1158973374.2866.75.camel@localhost> On Fri, 2006-09-22 at 19:57 -0400, Steve Dickson wrote: > Jesse Keating wrote: > > I don't accept your claim that these are the most common used packages to > > build our rpms. > These tools have been around since the early days of UNIX and > have been used every since... so whether you accept that or not > is.... well... indifferent... Actually, that's a falsehood. UNIX has been around much longer than autoconf and automake. autoconf had just gained enough momentum when I started using Linux in 1994 to look like it would indeed be able to replace the previous generation of IMakefiles. automake wasn't even born until later that year. On a less tangential note, you're missing Jesse's point. Autoconf and automake are used create the configure script and the Makefile.in's. As Patrice and Tom Tromey were quick to assure us, automake is not needed on the system where the dist tarball is unpacked and written. Our build system doesn't use them on the vast majority of packages that it creates. Only when you change the build source files (Makefile.am, configure.ac, etc) do you have to run the autotools to regenerate the build scripts. At that point, it really is your responsibility to make sure you run the programs from your spec file and BuildRequire them. > > > They should be viewed just like any other build requirement > > and listed as such. For you its two auto* packages. To somebody else, it's > > just pkgconfig, to yet another person its just intltool and gettext, so on > > and so forth. The line has to be drawn somewhere and it has been drawn. > Personally I think we should a bit more flexible and open to consider > adding packages that have very real potential of stopping undetectable > rpm corruption. Call me crazy... but I think thats a good idea verses > sticking to a policy that allows corruption... You haven't addressed Paul's point that it's easier for us (we're supposed to be knowledgable packagers, right?) to detect these errors than for people downloading the SRPM and rebuilding in their local environment to do so. You also haven't addressed Jesse's points that this applies to many other packages besides autoconf and automake (what makes this case exceptional?) or his point that part of being a packager is to look over the build logs to be sure your package not only built but built the way you expected it to. ad absurdum: because mono allows cross platform assemblies some mono packages ship from upstream with prebuilt assemblies. If the mono compile tools are not present on the system, these prebuilt assemblies may be used to construct the package. This can open a security hole if an upstream package includes assemblies that weren't actually generated from the source code. Should we include the mono stack to cover this? If you think that autoconf and automake should require an extra level of error checking, you might also consider writing a test for rpmlint that checks patches for changes to Makefile.am, configure.ac, etc, and if it finds some, makes sure that the spec file calls autoconf, automake, or autoreconf. This can benefit people who are not using our particular buildsystem as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From SteveD at redhat.com Sat Sep 23 02:05:32 2006 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 22 Sep 2006 22:05:32 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1158973374.2866.75.camel@localhost> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> <1158973374.2866.75.camel@localhost> Message-ID: <4514966C.1030300@RedHat.com> Toshio Kuratomi wrote: > You haven't addressed Paul's point that it's easier for us (we're > supposed to be knowledgable packagers, right?) to detect these errors > than for people downloading the SRPM and rebuilding in their local > environment to do so. In this particular case it wouldn't be ways for either them or us because the errors are undetectable... but I truly doubt their locally build rpm will end up on thousands of desktop via yum marrying corrupting machines as they go. The point being we should put in safeguards in that will stop us from sending out corrupted rpms and by adding those packages we are doing just that... imho.. > You also haven't addressed Jesse's points that > this applies to many other packages besides autoconf and automake (what > makes this case exceptional?) They stop undetectable RPM corruption... > or his point that part of being a packager > is to look over the build logs to be sure your package not only built > but built the way you expected it to. And me tell why its not a broken build system when we have to scour over successful build logs looking for data corrupters... > > ad absurdum: because mono allows cross platform assemblies some mono > packages ship from upstream with prebuilt assemblies. If the mono > compile tools are not present on the system, these prebuilt assemblies > may be used to construct the package. This can open a security hole if > an upstream package includes assemblies that weren't actually generated > from the source code. Should we include the mono stack to cover this? Sorry I'm not familiar mono... > > If you think that autoconf and automake should require an extra level of > error checking, you might also consider writing a test for rpmlint that > checks patches for changes to Makefile.am, configure.ac, etc, and if it > finds some, makes sure that the spec file calls autoconf, automake, or > autoreconf. This can benefit people who are not using our particular > buildsystem as well. Or just add two very small, highly used packages to the buildroot. ;-) steved. From Matt_Domsch at dell.com Sat Sep 23 02:16:33 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 22 Sep 2006 21:16:33 -0500 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45147874.80704@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> Message-ID: <20060923021633.GA21960@lists.us.dell.com> On Fri, Sep 22, 2006 at 07:57:40PM -0400, Steve Dickson wrote: > Personally I think we should a bit more flexible and open to consider > adding packages that have very real potential of stopping undetectable > rpm corruption. Call me crazy... but I think thats a good idea verses > sticking to a policy that allows corruption... >From the early days of the rebuilds, in my private rebuild system that I've been publishing results from weekly, I've posted the rpmdiffs for each and every package that built - diff of package as found in the pre-mock rawhide vs what came out of mock. This was done explicitly so folks could see if the mock builds made substantially different packages than the non-mock builds. I know I looked at those files to be sure my own packages were building consistently, I'm sure others did too. This was done in hopes of detecting the "undetectable rpm corruption" issues exactly like this. http://linux.dell.com/files/fedora/FixBuildRequires/ Now that everything from buildsys.fedoraproject.org has been rebuilt using mock, there's probably little benefit to doing so. But there was, and it's trivial do to. Perhaps I should have pointed this out more frequently and loudly, with nagmails etc, but I didn't want to flood people (early on in May-June, I published the results every couple days). -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tromey at redhat.com Sat Sep 23 02:27:35 2006 From: tromey at redhat.com (Tom Tromey) Date: 22 Sep 2006 20:27:35 -0600 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <20060922194421.GC12531@devserv.devel.redhat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> <20060922194421.GC12531@devserv.devel.redhat.com> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: Jakub> You should use autoconf/automake when you create the Jakub> patch, but not at package build time. I agree, due to the versioning problem. It looks like there are 5 versions of automake in active use ("yum list automake*")... That isn't a good situation, but assuming that the one named 'automake' will work with the current package is not a robust assumption. It doesn't seem to be a big deal to either BuildRequire the specific needed version, or to include the configure/Makefile.in/etc bits in the patch. Also ideally, upstream packagers would move to more recent auto* releases. Updating from automake 1.[678] to 1.9 is generally not a big deal. Autoconf upgrades, or automake 1.[45]->1.9 upgrades, can be harder. Tom From adrian at lisas.de Sat Sep 23 08:39:02 2006 From: adrian at lisas.de (Adrian Reber) Date: Sat, 23 Sep 2006 10:39:02 +0200 Subject: libcdio update Message-ID: <20060923083902.GA30079@lisas.de> I will update libcdio to 0.77 in the extras development repository. With this update the soname changes and all dependencies have to be rebuilt. I have already contacted the maintainers which are affected by this change. Adrian From fedora at leemhuis.info Sat Sep 23 14:00:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 23 Sep 2006 16:00:15 +0200 Subject: List of inactive members in cvsextras that will be removed soon Message-ID: <45153DEF.2050406@leemhuis.info> Hi, I did a check for inactive extras contributors now that the mass-rebuild is done. It was agreed on by FESCo that all inactive contributors will get removed from the cvsextras group in the accountssystem (they won't have access to extras-cvs in the future due to this) -- they of course will stay in cladone and can be re-added to cvsextras easily. That will a new sponsorship-process normally, but FESCo can make exceptions on a case-by-case basis. I produced the list with roughly this commands: > wget -O - -q https://www.redhat.com/archives/fedora-extras-commits/2006-September.txt.gz https://www.redhat.com/archives/fedora-extras-commits/2006-August.txt.gz | zcat | grep '^Author: ' | sed 's/Author: //' | tr A-Z a-z | sort | uniq > list_of_active_maintainers > wget -O - -q 'https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&format=txt' | sed 's/,/ /' | awk '{print $1}' | tr A-Z a-z > list_of_cvsextrasmembers > diff -u list_of_active_maintainers list_of_cvsextrasmembers | grep -e '^+' | sed 's/+//' | grep -w -e "buildsys" -e "sopwith" -e "gdk" > list_of_inactive_maintainers > wget -O - -q 'https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&format=txt' | sed 's/,/ /g' | grep -w -f list_of_inactive_maintainers >list_of_inactive_maintainers_with_mail Maybe this hit some false-positives. So here is the list up for review and comments before I go into the accounts system (I'll probably do this on monday night CEST) and remove people accidentally (people that were removed accidentally of course will be re-added without going though the sponsorship process). Here is the list (some false-positives that I know of were removed: jspaleta for example), slitted into those with and without redhat.com in the email-address: ankit ankit644_AT_yahoo.com Ankit Patel user 0 aoliva oliva_AT_lsd.ic.unicamp.br Alexandre Oliva user 0 bluekuja bluekuja_AT_ubuntu.com Andrea Veri user 0 byte byte_AT_aeon.com.my Colin Charles user 0 cra cra_AT_WPI.EDU Charles R. Anderson user 0 danielm daner964_AT_student.liu.se Daniel Malmgren user 0 davea davea_AT_sucs.org Dave Arter user 0 didier didier_AT_microtronyx.com Didier F.B. Casse user 0 dmoser derrick_moser_AT_yahoo.com Derrick Moser user 0 dnielsen david_AT_lovesunix.net David Nielsen user 0 ellson ellson_AT_research.att.com John Ellson user 0 eyecon DavidHart_AT_TQMcube.com David Cary Hart user 0 gijs gijs_AT_gewis.nl Gijs Hollestelle user 0 hunter thm_AT_duke.edu Hunter Matthews user 0 iprone hula-kevin_AT_iprone.com Kevin Gray user 0 ivazquez ivazquez_AT_ivazquez.net Ignacio Vazquez-Abrams sponsor 4 jjneely jjneely_AT_ncsu.edu Jack Neely user 0 kjcole kjcole_AT_gri.gallaudet.edu Kevin Cole user 0 ksfiles ksfiles_AT_gmail.com Kirby Files user 0 mariuslj mariuslj_AT_student.matnat.uio.no Marius L. J?hndal sponsor 0 mickael dreadyman_AT_gmail.com Mickael Bailly user 0 mjs menno_AT_freshfoo.com Menno Smits user 0 mpeters mpeters_AT_mac.com Michael A. Peters user 0 noa noa_AT_resare.com Noa Resare user 0 nomis80 nomis80_AT_nomis80.org Simon Perreault user 0 oa oliver.andrich_AT_gmail.com Oliver Andrich user 0 salimma michel.salim_AT_gmail.com Michel Alexandre Salim user 0 smooge smooge_AT_mindspring.com Stephen J Smoogen user 0 symbiont symbiont_AT_berlios.de Jeffrey Robert Pitman user 0 tamaster tamaster_AT_pobox.com Gregory Lynn Houlette user 0 tbandi72 toth_bandi_AT_users.sourceforge.net Andr?s T?th user 0 twillber toniw_AT_iki.fi Toni Willberg user 0 aluchko aluchko_AT_redhat.com Aaron Luchko user 0 behdad besfahbo_AT_redhat.com Behdad Esfahbod user 0 caolanm caolanm_AT_redhat.com Caolan McNamara user 0 davej davej_AT_redhat.com Dave Jones user 0 davidz davidz_AT_redhat.com David Zeuthen user 0 dcantrel dcantrell_AT_redhat.com David Cantrell user 0 dledford dledford_AT_redhat.com Doug Ledford user 0 dwalsh dwalsh_AT_redhat.com Daniel J Walsh user 0 harald harald_AT_redhat.com Harald Hoyer user 0 jmasters jcm_AT_redhat.com Jon Masters user 0 jparsons jparsons_AT_redhat.com Jim Parsons user 0 jrb jrb_AT_redhat.com Jonathan Blandford user 0 kwade kwade_AT_redhat.com Karsten Wade user 0 laroche laroche_AT_redhat.com Florian La Roche user 0 markmc markmc_AT_redhat.com Mark McLoughlin user 0 mharmsen mharmsen_AT_redhat.com Matthew Harmsen user 0 otaylor otaylor_AT_redhat.com Owen Taylor user 0 qshen qshen_AT_redhat.com Qian Shen user 0 qwang qwang_AT_redhat.com Qingyu Wang user 0 riel riel_AT_redhat.com Rik van Riel user 0 rstrode rstrode_AT_redhat.com Ray Strode sponsor 0 sgrubb sgrubb_AT_redhat.com Steve Grubb user 0 sundaram sundaram_AT_redhat.com Rahul Sundaram user 0 tfox tfox_AT_redhat.com Tammy Fox user 0 than than_AT_redhat.com Than Ngo user 0 twaugh twaugh_AT_redhat.com Tim Waugh user 0 veillard veillard_AT_redhat.com Daniel Veillard sponsor 7 walters walters_AT_redhat.com Colin Walters user 0 Tell me if there are any contributors in this list that should stay in cvsextras. tia! CU thl From twaugh at redhat.com Sat Sep 23 14:14:38 2006 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 23 Sep 2006 15:14:38 +0100 Subject: List of inactive members in cvsextras that will be removed soon In-Reply-To: <45153DEF.2050406@leemhuis.info> References: <45153DEF.2050406@leemhuis.info> Message-ID: <1159020878.7990.5.camel@cyberelk.elk> On Sat, 2006-09-23 at 16:00 +0200, Thorsten Leemhuis wrote: > twaugh twaugh_AT_redhat.com Tim Waugh user 0 I'm still here -- just have restricted time right at the moment, which is why I haven't shown up on your activity radar. :-) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sat Sep 23 15:01:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 23 Sep 2006 17:01:35 +0200 Subject: List of inactive members in cvsextras that will be removed soon In-Reply-To: <1159020878.7990.5.camel@cyberelk.elk> References: <45153DEF.2050406@leemhuis.info> <1159020878.7990.5.camel@cyberelk.elk> Message-ID: <45154C4F.5080409@leemhuis.info> Tim Waugh schrieb: > On Sat, 2006-09-23 at 16:00 +0200, Thorsten Leemhuis wrote: > >> twaugh twaugh_AT_redhat.com Tim Waugh user 0 > I'm still here -- just have restricted time right at the moment, which > is why I haven't shown up on your activity radar. :-) Well, I know that you and several other people from redhat are still around. But you and the others from by list seem to have no packages in Extras ATM so there is no need to be in cvsextras (or is there one for you?). So considers this please just as "cleanup" and "housekeeping", to make sure that the members of cvsextras are in fact extras contributors. You can of course re-apply at any point of time later easily. CU thl From jima at beer.tclug.org Sat Sep 23 16:36:04 2006 From: jima at beer.tclug.org (Jima) Date: Sat, 23 Sep 2006 11:36:04 -0500 (CDT) Subject: Please add autoconf and automake to the buildroot In-Reply-To: <4514966C.1030300@RedHat.com> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> <1158973374.2866.75.camel@localhost> <4514966C.1030300@RedHat.com> Message-ID: On Fri, 22 Sep 2006, Steve Dickson wrote: > Toshio Kuratomi wrote: >> You haven't addressed Paul's point that it's easier for us (we're >> supposed to be knowledgable packagers, right?) to detect these errors >> than for people downloading the SRPM and rebuilding in their local >> environment to do so. > In this particular case it wouldn't be ways for either them or us > because the errors are undetectable... but I truly doubt their > locally build rpm will end up on thousands of desktop via yum > marrying corrupting machines as they go. The point being we should put > in safeguards in that will stop us from sending out corrupted rpms > and by adding those packages we are doing just that... imho.. If the errors are undetectable, then I consider it all the more reason for you to add BRs for autoconf/automake. As stated previously, your case isn't really any different than any other missing BuildReqs that cause weird behavior in the resultant packages. >From an earlier email: > Jesse Keating wrote: > > I don't accept your claim that these are the most common used packages > > to build our rpms. > > These tools have been around since the early days of UNIX and have been > used every since... so whether you accept that or not is.... well... > indifferent... Unless you want to s/UNIX/Linux/, Toshio seemed to discount this claim. But, regardless of how old they are, age does not equal importance. I have a relatively meager package load (11), but only one of my packages uses autoconf. I asked Spot, as he has more packages (101); only three use autoconf or automake. A small sampling, for sure, but I can't help but wonder if it's at least vaguely representative. >> You also haven't addressed Jesse's points that >> this applies to many other packages besides autoconf and automake (what >> makes this case exceptional?) > They stop undetectable RPM corruption... That's generally the point of correctly defining your BuildReqs. >> or his point that part of being a packager >> is to look over the build logs to be sure your package not only built >> but built the way you expected it to. > And me tell why its not a broken build system when we have to scour over > successful build logs looking for data corrupters... Sounds more like broken packages, personally. >> If you think that autoconf and automake should require an extra level of >> error checking, you might also consider writing a test for rpmlint that >> checks patches for changes to Makefile.am, configure.ac, etc, and if it >> finds some, makes sure that the spec file calls autoconf, automake, or >> autoreconf. This can benefit people who are not using our particular >> buildsystem as well. > Or just add two very small, highly used packages to the buildroot. ;-) Would you mind ennumerating "highly used?" Jima From sgrubb at redhat.com Sat Sep 23 17:08:21 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 23 Sep 2006 13:08:21 -0400 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <4514966C.1030300@RedHat.com> References: <45142514.1000109@RedHat.com> <1158973374.2866.75.camel@localhost> <4514966C.1030300@RedHat.com> Message-ID: <200609231308.21724.sgrubb@redhat.com> On Friday 22 September 2006 22:05, Steve Dickson wrote: > In this particular case it wouldn't be ways for either them or us > because the errors are undetectable... The only thing that I can think of that is somewhat fishy is this in autoreconf: my $autoconf = $ENV{'AUTOCONF'} || '/usr/bin/autoconf'; my $autoheader = $ENV{'AUTOHEADER'} || '/usr/bin/autoheader'; my $automake = $ENV{'AUTOMAKE'} || 'automake'; my $aclocal = $ENV{'ACLOCAL'} || 'aclocal'; my $libtoolize = $ENV{'LIBTOOLIZE'} || 'libtoolize'; my $autopoint = $ENV{'AUTOPOINT'} || 'autopoint'; It uses a full path for autoconf, but local path for automake. Do you know if the package in question contains a copy of automake? -Steve From paul at city-fan.org Sun Sep 24 09:21:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 24 Sep 2006 10:21:39 +0100 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1158973374.2866.75.camel@localhost> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> <1158973374.2866.75.camel@localhost> Message-ID: <1159089699.23008.10.camel@metropolis.intra.city-fan.org> On Fri, 2006-09-22 at 18:02 -0700, Toshio Kuratomi wrote: > If you think that autoconf and automake should require an extra level of > error checking, you might also consider writing a test for rpmlint that > checks patches for changes to Makefile.am, configure.ac, etc, and if it > finds some, makes sure that the spec file calls autoconf, automake, or > autoreconf. This can benefit people who are not using our particular > buildsystem as well. I think this would lead to false positives. If I find I have to patch autotools input files, I also try to make the corresponding patch in the output files. Sometimes this is a trivial edit and other times it involves re-running the autotools and creating a patch from the original files to the newly-generated ones. Either way, there is no need to run the autotools when the package is built on the buildsystem. I believe this to be good practice and thus a naive rpmlint check for edits to autotools input files wouldn't be that good a test. Paul. From paul at city-fan.org Sun Sep 24 09:26:23 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 24 Sep 2006 10:26:23 +0100 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <45143B22.7070605@RedHat.com> References: <45142514.1000109@RedHat.com> <1158948837.23008.4.camel@metropolis.intra.city-fan.org> <45143B22.7070605@RedHat.com> Message-ID: <1159089983.23008.13.camel@metropolis.intra.city-fan.org> On Fri, 2006-09-22 at 15:36 -0400, Steve Dickson wrote: > > Paul Howarth wrote: > > > > On the other hand, by including autotools in the minimal buildroot, > > people get away with not adding them as buildreqs of packages that need > > them, which would then have the result that people trying to rebuild > > these packages for themselves on systems without autotools installed > > would come across these tricky problems, and probably be less able to > > figure out what the problem is. > point... and not having the correct buildreqs in the spec file > would be a bug in the spec file... and the person should report > it as such... but that is not a reason to leave a corruption hole > in our build process that can potentially destroy a system with > a corrupt rpm... imho... What are the chances of this bug being found by someone other than the packager? Very slim I'd have thought, particularly if the packager's build system hides the bug from him. > > So my vote would be keep the status quo; packagers patching autotools > > input files should either buildreq autotools, or, better still, also > > patch the autotools generated files so that the autotools aren't needed > > for the package build. > Patching the autotool generated files is not a good idea imho... > You basically saying don't use *any* of the autoconf tools and just > hack things to work... I've been down that path and I have found > those hack become very unmaintainable in a very short time... > It it much much easy to simple patch the autoconf files and > rerun the tools.. Indeed it is. So re-run the tools yourself and use the tools' output to make the patch. Paul. From a.badger at gmail.com Sun Sep 24 15:28:28 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 24 Sep 2006 08:28:28 -0700 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1159089699.23008.10.camel@metropolis.intra.city-fan.org> References: <45142514.1000109@RedHat.com> <200609221518.09832.jkeating@redhat.com> <45143F41.8050003@RedHat.com> <200609221632.07777.jkeating@redhat.com> <45147874.80704@RedHat.com> <1158973374.2866.75.camel@localhost> <1159089699.23008.10.camel@metropolis.intra.city-fan.org> Message-ID: <1159111708.2979.7.camel@localhost> On Sun, 2006-09-24 at 10:21 +0100, Paul Howarth wrote: > On Fri, 2006-09-22 at 18:02 -0700, Toshio Kuratomi wrote: > > If you think that autoconf and automake should require an extra level of > > error checking, you might also consider writing a test for rpmlint that > > checks patches for changes to Makefile.am, configure.ac, etc, and if it > > finds some, makes sure that the spec file calls autoconf, automake, or > > autoreconf. This can benefit people who are not using our particular > > buildsystem as well. > > I think this would lead to false positives. If I find I have to patch > autotools input files, I also try to make the corresponding patch in the > output files. Sometimes this is a trivial edit and other times it > involves re-running the autotools and creating a patch from the original > files to the newly-generated ones. Either way, there is no need to run > the autotools when the package is built on the buildsystem. I believe > this to be good practice and thus a naive rpmlint check for edits to > autotools input files wouldn't be that good a test. Yes. There would be false positives. But rpmlint generates other false positives as well.... It points out possible packaging errors rather than things that are 100% reliably wrong. It is up to the person looking at the output to understand what it is complaining about and figure out if there's a genuine error that needs to be addressed. OTOH, I don't have time to write this check so if SteveD doesn't do this, we'll all have to continue to remember to do this check manually :-) -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 dennis at ausil.us Sun Sep 24 16:48:32 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 24 Sep 2006 11:48:32 -0500 Subject: Please add autoconf and automake to the buildroot In-Reply-To: <1159089983.23008.13.camel@metropolis.intra.city-fan.org> References: <45142514.1000109@RedHat.com> <45143B22.7070605@RedHat.com> <1159089983.23008.13.camel@metropolis.intra.city-fan.org> Message-ID: <200609241148.33327.dennis@ausil.us> On Sunday 24 September 2006 4:26 am, Paul Howarth wrote: > On Fri, 2006-09-22 at 15:36 -0400, Steve Dickson wrote: > > Paul Howarth wrote: > > > On the other hand, by including autotools in the minimal buildroot, > > > people get away with not adding them as buildreqs of packages that need > > > them, which would then have the result that people trying to rebuild > > > these packages for themselves on systems without autotools installed > > > would come across these tricky problems, and probably be less able to > > > figure out what the problem is. > > > > point... and not having the correct buildreqs in the spec file > > would be a bug in the spec file... and the person should report > > it as such... but that is not a reason to leave a corruption hole > > in our build process that can potentially destroy a system with > > a corrupt rpm... imho... > > What are the chances of this bug being found by someone other than the > packager? Very slim I'd have thought, particularly if the packager's > build system hides the bug from him. The packager should manually call autoconf and automake if patching the any of the autotools files. they should not rely on them being called for them. and if the packager did the right thing. It should be picked up with their testing. packages should be building their package in mock locally before committing changes to cvs. -- Dennis Gilmore, RHCE Proud Australian From twaugh at redhat.com Sun Sep 24 22:30:20 2006 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 24 Sep 2006 23:30:20 +0100 Subject: List of inactive members in cvsextras that will be removed soon In-Reply-To: <45154C4F.5080409@leemhuis.info> References: <45153DEF.2050406@leemhuis.info> <1159020878.7990.5.camel@cyberelk.elk> <45154C4F.5080409@leemhuis.info> Message-ID: <1159137020.3813.48.camel@cyberelk.elk> On Sat, 2006-09-23 at 17:01 +0200, Thorsten Leemhuis wrote: > Well, I know that you and several other people from redhat are still > around. But you and the others from by list seem to have no packages in > Extras ATM so there is no need to be in cvsextras (or is there one for > you?). I have a package that's going through the process of getting into Extras (international-time). As soon as I get some time free for Extras I can advance it further through the process. Tim. */ -------------- 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 petersen at redhat.com Mon Sep 25 07:04:17 2006 From: petersen at redhat.com (Jens Petersen) Date: Mon, 25 Sep 2006 16:04:17 +0900 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <1158612775.2902.140.camel@viper.local> References: <1158612775.2902.140.camel@viper.local> Message-ID: <45177F71.5020203@redhat.com> So what are the precise steps for unorphaning packaging once they have been rebuilt? - remove needs.rebuild - remove from Extras/OrphanedPackages ? Jens From Christian.Iseli at licr.org Mon Sep 25 14:07:47 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 25 Sep 2006 16:07:47 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <45177F71.5020203@redhat.com> References: <1158612775.2902.140.camel@viper.local> <45177F71.5020203@redhat.com> Message-ID: <20060925160747.7897f8a9@ludwig-alpha> On Mon, 25 Sep 2006 16:04:17 +0900, Jens Petersen wrote: > - remove needs.rebuild > - remove from Extras/OrphanedPackages Yes, and also: - update owners.list file - assign all open bugs to self - possibly check and update comps.xml C From ville.skytta at iki.fi Mon Sep 25 21:22:55 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 26 Sep 2006 00:22:55 +0300 Subject: Extras for FC6 rebuild status Message-ID: <1159219375.2981.75.camel@viper.local> Extras for FC6 rebuild status: 67 packages remain removed from the package repository due to not being rebuilt/reclaimed: http://fedoraproject.org/wiki/Extras/FC6Status Things changed over the weekend, and there are currently no packages that depend on those pending for removal, good. (Except for curry, but I gather ghc will be taken care of soon.) However, there's still a few packages whose status is somewhat unclear in the devel repo - these need to be properly unorphaned in order for them to stay in FE6: - ddclient (Josh Boyer?) - libvisual-plugins (Thomas Vander Stichele?) - python-twisted (Thomas Vander Stichele?) Nothing appears to depend on ddclient or libvisual-plugins, but these have dependencies on python-twisted: buildbot, flumotion, pyicq-t, python-cvstoys. Nothing appears to require those. Overall, I think things are starting to look pretty good. The latest broken dependencies reports have also been remarkably shorter than they have used to be. Let's just iron out the last few bits and I think we'll be in pretty good shape for FC6. From jwboyer at jdub.homelinux.org Mon Sep 25 21:35:16 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 25 Sep 2006 16:35:16 -0500 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <1159220117.24836.4.camel@zod.rchland.ibm.com> On Tue, 2006-09-26 at 00:22 +0300, Ville Skytt? wrote: > Extras for FC6 rebuild status: > > 67 packages remain removed from the package repository due to not being > rebuilt/reclaimed: http://fedoraproject.org/wiki/Extras/FC6Status > > Things changed over the weekend, and there are currently no packages > that depend on those pending for removal, good. (Except for curry, but > I gather ghc will be taken care of soon.) > > However, there's still a few packages whose status is somewhat unclear > in the devel repo - these need to be properly unorphaned in order for > them to stay in FE6: > > - ddclient (Josh Boyer?) Yes, I'm taking ddclient. Just haven't gotten to it yet, sorry. I'll get it done tonight. josh From jamatos at fc.up.pt Mon Sep 25 21:56:20 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Mon, 25 Sep 2006 22:56:20 +0100 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <200609252256.21037.jamatos@fc.up.pt> On Monday 25 September 2006 22:22, Ville Skytt? wrote: > Extras for FC6 rebuild status: > > 67 packages remain removed from the package repository due to not being > rebuilt/reclaimed: http://fedoraproject.org/wiki/Extras/FC6Status > > Things changed over the weekend, and there are currently no packages > that depend on those pending for removal, good. (Except for curry, but > I gather ghc will be taken care of soon.) I will take care of ifplugd, I use it and it is unmaintained. I will do the changes required tomorrow. (wiki+cvs+owners+...) -- Jos? Ab?lio From dledford at redhat.com Tue Sep 26 03:35:07 2006 From: dledford at redhat.com (Doug Ledford) Date: Mon, 25 Sep 2006 23:35:07 -0400 Subject: List of inactive members in cvsextras that will be removed soon In-Reply-To: <45153DEF.2050406@leemhuis.info> References: <45153DEF.2050406@leemhuis.info> Message-ID: <1159241707.5074.2.camel@fc6.xsintricity.com> On Sat, 2006-09-23 at 16:00 +0200, Thorsten Leemhuis wrote: > dledford dledford_AT_redhat.com Doug Ledford user 0 Unless someone activated my account when I wasn't looking, I still don't have access to extras cvs, which would explain why I wasn't active, but not a reason to remove my account. It's reason to either A) activate my account or B) tell me it was activated so I know I can get something done in extras. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Sep 26 05:04:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Sep 2006 07:04:46 +0200 Subject: List of inactive members in cvsextras that will be removed soon In-Reply-To: <1159241707.5074.2.camel@fc6.xsintricity.com> References: <45153DEF.2050406@leemhuis.info> <1159241707.5074.2.camel@fc6.xsintricity.com> Message-ID: <4518B4EE.7010804@leemhuis.info> Doug Ledford schrieb: > On Sat, 2006-09-23 at 16:00 +0200, Thorsten Leemhuis wrote: >> dledford dledford_AT_redhat.com Doug Ledford user 0 > Unless someone activated my account when I wasn't looking, You normally get a mail when you get sponsored. And it seems you got sponsored, so you should have revieved that mail. > I still don't > have access to extras cvs, which would explain why I wasn't active, but > not a reason to remove my account. It's reason to either A) activate my > account or B) tell me it was activated so I know I can get something > done in extras. Well, what packages do you plan to maintain? Who is sponsering you? CU thl From pix at crazyfrogs.org Tue Sep 26 06:30:10 2006 From: pix at crazyfrogs.org (PIx) Date: Tue, 26 Sep 2006 08:30:10 +0200 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <1159252210.8427.12.camel@ruatha> What about amarok ? (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206214 ) Looks like it still needs Helix to appear in extras.. Le mardi 26 septembre 2006 ? 00:22 +0300, Ville Skytt? a ?crit : > Extras for FC6 rebuild status: > > 67 packages remain removed from the package repository due to not being > rebuilt/reclaimed: http://fedoraproject.org/wiki/Extras/FC6Status > > Things changed over the weekend, and there are currently no packages > that depend on those pending for removal, good. (Except for curry, but > I gather ghc will be taken care of soon.) > > However, there's still a few packages whose status is somewhat unclear > in the devel repo - these need to be properly unorphaned in order for > them to stay in FE6: > > - ddclient (Josh Boyer?) > - libvisual-plugins (Thomas Vander Stichele?) > - python-twisted (Thomas Vander Stichele?) > > Nothing appears to depend on ddclient or libvisual-plugins, but these > have dependencies on python-twisted: buildbot, flumotion, pyicq-t, > python-cvstoys. Nothing appears to require those. > > Overall, I think things are starting to look pretty good. The latest > broken dependencies reports have also been remarkably shorter than they > have used to be. Let's just iron out the last few bits and I think > we'll be in pretty good shape for FC6. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From rvokal at redhat.com Tue Sep 26 07:04:48 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Tue, 26 Sep 2006 09:04:48 +0200 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <1159254288.13890.3.camel@localhost.localdomain> On Tue, 2006-09-26 at 00:22 +0300, Ville Skytt? wrote: > Extras for FC6 rebuild status: > > 67 packages remain removed from the package repository due to not being > rebuilt/reclaimed: http://fedoraproject.org/wiki/Extras/FC6Status > > Things changed over the weekend, and there are currently no packages > that depend on those pending for removal, good. (Except for curry, but > I gather ghc will be taken care of soon.) > > However, there's still a few packages whose status is somewhat unclear > in the devel repo - these need to be properly unorphaned in order for > them to stay in FE6: > > - ddclient (Josh Boyer?) > - libvisual-plugins (Thomas Vander Stichele?) > - python-twisted (Thomas Vander Stichele?) > > Nothing appears to depend on ddclient or libvisual-plugins, but these > have dependencies on python-twisted: buildbot, flumotion, pyicq-t, > python-cvstoys. Nothing appears to require those. > > Overall, I think things are starting to look pretty good. The latest > broken dependencies reports have also been remarkably shorter than they > have used to be. Let's just iron out the last few bits and I think > we'll be in pretty good shape for FC6. > I take care of adns packages (adns, python-adns) Radek > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Radek Vok?l Base OS Engineering Office: +420 543 422 235 Red Hat Inc. http://www.redhat.com From paul at city-fan.org Tue Sep 26 07:32:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 26 Sep 2006 08:32:47 +0100 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <1159255967.9858.6.camel@metropolis.intra.city-fan.org> On Tue, 2006-09-26 at 00:22 +0300, Ville Skytt? wrote: > Extras for FC6 rebuild status: > > ... > > However, there's still a few packages whose status is somewhat unclear > in the devel repo - these need to be properly unorphaned in order for > them to stay in FE6: > > - ddclient (Josh Boyer?) > - libvisual-plugins (Thomas Vander Stichele?) > - python-twisted (Thomas Vander Stichele?) > > Nothing appears to depend on ddclient or libvisual-plugins, but these > have dependencies on python-twisted: buildbot, flumotion, pyicq-t, > python-cvstoys. Nothing appears to require those. The version of Twisted in Extras cvs is rather ancient; Thomas has put together a set of packages to update it to the current release though (see #171543). It's a set of packages because upstream has split the project up. These packages will all need to be reviewed, but so far Thomas appears to have been too busy to submit them for review. The current upstream release of bittorrent (4.9.x) requires the new version of Twisted. I would have liked to have had this in FC6 but it looks like it's going to be too late now. Paul. From thomas at apestaart.org Tue Sep 26 14:51:51 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 26 Sep 2006 16:51:51 +0200 Subject: Extras for FC6 rebuild status In-Reply-To: <1159219375.2981.75.camel@viper.local> References: <1159219375.2981.75.camel@viper.local> Message-ID: <1159282311.31039.52.camel@otto.amantes> Hi, > - libvisual-plugins (Thomas Vander Stichele?) I do not intend to maintain it, I just gave it a kick to jump from 0.2.0 to 0.4.0. This package had broken yum upgrade for people for over 40 days, which one could take as a failure of the system in some way. (But I'm sure people know my opinion about the fact that yum upgrade gives up as soon as the smallest dependency problem is found) There are two open bugs open about that, but for some reason I could not actually comment on them. Its maintainer recently mailed the various lists that he was going to stop maintaining his packages, so it's now effectively orphaned. > - python-twisted (Thomas Vander Stichele?) This one is a lot more tricky. With the 2.0 release of twisted, Twisted was split up in over 10 separate tarballs. While I'm happy with the modularity, it does mean that it is unclear how to upgrade it in Extras. I had submitted an initial packaging to Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171543 but haven't managed to convince enough people to look at it yet, and I'm still not sure if there is a way for me to push this as an upgrade of the existing python-twisted package (note that the collection of these packages, together with the python-twisted rpm - whic his now an umbrella package), it should be a complete drop-in replacement, and it works with flumotion and buildbot) The current plan for this is as follows: - each of these packages is going to be submitted as a new package for devel Extras - they can hit the repository step by step since python-twisted is currently not in devel - when the whole stack is in place, we could consider doing a push to FC5 as well (which I would really like to see happen) Does that sound sane ? Thomas From rdieter at math.unl.edu Tue Sep 26 15:15:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 10:15:19 -0500 Subject: Extras for FC6 rebuild status In-Reply-To: <1159252210.8427.12.camel@ruatha> References: <1159219375.2981.75.camel@viper.local> <1159252210.8427.12.camel@ruatha> Message-ID: <45194407.3050706@math.unl.edu> PIx wrote: > What about amarok ? (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206214 ) > Looks like it still needs Helix to appear in extras.. Or xine-lib... (: http://bugzilla.redhat.com/205798 -- Rex From rdieter at math.unl.edu Tue Sep 26 18:26:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 13:26:49 -0500 Subject: libtunepimp-0.5.1 coming (soon) to Extras In-Reply-To: <45102EC5.9040702@math.unl.edu> References: <45102EC5.9040702@math.unl.edu> Message-ID: <451970E9.9040403@math.unl.edu> Rex Dieter wrote on 09/19: > Just a heads up that I plan on upgrading to libtunepimp-0.5.1 (in > Extras) sson (probably within a couple of days). It is > API/ABI-incompatible with previous releases. AFAICT, the only affected > Extras packages are: > amarok (1) > kdemultimedia-extras (mine) (2) > kid3 (2) OK, development is now at libtunepimp-0.5.1. Depending on how well this goes, I'm leaning toward a similar upgrade for the FC-5 branch as well. -- Rex > (1) confirmed to work with libtunepimp-0.5 > (2) doesn't (yet) support libtunepimp-0.5 (but still buildable). If > there's enough interest, I can make a parallel-installable > compat-libtunepimp-0.4 (or something like that). Frankly, > libtunepimp-0.4 is/was buggy enough that it probably isn't worth the > effort. From ikent at redhat.com Wed Sep 27 04:35:13 2006 From: ikent at redhat.com (Ian Kent) Date: Wed, 27 Sep 2006 12:35:13 +0800 Subject: FC6 Test3 is now frozen In-Reply-To: <200609060811.27862.jkeating@redhat.com> References: <200609051205.21931.jkeating@redhat.com> <1157543138.3162.0.camel@majain.pnq.redhat.com> <200609060811.27862.jkeating@redhat.com> Message-ID: <1159331713.2897.48.camel@raven.themaw.net> On Wed, 2006-09-06 at 08:11 -0400, Jesse Keating wrote: Hi Jesse, Sorry to bug you with silly questions but ... I'm not clear on the current state of the of FC6 except that the build target seems to be still locked. I've discovered quite a serious bug in autofs and think it needs to be fixed as soon as possible in FC6. Basically, a case that can easily lead to a SEGV. I believe I will need to create a BZ to describe the problem (which I've done, bz 208219) and build into dist-FC6-HEAD (which I've also done) and then send a mail to (?) asking for review. Is that the right thing to do? Is there a problem in that I have included a few other simple bug fix patches in the package following the freeze that will also be present in the requested package? > We are in a continual freeze. Builds are currently going to dist-fc6-HEAD. > There is some criteria to get it moved out of -HEAD and into dist-fc6 for > either Test3 or for the final. > > For Test3 they need to be serious blocker type bugfixes, such as every user > will crash this app, or this will prevent installations. > > Once Test3 goes out the door there is a bit more flexibility in getting things > moved in, and it would be low risk bugfixes (preferrably on either FC6Target > or FC6Blockers) or the above criteria. Once we've deep frozen for FC6 we'd > be back to 'prevents installation' or 'eats users data upon execution' > criteria to get it pulled out of -HEAD and into dist-fc6 for the release. > After that, the contents of dist-fc6-HEAD would be moved to > dist-fc6-updates-candidate to be processed as possible updates. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From petersen at redhat.com Wed Sep 27 07:12:31 2006 From: petersen at redhat.com (Jens Petersen) Date: Wed, 27 Sep 2006 16:12:31 +0900 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060925160747.7897f8a9@ludwig-alpha> References: <1158612775.2902.140.camel@viper.local> <45177F71.5020203@redhat.com> <20060925160747.7897f8a9@ludwig-alpha> Message-ID: <451A245F.3080802@redhat.com> Christian Iseli wrote: > On Mon, 25 Sep 2006 16:04:17 +0900, Jens Petersen wrote: >> - remove needs.rebuild >> - remove from Extras/OrphanedPackages > > Yes, and also: > - update owners.list file Sure. > - assign all open bugs to self > - possibly check and update comps.xml Ok (sigh), thanks. And who is responsible for updating Extras/FC6Status? Jens PS For the record I'm not very happy that the warning mails I received didn't seem to mention that my packages were about to be removed from Extras. I hope this process will be done better in the future: I'm already overloaded enough as it is with FC6 work without having to unorphan deleted packages just because they didn't get rebuilt in time. From Christian.Iseli at licr.org Wed Sep 27 07:30:32 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 27 Sep 2006 09:30:32 +0200 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <451A245F.3080802@redhat.com> References: <1158612775.2902.140.camel@viper.local> <45177F71.5020203@redhat.com> <20060925160747.7897f8a9@ludwig-alpha> <451A245F.3080802@redhat.com> Message-ID: <20060927093032.34d23142@ludwig-alpha> On Wed, 27 Sep 2006 16:12:31 +0900, Jens Petersen wrote: > And who is responsible for updating Extras/FC6Status? Ville put the orphaned packages in there, but you can remove the ones you un-orphan yourself AFAIK. C From jkeating at redhat.com Wed Sep 27 14:35:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Sep 2006 10:35:47 -0400 Subject: FC6 Test3 is now frozen In-Reply-To: <1159331713.2897.48.camel@raven.themaw.net> References: <200609051205.21931.jkeating@redhat.com> <200609060811.27862.jkeating@redhat.com> <1159331713.2897.48.camel@raven.themaw.net> Message-ID: <200609271035.47727.jkeating@redhat.com> On Wednesday 27 September 2006 00:35, Ian Kent wrote: > Sorry to bug you with silly questions but ... > > I'm not clear on the current state of the of FC6 except that the build > target seems to be still locked. We're in continual freeze only taking in bugfixes that are hopefully for FC6Blocker or FC6Target bugs. -- 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 ville.skytta at iki.fi Wed Sep 27 18:27:29 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 27 Sep 2006 21:27:29 +0300 Subject: Extras packages queued for removal after (non-)rebuild In-Reply-To: <20060927093032.34d23142@ludwig-alpha> References: <1158612775.2902.140.camel@viper.local> <45177F71.5020203@redhat.com> <20060925160747.7897f8a9@ludwig-alpha> <451A245F.3080802@redhat.com> <20060927093032.34d23142@ludwig-alpha> Message-ID: <1159381649.2981.213.camel@viper.local> On Wed, 2006-09-27 at 09:30 +0200, Christian Iseli wrote: > On Wed, 27 Sep 2006 16:12:31 +0900, Jens Petersen wrote: > > And who is responsible for updating Extras/FC6Status? > > Ville put the orphaned packages in there, but you can remove > the ones you un-orphan yourself AFAIK. Sure, but please keep it in sync with the actual public repository, not CVS/needsign. And leave packages which have been rebuilt but not unorphaned listed there noting the status, there are currently some examples in it.