From kaboom at oobleck.net Mon Apr 3 15:07:27 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 3 Apr 2006 11:07:27 -0400 (EDT) Subject: Fedora Extras CVS problems Message-ID: Looks like some garbage in several of the releases If I try to check out each release, I get: [kaboom at urd fedora-extras-cvs]$ cvs co FC-3 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs [checkout aborted]: there is no repository /cvs/extras/rpms/gdesklets/FC-3 [kaboom at urd fedora-extras-cvs]$ cvs co FC-4 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs [checkout aborted]: there is no repository /cvs/extras/rpms/fftw3/FC-4 [kaboom at urd fedora-extras-cvs]$ cvs co FC-5 For more information on using the Fedora source code repositories, please visit http://fedoraproject.org/wiki/UsingCvs cvs [checkout aborted]: there is no repository /cvs/extras/rpms/fftw3/FC-5 [kaboom at urd fedora-extras-cvs]$ devel's working, but gdesklets is killing FC-3 and fftw3 is killing FC-4 and FC-5 later, chris From notting at redhat.com Tue Apr 4 16:56:10 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Apr 2006 12:56:10 -0400 Subject: gtk+ stuff moving out of Core Message-ID: <20060404165610.GA32313@devserv.devel.redhat.com> We're intending to remove the GNOME1/GTK1 stack from Core soon. Initially, the following will go away: GConf Guppi ORBit gal gnome-libs gnome-print gtkhtml libgal23 libglade libgnomeprint15 oaf Later, these will follow: glib gtk+ gdk-pixbuf imlib Looking at Extras, the following things require glib/gtk+: Gtk-Perl qiv compat-wxGTK dillo gfontview amarok-visualisation (hah!) easytag gkrellmms xvattr freedroidrpg *xmms* diradmin amaya (wow) alsa-tools soundtracker gtkalog edb-gtk gsview gentoo gcombust bubblemon R-gnomeGUI bmp-xosd nomadsync If you own one of these, glib and gtk+ will need a maintainer.... Bill From fedora at camperquake.de Tue Apr 4 18:31:46 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Apr 2006 20:31:46 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060404165610.GA32313@devserv.devel.redhat.com> References: <20060404165610.GA32313@devserv.devel.redhat.com> Message-ID: <20060404203146.4491da03@nausicaa.camperquake.de> Hi. Bill Nottingham wrote: > If you own one of these, glib and gtk+ will need a maintainer.... Can we find a way to seamlessly move all those packages into Extras so that the combined FC/FE tree stays consistent during this change? We can then still orphan the packages from FE, if nothing needs them. -- To remove dust from the eye, pull the eye down over the nose. From jkeating at redhat.com Tue Apr 4 18:48:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 04 Apr 2006 14:48:56 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060404203146.4491da03@nausicaa.camperquake.de> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> Message-ID: <1144176537.18098.39.camel@ender> On Tue, 2006-04-04 at 20:31 +0200, Ralf Ertzinger wrote: > > Can we find a way to seamlessly move all those packages into > Extras so that the combined FC/FE tree stays consistent during > this change? We can then still orphan the packages from FE, if > nothing needs them. Sure, we find somebody to take these packages, they prepare CVS and get packages ready to go. At some point between rawhide pushes, we drop it from core and release it in Extras in very short time. Coordinated. This would be pretty seemless, right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Tue Apr 4 19:09:47 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 04 Apr 2006 21:09:47 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144176537.18098.39.camel@ender> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> Message-ID: <4432C47B.9000703@hhs.nl> Jesse Keating wrote: > On Tue, 2006-04-04 at 20:31 +0200, Ralf Ertzinger wrote: >> Can we find a way to seamlessly move all those packages into >> Extras so that the combined FC/FE tree stays consistent during >> this change? We can then still orphan the packages from FE, if >> nothing needs them. > > Sure, we find somebody to take these packages, they prepare CVS and get > packages ready to go. At some point between rawhide pushes, we drop it > from core and release it in Extras in very short time. Coordinated. > This would be pretty seemless, right? > I may be missing something, but why (after finding a new maintainer and let him/her import gtk+ + glib into CVS) don't we just release gtk+ and glib in FE with a newer release and then the next day or even after a few days drop it from core then we would avoid a "rac window" and I see no harm in this. Regards, Hans From jkeating at redhat.com Tue Apr 4 19:18:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 04 Apr 2006 15:18:27 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <4432C47B.9000703@hhs.nl> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> Message-ID: <1144178307.18098.45.camel@ender> On Tue, 2006-04-04 at 21:09 +0200, Hans de Goede wrote: > I may be missing something, but why (after finding a new maintainer and > let him/her import gtk+ + glib into CVS) don't we just release gtk+ and > glib in FE with a newer release and then the next day or even after a > few days drop it from core then we would avoid a "rac window" and I see > no harm in this. Sure, we could do this. Having it out of the internal Fedora build system would be nice, to prevent any more packages from linking against it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Tue Apr 4 21:17:41 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 04 Apr 2006 17:17:41 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144178307.18098.45.camel@ender> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> Message-ID: <1144185462.2096.0.camel@localhost.localdomain> On Tue, 2006-04-04 at 15:18 -0400, Jesse Keating wrote: > On Tue, 2006-04-04 at 21:09 +0200, Hans de Goede wrote: > > I may be missing something, but why (after finding a new maintainer and > > let him/her import gtk+ + glib into CVS) don't we just release gtk+ and > > glib in FE with a newer release and then the next day or even after a > > few days drop it from core then we would avoid a "rac window" and I see > > no harm in this. > > Sure, we could do this. Having it out of the internal Fedora build > system would be nice, to prevent any more packages from linking against > it. I think Hans' approach here is the safest... Dan From dwmw2 at infradead.org Wed Apr 5 13:11:51 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 14:11:51 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144178307.18098.45.camel@ender> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> Message-ID: <1144242711.6227.48.camel@pmac.infradead.org> On Tue, 2006-04-04 at 15:18 -0400, Jesse Keating wrote: > Sure, we could do this. Having it out of the internal Fedora build > system would be nice, to prevent any more packages from linking > against it. Move binary packages from Core to Extras repository, copy CVS files manually from Core to Extras CVS repository... surely it should be that simple? -- dwmw2 From rdieter at math.unl.edu Wed Apr 5 13:30:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 08:30:24 -0500 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144242711.6227.48.camel@pmac.infradead.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> Message-ID: <4433C670.4080305@math.unl.edu> David Woodhouse wrote: > On Tue, 2006-04-04 at 15:18 -0400, Jesse Keating wrote: > >>Sure, we could do this. Having it out of the internal Fedora build >>system would be nice, to prevent any more packages from linking >>against it. > > > Move binary packages from Core to Extras repository, copy CVS files > manually from Core to Extras CVS repository... surely it should be that > simple? Don't forget that Extras policy still requires a formal review, even for Core->Extras transitioned packages. -- Rex From fedora at leemhuis.info Wed Apr 5 13:51:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Apr 2006 15:51:09 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: <4433C670.4080305@math.unl.edu> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> Message-ID: <1144245070.2331.7.camel@localhost.localdomain> Am Mittwoch, den 05.04.2006, 08:30 -0500 schrieb Rex Dieter: > David Woodhouse wrote: > > On Tue, 2006-04-04 at 15:18 -0400, Jesse Keating wrote: > > > >>Sure, we could do this. Having it out of the internal Fedora build > >>system would be nice, to prevent any more packages from linking > >>against it. > > > > > > Move binary packages from Core to Extras repository, That would be very useful for other situations. E.g. it would make it possible to move some devel packages or openoffice language files from Core to Extras to reduce the size of Core. > > copy CVS files > > manually from Core to Extras CVS repository... surely it should be that > > simple? > > Don't forget that Extras policy still requires a formal review, even for > Core->Extras transitioned packages. And a new maintainer -- it helps nobody if we have a lot of orphaned packages in Extras (even if they come from Core). CU thl -- Thorsten Leemhuis From dwmw2 at infradead.org Wed Apr 5 14:07:28 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 15:07:28 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144245070.2331.7.camel@localhost.localdomain> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> Message-ID: <1144246048.6227.59.camel@pmac.infradead.org> On Wed, 2006-04-05 at 15:51 +0200, Thorsten Leemhuis wrote: > > Don't forget that Extras policy still requires a formal review, even for > > Core->Extras transitioned packages. > > And a new maintainer -- it helps nobody if we have a lot of orphaned > packages in Extras (even if they come from Core). It doesn't _require_ a new maintainer -- the person who owned in Core could quite happily continue to maintain it at least during the transition. A change of maintainer is something we can handle anyway, if they don't want to continue. And we could bypass the formal review for the initial binary package too -- just make sure it passes review before the first _update_ is actually put through the Extras build system. We need to make it easier for things to pass between Core and Extras, in either direction. -- dwmw2 From Christian.Iseli at licr.org Wed Apr 5 14:23:16 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Apr 2006 16:23:16 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: Your message of "Wed, 05 Apr 2006 15:07:28 BST." <1144246048.6227.59.camel@pmac.infradead.org> Message-ID: <200604051423.k35ENG88021373@ludwig-alpha.unil.ch> dwmw2 at infradead.org said: > And we could bypass the formal review for the initial binary package too I'm not sure I like this idea. What would be the point ? What worries me a bit is that once a binary package is in FE, there will be little incentive to review and push the update. Christian From fedora at leemhuis.info Wed Apr 5 14:27:13 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Apr 2006 16:27:13 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144246048.6227.59.camel@pmac.infradead.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> <1144246048.6227.59.camel@pmac.infradead.org> Message-ID: <1144247233.2331.25.camel@localhost.localdomain> Am Mittwoch, den 05.04.2006, 15:07 +0100 schrieb David Woodhouse: > On Wed, 2006-04-05 at 15:51 +0200, Thorsten Leemhuis wrote: > > > Don't forget that Extras policy still requires a formal review, even for > > > Core->Extras transitioned packages. > > > > And a new maintainer -- it helps nobody if we have a lot of orphaned > > packages in Extras (even if they come from Core). > > It doesn't _require_ a new maintainer -- the person who owned in Core > could quite happily continue to maintain it at least during the > transition. That was often not the case in the past iirc. > A change of maintainer is something we can handle anyway, if > they don't want to continue. > And we could bypass the formal review for the initial binary package too > -- just make sure it passes review before the first _update_ is actually > put through the Extras build system. And if there no one steps up to maintain it in extras? If it fails review? Will it be deleted? Who will do that? When? Chances are high that some packages will just linger around there until FC6 test3. Then someone will notice "He, no one maintains gtk+ or foo in Extras -- let's remove it. Ohh, we can't remove it -- a lot of packages depend on it". I'd like to avoid that. But okay, if others agree, let's do something like this: Copy over the binary packages from rawhide to extras devel. Let them linger around there for a month or a bit more (let's say "end of May" in this case) -- then they will get deleted. Even if that breaks deps for other packages in Extras. That okay for everybody? > We need to make it easier for things to pass between Core and Extras, in > either direction. Agreed. -- Thorsten Leemhuis From rdieter at math.unl.edu Wed Apr 5 14:38:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 09:38:34 -0500 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144245070.2331.7.camel@localhost.localdomain> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> Message-ID: <4433D66A.5030108@math.unl.edu> Thorsten Leemhuis wrote: > And a new maintainer -- it helps nobody if we have a lot of orphaned > packages in Extras (even if they come from Core). Heck, if no-one else offers, I'd be willing to maintain glib/gtk+ (those look easy enough). my incentive: I maintain the dependant gsview in Extras. -- Rex From dwmw2 at infradead.org Wed Apr 5 14:42:50 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 15:42:50 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144247233.2331.25.camel@localhost.localdomain> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> <1144246048.6227.59.camel@pmac.infradead.org> <1144247233.2331.25.camel@localhost.localdomain> Message-ID: <1144248170.6227.72.camel@pmac.infradead.org> On Wed, 2006-04-05 at 16:27 +0200, Thorsten Leemhuis wrote: > > > It doesn't _require_ a new maintainer -- the person who owned in Core > > could quite happily continue to maintain it at least during the > > transition. > > That was often not the case in the past iirc. Then let's just drop the word 'happily' and make it a declaration: When packages are moved from Core to Extras, the existing Core maintainer shall continue to own the package. They can attempt to find a new victim^Wvolunteer to maintain the package later if they so desire. > > A change of maintainer is something we can handle anyway, if > > they don't want to continue. > > > And we could bypass the formal review for the initial binary package too > > -- just make sure it passes review before the first _update_ is actually > > put through the Extras build system. > > And if there no one steps up to maintain it in extras? If it fails > review? Will it be deleted? Who will do that? When? Chances are high > that some packages will just linger around there until FC6 test3. Handle it precisely the same as any other abdication. If the Extras maintainer of gtk+ suddenly declares that they have no more time for the task, we have exactly the same questions, right? -- dwmw2 From veillard at redhat.com Wed Apr 5 14:45:19 2006 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 5 Apr 2006 10:45:19 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060404165610.GA32313@devserv.devel.redhat.com> References: <20060404165610.GA32313@devserv.devel.redhat.com> Message-ID: <20060405144519.GB22325@redhat.com> On Tue, Apr 04, 2006 at 12:56:10PM -0400, Bill Nottingham wrote: > We're intending to remove the GNOME1/GTK1 stack from Core soon. > Initially, the following will go away: > > GConf > Guppi > ORBit > gal > gnome-libs > gnome-print > gtkhtml > libgal23 > libglade > libgnomeprint15 > oaf > > Later, these will follow: > > glib > gtk+ > gdk-pixbuf > imlib I don't want to look painful, but can't we get rid of libxml1 too ? And any depending app should really go to Extras IMHO... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ 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 Wed Apr 5 14:46:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Apr 2006 15:46:52 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144246048.6227.59.camel@pmac.infradead.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> <1144246048.6227.59.camel@pmac.infradead.org> Message-ID: <4433D85C.8060104@city-fan.org> David Woodhouse wrote: > On Wed, 2006-04-05 at 15:51 +0200, Thorsten Leemhuis wrote: >>> Don't forget that Extras policy still requires a formal review, even for >>> Core->Extras transitioned packages. >> And a new maintainer -- it helps nobody if we have a lot of orphaned >> packages in Extras (even if they come from Core). > > It doesn't _require_ a new maintainer -- the person who owned in Core > could quite happily continue to maintain it at least during the > transition. A change of maintainer is something we can handle anyway, if > they don't want to continue. > > And we could bypass the formal review for the initial binary package too > -- just make sure it passes review before the first _update_ is actually > put through the Extras build system. Some Core packages would not even get through the Extras build system due to missing buildreqs. There should always be a review of anything going into Extras. > We need to make it easier for things to pass between Core and Extras, in > either direction. Yes, and there needs to be an established procedure for this. Packages have been imported into Core without the Extras maintainer even being contacted in the no too distant past. Paul. From jamatos at fc.up.pt Wed Apr 5 14:50:12 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 5 Apr 2006 15:50:12 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144248170.6227.72.camel@pmac.infradead.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <1144247233.2331.25.camel@localhost.localdomain> <1144248170.6227.72.camel@pmac.infradead.org> Message-ID: <200604051550.12858.jamatos@fc.up.pt> On Wednesday 05 April 2006 15:42, David Woodhouse wrote: > Then let's just drop the word 'happily' and make it a declaration: > > When packages are moved from Core to Extras, the existing Core > maintainer shall continue to own the package. They can attempt to find a > new victim^Wvolunteer to maintain the package later if they so desire. The point here is different from last time. The problem that we had last time was that lots of packages in Core are not up to Extras standards. That was the reason to stop the direct injection of packages dropped from Core. But as I said before those packages did not had a maintainer. I am not against a change, but there (valid) reasons before to have such a policy. Just my 0.02 ?. -- Jos? Ab?lio From pmatilai at laiskiainen.org Wed Apr 5 15:43:03 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 05 Apr 2006 18:43:03 +0300 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144242711.6227.48.camel@pmac.infradead.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> Message-ID: <4433E587.9060804@laiskiainen.org> > On Tue, 2006-04-04 at 15:18 -0400, Jesse Keating wrote: >> Sure, we could do this. Having it out of the internal Fedora build >> system would be nice, to prevent any more packages from linking >> against it. All this talk about how to make the transition smooth and yet in todays rawhide report: Removed package Guppi Removed package oaf Removed package gal Removed package gnome-print Removed package gnome-libs I don't see them imported into Extras, not to mention going through review and actually built. Sure, it's rawhide and I couldn't personally care less which way it breaks but... - Panu - From ville.skytta at iki.fi Wed Apr 5 16:15:13 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Apr 2006 19:15:13 +0300 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144247233.2331.25.camel@localhost.localdomain> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> <1144246048.6227.59.camel@pmac.infradead.org> <1144247233.2331.25.camel@localhost.localdomain> Message-ID: <1144253713.2712.11.camel@localhost.localdomain> On Wed, 2006-04-05 at 16:27 +0200, Thorsten Leemhuis wrote: > But okay, if others agree, let's do something like this: Copy over the > binary packages from rawhide to extras devel. Let them linger around > there for a month or a bit more (let's say "end of May" in this case) -- > then they will get deleted. Even if that breaks deps for other packages > in Extras. I'm missing the point of that. But given that Rex volunteered to maintain glib/gtk+, it's possibly moot anyway. From rdieter at math.unl.edu Wed Apr 5 16:31:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 11:31:11 -0500 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144253713.2712.11.camel@localhost.localdomain> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060404203146.4491da03@nausicaa.camperquake.de> <1144176537.18098.39.camel@ender> <4432C47B.9000703@hhs.nl> <1144178307.18098.45.camel@ender> <1144242711.6227.48.camel@pmac.infradead.org> <4433C670.4080305@math.unl.edu> <1144245070.2331.7.camel@localhost.localdomain> <1144246048.6227.59.camel@pmac.infradead.org> <1144247233.2331.25.camel@localhost.localdomain> <1144253713.2712.11.camel@localhost.localdomain> Message-ID: <4433F0CF.7050902@math.unl.edu> Ville Skytt? wrote: > But given that Rex volunteered to maintain glib/gtk+, it's possibly moot anyway. Clarification: I said I'd do glib/gtk+ if no-one else would. The result will probably be the same. (-: -- Rex From jspaleta at gmail.com Wed Apr 5 17:46:40 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 13:46:40 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <200604051423.k35ENG88021373@ludwig-alpha.unil.ch> References: <1144246048.6227.59.camel@pmac.infradead.org> <200604051423.k35ENG88021373@ludwig-alpha.unil.ch> Message-ID: <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> On 4/5/06, Christian.Iseli at licr.org wrote: > I'm not sure I like this idea. What would be the point ? > What worries me a bit is that once a binary package is in FE, there will be > little incentive to review and push the update. I have a suggested fix for that. Have people raise their hand now and commit to doing the review by a certain point in time. Start the clock and if the review isn't completed within the time frame of that clock and new binaries pushed... the existing binaries that were imported from Core are removed breaking the dep chains. We can do this sort of thing now before the next testing cycle even begins and allow for as smooth a transition as possible. Things are much more difficult to deal with smoothly if things are dropped from Core late in the testing phase.. cough gstreamer08 cough. The idea here is to allow a "good faith" effort for someone to take "proactive" responsibility to clean this package up which minimizes the impact on the package repository. Good faith meaning that a package maintainer and a reviewer(most likely someone who needs this package as a dep) raise their hands now and say "yes we will work on getting this compliant in X number of days". If people don't raise their hand to take the responsbility then no.. its not appropriate to bend the rules and let the binaries in from Core. If people sign up now and say they are going to be responsible for pushing this through review within the stated timeframe then we can publicly shame them when they fail. I think its an appropriate tradeoff to let the binaries in now if people take responsibility upfront to work on the review... because I like giving people enough rope to hang themselves for public amusement. -jef From Christian.Iseli at licr.org Wed Apr 5 18:19:57 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Apr 2006 20:19:57 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: Your message of "Wed, 05 Apr 2006 13:46:40 EDT." <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> Message-ID: <200604051820.k35IKLAs002612@mx3.redhat.com> jspaleta at gmail.com said: > The idea here is to allow a "good faith" effort for someone to take > "proactive" responsibility to clean this package up which minimizes the > impact on the package repository. Good faith meaning that a package > maintainer and a reviewer(most likely someone who needs this package as a > dep) raise their hands now and say "yes we will work on getting this > compliant in X number of days". If people don't raise their hand to take the > responsbility then no.. its not appropriate to bend the rules and let the > binaries in from Core. If people sign up now and say they are going to be > responsible for pushing this through review within the stated timeframe then > we can publicly shame them when they fail. I think its an appropriate > tradeoff to let the binaries in now if people take responsibility upfront to > work on the review... because I like giving people enough rope to hang > themselves for public amusement. Ok, works for me :-) Christian From dwmw2 at infradead.org Wed Apr 5 19:56:35 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 20:56:35 +0100 Subject: gtk+ stuff moving out of Core In-Reply-To: <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> References: <1144246048.6227.59.camel@pmac.infradead.org> <200604051423.k35ENG88021373@ludwig-alpha.unil.ch> <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> Message-ID: <1144266995.6227.105.camel@pmac.infradead.org> On Wed, 2006-04-05 at 13:46 -0400, Jeff Spaleta wrote: > On 4/5/06, Christian.Iseli at licr.org wrote: > > I'm not sure I like this idea. What would be the point ? > > What worries me a bit is that once a binary package is in FE, there will be > > little incentive to review and push the update. > > I have a suggested fix for that. I have a better fix for that, although perhaps less practical in the very short term: Stop having different quality standards for Core and for Extras. Go file bugs (and submit patches) against any Core package which doesn't meet the existing guidelines and would need to be modified if it were ever hypothetically to be moved into Extras. -- dwmw2 From bdpepple at ameritech.net Wed Apr 5 20:43:35 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 05 Apr 2006 16:43:35 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144266995.6227.105.camel@pmac.infradead.org> References: <1144246048.6227.59.camel@pmac.infradead.org> <200604051423.k35ENG88021373@ludwig-alpha.unil.ch> <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> <1144266995.6227.105.camel@pmac.infradead.org> Message-ID: <1144269815.24179.3.camel@shuttle.piedmont.com> On Wed, 2006-04-05 at 20:56 +0100, David Woodhouse wrote: > I have a better fix for that, although perhaps less practical in the > very short term: Stop having different quality standards for Core and > for Extras. > > Go file bugs (and submit patches) against any Core package which doesn't > meet the existing guidelines and would need to be modified if it were > ever hypothetically to be moved into Extras. I've done that in the past, but in general they just tend to sit in Bugzilla forever. For example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182174 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Wed Apr 5 22:37:02 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 Apr 2006 18:37:02 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <1144266995.6227.105.camel@pmac.infradead.org> References: <1144246048.6227.59.camel@pmac.infradead.org> <604aa7910604051046x21dfdd1ke634427d7fd0c134@mail.gmail.com> <1144266995.6227.105.camel@pmac.infradead.org> Message-ID: <200604051837.02869.jkeating@j2solutions.net> On Wednesday 05 April 2006 15:56, David Woodhouse wrote: > I have a better fix for that, although perhaps less practical in the > very short term: Stop having different quality standards for Core and > for Extras. > > Go file bugs (and submit patches) against any Core package which doesn't > meet the existing guidelines and would need to be modified if it were > ever hypothetically to be moved into Extras. All new core packages must adhere to the Extras package quality standards. We're still working out the details to accomplish the review. I also agree that the package from Core to Extras does not get a free ride, it still needs to be review. -- 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: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jkeating at j2solutions.net Wed Apr 5 22:39:02 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 Apr 2006 18:39:02 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <4433E587.9060804@laiskiainen.org> References: <20060404165610.GA32313@devserv.devel.redhat.com> <1144242711.6227.48.camel@pmac.infradead.org> <4433E587.9060804@laiskiainen.org> Message-ID: <200604051839.02370.jkeating@j2solutions.net> On Wednesday 05 April 2006 11:43, Panu Matilainen wrote: > I don't see them imported into Extras, not to mention going through > review and actually built. Sure, it's rawhide and I couldn't personally > care less which way it breaks but... These were checked for deps (or so I was told) and where safe to remove. Those things that still had deps were not removed, like gtk/glib. -- 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: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From notting at redhat.com Thu Apr 6 02:37:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Apr 2006 22:37:15 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <200604051839.02370.jkeating@j2solutions.net> References: <20060404165610.GA32313@devserv.devel.redhat.com> <1144242711.6227.48.camel@pmac.infradead.org> <4433E587.9060804@laiskiainen.org> <200604051839.02370.jkeating@j2solutions.net> Message-ID: <20060406023714.GA10416@devserv.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: > On Wednesday 05 April 2006 11:43, Panu Matilainen wrote: > > I don't see them imported into Extras, not to mention going through > > review and actually built. Sure, it's rawhide and I couldn't personally > > care less which way it breaks but... > > These were checked for deps (or so I was told) and where safe to remove. > Those things that still had deps were not removed, like gtk/glib. Right, I checked these for deps outside of themselves. If I messed it up, please let me know. Bill From notting at redhat.com Thu Apr 6 02:40:33 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Apr 2006 22:40:33 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060405144519.GB22325@redhat.com> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060405144519.GB22325@redhat.com> Message-ID: <20060406024033.GC10416@devserv.devel.redhat.com> Daniel Veillard (veillard at redhat.com) said: > I don't want to look painful, but can't we get rid of libxml1 too ? > And any depending app should really go to Extras IMHO... Actaully, it looks like, with the above removals, nothing in Core requires libxml. Extras requires are in: Gtk-Perl R-gnomeGUI (probably via libglade1). Any volunteers? :) Bill From bugs.michael at gmx.net Thu Apr 6 08:04:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 6 Apr 2006 10:04:06 +0200 Subject: Fedora Extras CVS problems In-Reply-To: References: Message-ID: <20060406100406.297adde4.bugs.michael@gmx.net> On Mon, 3 Apr 2006 11:07:27 -0400 (EDT), Chris Ricker wrote: > Looks like some garbage in several of the releases > > If I try to check out each release, I get: > > [kaboom at urd fedora-extras-cvs]$ cvs co FC-3 > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > cvs [checkout aborted]: there is no repository > /cvs/extras/rpms/gdesklets/FC-3 > [kaboom at urd fedora-extras-cvs]$ cvs co FC-4 > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > cvs [checkout aborted]: there is no repository /cvs/extras/rpms/fftw3/FC-4 > [kaboom at urd fedora-extras-cvs]$ cvs co FC-5 > For more information on using the Fedora source code repositories, > please visit http://fedoraproject.org/wiki/UsingCvs > cvs [checkout aborted]: there is no repository /cvs/extras/rpms/fftw3/FC-5 > [kaboom at urd fedora-extras-cvs]$ > > devel's working, but gdesklets is killing FC-3 and fftw3 is killing FC-4 > and FC-5 Fixed. But this indicates that there's an underlying problem related to the CVS module removal requests which contributors can request on the CVSSyncNeeded page in the Wiki. From veillard at redhat.com Thu Apr 6 09:13:31 2006 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 6 Apr 2006 05:13:31 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060406024033.GC10416@devserv.devel.redhat.com> References: <20060404165610.GA32313@devserv.devel.redhat.com> <20060405144519.GB22325@redhat.com> <20060406024033.GC10416@devserv.devel.redhat.com> Message-ID: <20060406091331.GH22325@redhat.com> On Wed, Apr 05, 2006 at 10:40:33PM -0400, Bill Nottingham wrote: > Daniel Veillard (veillard at redhat.com) said: > > I don't want to look painful, but can't we get rid of libxml1 too ? > > And any depending app should really go to Extras IMHO... > > Actaully, it looks like, with the above removals, nothing in > Core requires libxml. Extras requires are in: /me bounces all around ... it only took 5 years ! > Gtk-Perl > R-gnomeGUI > (probably via libglade1). > > Any volunteers? :) Please someone takes this off my plate :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 6 12:08:47 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 6 Apr 2006 14:08:47 +0200 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060406023714.GA10416@devserv.devel.redhat.com> References: <20060404165610.GA32313@devserv.devel.redhat.com> <1144242711.6227.48.camel@pmac.infradead.org> <4433E587.9060804@laiskiainen.org> <200604051839.02370.jkeating@j2solutions.net> <20060406023714.GA10416@devserv.devel.redhat.com> Message-ID: <20060406140847.75b5b7cf@python2> Bill Nottingham wrote : > Jesse Keating (jkeating at j2solutions.net) said: > > On Wednesday 05 April 2006 11:43, Panu Matilainen wrote: > > > I don't see them imported into Extras, not to mention going through > > > review and actually built. Sure, it's rawhide and I couldn't personally > > > care less which way it breaks but... > > > > These were checked for deps (or so I was told) and where safe to remove. > > Those things that still had deps were not removed, like gtk/glib. > > Right, I checked these for deps outside of themselves. If I messed > it up, please let me know. Well, so you know :-) package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomeui.so.32 libart_lgpl.so.2 libgnome.so.32 libgnomesupport.so.0 package: Gtk-Perl - 0.7008-40.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomeui.so.32 libgnome.so.32 libart_lgpl.so.2 libglade.so.0 libgtkxmhtml.so.1 libgnomesupport.so.0 libzvt.so.2 package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomeui.so.32 libgnome.so.32 libart_lgpl.so.2 libgnomesupport.so.0 gnome-libs >= 0:1.2 And the same for x86_64 and ppc. Brought to you by Michael Schwendt's neat automated dependency check. As for gnome-libs, it needs at least this fixed before getting into Extras : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184125 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2080_FC5 Load : 0.85 0.52 0.57 From notting at redhat.com Thu Apr 6 19:08:47 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Apr 2006 15:08:47 -0400 Subject: gtk+ stuff moving out of Core In-Reply-To: <20060406140847.75b5b7cf@python2> References: <20060404165610.GA32313@devserv.devel.redhat.com> <1144242711.6227.48.camel@pmac.infradead.org> <4433E587.9060804@laiskiainen.org> <200604051839.02370.jkeating@j2solutions.net> <20060406023714.GA10416@devserv.devel.redhat.com> <20060406140847.75b5b7cf@python2> Message-ID: <20060406190847.GB22348@devserv.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Bill Nottingham wrote : > > > Jesse Keating (jkeating at j2solutions.net) said: > > > On Wednesday 05 April 2006 11:43, Panu Matilainen wrote: > > > > I don't see them imported into Extras, not to mention going through > > > > review and actually built. Sure, it's rawhide and I couldn't personally > > > > care less which way it breaks but... > > > > > > These were checked for deps (or so I was told) and where safe to remove. > > > Those things that still had deps were not removed, like gtk/glib. > > > > Right, I checked these for deps outside of themselves. If I messed > > it up, please let me know. > > Well, so you know :-) Thanks! Hm, wonder if we can 'encourage' ports away from gnome1 to gnome2. :) Bill From ville.skytta at iki.fi Sun Apr 9 18:03:04 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 09 Apr 2006 21:03:04 +0300 Subject: xmms split Message-ID: <1144605784.27927.28.camel@localhost.localdomain> Hi, I've taken over xmms maintainership in Extras and split libxmms and plugins out of it into xmms-libs. This is so that other applications that can use xmms plugins can just pull in the library and plugins without bringing in the main app along with its file type associations etc. The split is only in devel for now, but I intend to push it to FE5 too next week. And if there's need for it, will consider adding a "Provides: xmms-libs = ..." to the FE4 package for forward compatibility. (If you want the latter, ping me.) There's a bit of fine tuning to do in various plugin and other packages, the main things worth noting being: - A dependency on libxmms.so.1 no longer pulls in the main xmms package - At least input and visualisation plugin packages should be considered candidates for having a dependency only on the libs package (explicitly or through an autogenerated libxmms.so.1 one), not the main xmms package I've already gone through all xmms dependent packages in FE and elsewhere and notified the maintainers in case I found some dependencies that should/could change. From notting at redhat.com Tue Apr 11 16:47:17 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Apr 2006 12:47:17 -0400 Subject: new for FC6 and later: Package Review! Message-ID: <20060411164716.GC13288@devserv.devel.redhat.com> One thing we're going to introduce for FC6 and later releases is package review of all new packages intended for Fedora Core. We're basing this off of the Extras Review process. Some quick FAQs before we go completely live: - Why? Peer review is good. Increasing quality by catching packaging errors before they go live is better.. Educating packagers so that packaging errors aren't repeated is even better than that. - How will it work? We hope to have more docs available soon, but, for noew, see the process at: http://fedoraproject.org/wiki/Extras/Contributors specifically, the sections on 'Make a Package, Upload Your Package, and Create Your Review Request'. The URL will be: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&format=core-review - What should a reviewer look for? See: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines - Who can review? We'd like to open this to the community both inside and outside Red Hat; it's the only way to really scale this. Moreover, by implementing the culture of review for both Core and Extras, we expect to be able to increase the number of available reviewers, to accelerate and better the process for both Core and Extras. - What about already existing packages? Throw them in the review system! Can't possibly hurt. Questions? Comments? Flames? Bill From jamatos at fc.up.pt Tue Apr 11 20:39:50 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 11 Apr 2006 21:39:50 +0100 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060411164716.GC13288@devserv.devel.redhat.com> References: <20060411164716.GC13288@devserv.devel.redhat.com> Message-ID: <200604112139.50542.jamatos@fc.up.pt> On Tuesday 11 April 2006 17:47, Bill Nottingham wrote: > Questions? Comments? Flames? Your message is 10 days late. ;-) > Bill -- Jos? Ab?lio From jkeating at redhat.com Tue Apr 11 20:42:44 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Apr 2006 16:42:44 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <200604112139.50542.jamatos@fc.up.pt> References: <20060411164716.GC13288@devserv.devel.redhat.com> <200604112139.50542.jamatos@fc.up.pt> Message-ID: <1144788164.18861.152.camel@ender> On Tue, 2006-04-11 at 21:39 +0100, Jose' Matos wrote: > Your message is 10 days late. ;-) This is not a joke. -- 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 jamatos at fc.up.pt Tue Apr 11 20:55:52 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 11 Apr 2006 21:55:52 +0100 Subject: new for FC6 and later: Package Review! In-Reply-To: <1144788164.18861.152.camel@ender> References: <20060411164716.GC13288@devserv.devel.redhat.com> <200604112139.50542.jamatos@fc.up.pt> <1144788164.18861.152.camel@ender> Message-ID: <200604112155.52424.jamatos@fc.up.pt> On Tuesday 11 April 2006 21:42, Jesse Keating wrote: > On Tue, 2006-04-11 at 21:39 +0100, Jose' Matos wrote: > > Your message is 10 days late. ;-) > > This is not a joke. Argh... you are spoiling the joke, but if you insist I will repeat: This message is 2 and half years late. ;-) I hope you get it this time. :-) Now for some thing on topic to avoid me going to several kill files, or the modern day equivalent of ****assassin (yes, it is a forbidden word ;-). I am quite happy to see this happen and I consider this rewarding considering the work done into Extras. Now as everything with Fedora we must wait to see how it goes but it is starting to look good really good. As we say here, better late than never. -- Jos? Ab?lio From bugs.michael at gmx.net Tue Apr 11 22:33:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Apr 2006 00:33:16 +0200 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060411164716.GC13288@devserv.devel.redhat.com> References: <20060411164716.GC13288@devserv.devel.redhat.com> Message-ID: <20060412003316.eeb6b02d.bugs.michael@gmx.net> On Tue, 11 Apr 2006 12:47:17 -0400, Bill Nottingham wrote: > One thing we're going to introduce for FC6 and later releases is > package review of all new packages intended for Fedora Core. > > We're basing this off of the Extras Review process. > > Some quick FAQs before we go completely live: > > - Why? > > Peer review is good. Increasing quality by catching packaging > errors before they go live is better.. Educating packagers so > that packaging errors aren't repeated is even better than that. It's really difficult to comment on this before it's seen in action. A few questions: Will it avoid incidents like this? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187714 Do Core package maintainers accept the current FE packaging guidelines? Or will reviews result in lengthy discussions about personal preferences? > The URL will be: > > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&format=core-review > Where's the tracker bug? Will bugzilla comments be posted to a mailing-list? From pnasrat at redhat.com Tue Apr 11 22:48:46 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 11 Apr 2006 18:48:46 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060412003316.eeb6b02d.bugs.michael@gmx.net> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> Message-ID: <1144795726.12763.16.camel@enki.eridu> On Wed, 2006-04-12 at 00:33 +0200, Michael Schwendt wrote: > On Tue, 11 Apr 2006 12:47:17 -0400, Bill Nottingham wrote: > > > One thing we're going to introduce for FC6 and later releases is > > package review of all new packages intended for Fedora Core. > > > > We're basing this off of the Extras Review process. > > > > Some quick FAQs before we go completely live: > > > > - Why? > > > > Peer review is good. Increasing quality by catching packaging > > errors before they go live is better.. Educating packagers so > > that packaging errors aren't repeated is even better than that. > > It's really difficult to comment on this before it's seen in action. > > A few questions: > > Will it avoid incidents like this? > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187714 If bugs are closed incorrectly they should be reopened - the reporter should have done that. The fact that Fedora contributors have bug rights means that this could happen with any packager/contributor. Paul From jspaleta at gmail.com Tue Apr 11 22:55:46 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Apr 2006 18:55:46 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060412003316.eeb6b02d.bugs.michael@gmx.net> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> Message-ID: <604aa7910604111555n3912538bied871711b5be3123@mail.gmail.com> On 4/11/06, Michael Schwendt wrote: > Will it avoid incidents like this? > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187714 Jeff isn't the rpm package maintainer for Core, so I'm not sure how package policy for Core can prevent situations with regard to how he or any other "upstream" developer on a codebase decides to use their bugzilla access. Whether or not Jeff should be closing out bugs like this is something you'll need to discuss with Jeff. Remember that pretty much every contributor has the ability to close out any bugreport.. not just the maintainers of a particular package. So if someone else other than the maintainer closes the bug out, you are free to reopen it and ask them to let the package maintainer decide to close it. The idea is to make it easier for other people to help out with janitorial work.. but that amount of open access will lead to disagreements which are not born of malice or even thought. The line between maintainer and upstream issue can be mis-drawn. In this particular case Jeff is using his bugzilla access to drive things upstrea, and if you feel he's closed the bug in error, reopen it. > Do Core package maintainers accept the current FE packaging guidelines? Or > will reviews result in lengthy discussions about personal preferences? Do all the Extras maintainers accept the current FE packaging guidelines? The guidelines are a living document and discussion among Extras maintainers still happens with regard to the merit of some of the required review items.. As long as the Core release team are prepared to crack the whip and to make the review requirements a requirement for all new packages..Core maintainers will have to accept it as policy. For things which are already in Core I know, based on discussion with some maintainers that they are willing to submit to a review and fix things as manpower and time allow. I'm sure those feelings are shared by all maintainers, especially those that are less active in Extras and/or community facing discussions generally. But you have to start somewhere to build up a culture change inside Core. -jef From jspaleta at gmail.com Tue Apr 11 23:02:34 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Apr 2006 19:02:34 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <604aa7910604111555n3912538bied871711b5be3123@mail.gmail.com> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> <604aa7910604111555n3912538bied871711b5be3123@mail.gmail.com> Message-ID: <604aa7910604111602x4995935cs1cf8534e855b4160@mail.gmail.com> On 4/11/06, Jeff Spaleta wrote: > For things which are already in Core I know, based on discussion with > some maintainers that they are willing to submit to a review and fix > things as manpower and time allow. I'm sure those feelings are shared > by all maintainers, especially those that are less active in Extras > and/or community facing discussions generally. But you have to start > somewhere to build up a culture change inside Core. Crap... need to correct that for it to actually make sense. For things which are already in Core I know, based on discussion with some maintainers that they are willing to submit to a review and fix things as manpower and time allow. I'm sure those feelings are NOT shared by all maintainers, especially those that are less active in Extras and/or community facing discussions generally. But you have to start somewhere to build up a culture change inside Core. -jef From mclasen at redhat.com Wed Apr 12 02:08:55 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 11 Apr 2006 22:08:55 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060411164716.GC13288@devserv.devel.redhat.com> References: <20060411164716.GC13288@devserv.devel.redhat.com> Message-ID: <1144807735.2083.1.camel@localhost.localdomain> On Tue, 2006-04-11 at 12:47 -0400, Bill Nottingham wrote: > One thing we're going to introduce for FC6 and later releases is > package review of all new packages intended for Fedora Core. Ok, to see how well this works in practise, lets start: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188661 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188666 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188668 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188677 These are review requests for the four packages that would result from splitting the current multi-tarball gnome-utils package, which is something we want to do for FC6. Matthias From notting at redhat.com Wed Apr 12 03:55:32 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Apr 2006 23:55:32 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060412003316.eeb6b02d.bugs.michael@gmx.net> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> Message-ID: <20060412035532.GB2883@devserv.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > Where's the tracker bug? Look for FC-NEW, FC-ACCEPT, etc. > Will bugzilla comments be posted to a > mailing-list? Got any ideas for a good one? Dumping it on fedora-maintainers seemed like overkill. Perhaps a fedora-package-review that has both Core and Extras? Bill From wtogami at redhat.com Wed Apr 12 18:51:24 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Apr 2006 14:51:24 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060412035532.GB2883@devserv.devel.redhat.com> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> <20060412035532.GB2883@devserv.devel.redhat.com> Message-ID: <443D4C2C.2070901@redhat.com> Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: >> Where's the tracker bug? > > Look for FC-NEW, FC-ACCEPT, etc. > >> Will bugzilla comments be posted to a >> mailing-list? > > Got any ideas for a good one? Dumping it on fedora-maintainers seemed > like overkill. Perhaps a fedora-package-review that has both Core > and Extras? I requested fedora-package-review. Both Core and Extras package review traffic will go there. Yet another small step toward blurring the differences between Core and Extras. More to come. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Apr 12 21:04:16 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Apr 2006 17:04:16 -0400 Subject: Fedora Package Reviews List Message-ID: <443D6B50.8020305@redhat.com> http://www.redhat.com/mailman/listinfo/fedora-package-review Bug Traffic of Package Reviews for the Fedora Distribution are delivered to this read-only list. For now Fedora Core package reviews are set to this list. I will be migrating Fedora Extras package reviews sometime soon. "Soon" by Fedora standards could be any year now. =) Warren Togami wtogami at redhat.com From rdieter at math.unl.edu Thu Apr 13 19:12:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Apr 2006 14:12:15 -0500 Subject: Fedora Package Reviews List In-Reply-To: <443D6B50.8020305__7379.37231683663$1144875887$gmane$org@redhat.com> References: <443D6B50.8020305__7379.37231683663$1144875887$gmane$org@redhat.com> Message-ID: <443EA28F.6050602@math.unl.edu> Warren Togami wrote: > http://www.redhat.com/mailman/listinfo/fedora-package-review As long as it's accessible via gmane.org... -- Rex From gauret at free.fr Thu Apr 13 20:06:48 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 13 Apr 2006 22:06:48 +0200 Subject: Fedora Package Reviews List In-Reply-To: <443EA28F.6050602@math.unl.edu> References: <443D6B50.8020305__7379.37231683663$1144875887$gmane$org@redhat.com> <443EA28F.6050602@math.unl.edu> Message-ID: <200604132206.48273.gauret@free.fr> > As long as it's accessible via gmane.org... I've just asked for it. Hope they won't crawl under the same request. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr One of the universal rules of happiness is: "Always be wary of any helpful item that weighs less than its operating manual". From rdieter at math.unl.edu Thu Apr 13 20:34:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Apr 2006 15:34:28 -0500 Subject: Fedora Package Reviews List In-Reply-To: <200604132206.48273.gauret@free.fr> References: <443D6B50.8020305__7379.37231683663$1144875887$gmane$org@redhat.com> <443EA28F.6050602@math.unl.edu> <200604132206.48273.gauret@free.fr> Message-ID: <443EB5D4.5000601@math.unl.edu> Aurelien Bompard wrote: >>As long as it's accessible via gmane.org... > I've just asked for it. Hope they won't crawl under the same request. Who is "they"? gmane or redhat? Either way, thanks. -- Rex From gauret at free.fr Thu Apr 13 21:02:26 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 13 Apr 2006 23:02:26 +0200 Subject: Fedora Package Reviews List In-Reply-To: <443EB5D4.5000601@math.unl.edu> References: <443D6B50.8020305__7379.37231683663$1144875887$gmane$org@redhat.com> <200604132206.48273.gauret@free.fr> <443EB5D4.5000601@math.unl.edu> Message-ID: <200604132302.26927.gauret@free.fr> > Who is "they"? gmane or redhat? Gmane. > Either way, thanks. No problem, I use this service a lot myself. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Make everything as simple as possible, but not simpler." -- Albert Einstein From andreas.bierfert at lowlatency.de Sat Apr 15 08:10:38 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 15 Apr 2006 10:10:38 +0200 Subject: File upload doesn't work In-Reply-To: <1143622945.3838.19.camel@perun.kabelta.loc> References: <1143622945.3838.19.camel@perun.kabelta.loc> Message-ID: <20060415101038.44f8ebfd@alkaid.a.lan> And again: [10:09 AM][awjb at alkaid ~/cvs/fedora/extras/rpms/wine-docs/FC-5]$ make new-sources FILES='wine-docs-0.9.12.tar.bz2' Checking : wine-docs-0.9.12.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 - 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From dcbw at redhat.com Sat Apr 15 21:26:48 2006 From: dcbw at redhat.com (Dan Williams) Date: Sat, 15 Apr 2006 17:26:48 -0400 Subject: File upload doesn't work In-Reply-To: <20060415101038.44f8ebfd@alkaid.a.lan> References: <1143622945.3838.19.camel@perun.kabelta.loc> <20060415101038.44f8ebfd@alkaid.a.lan> Message-ID: <1145136408.5963.4.camel@localhost.localdomain> On Sat, 2006-04-15 at 10:10 +0200, Andreas Bierfert wrote: > And again: > > > [10:09 AM][awjb at alkaid ~/cvs/fedora/extras/rpms/wine-docs/FC-5]$ make > new-sources FILES='wine-docs-0.9.12.tar.bz2' > > Checking : wine-docs-0.9.12.tar.bz2 on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check > remote file status make: *** [new-sources] Error 255 Is there a difference between 'make upload FILES=' and 'make new-sources FILES=' ? Dan From bugs.michael at gmx.net Sat Apr 15 21:46:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 15 Apr 2006 23:46:37 +0200 Subject: File upload doesn't work In-Reply-To: <1145136408.5963.4.camel@localhost.localdomain> References: <1143622945.3838.19.camel@perun.kabelta.loc> <20060415101038.44f8ebfd@alkaid.a.lan> <1145136408.5963.4.camel@localhost.localdomain> Message-ID: <20060415234637.296ce227.bugs.michael@gmx.net> On Sat, 15 Apr 2006 17:26:48 -0400, Dan Williams wrote: > On Sat, 2006-04-15 at 10:10 +0200, Andreas Bierfert wrote: > > And again: > > > > > > [10:09 AM][awjb at alkaid ~/cvs/fedora/extras/rpms/wine-docs/FC-5]$ make > > new-sources FILES='wine-docs-0.9.12.tar.bz2' > > > > Checking : wine-docs-0.9.12.tar.bz2 on > > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check > > remote file status make: *** [new-sources] Error 255 Two days ago Ville was hit by an expired client certificate (~/.fedora.cert) needed to download a fresh one at https://admin.fedoraproject.org/accounts/ > Is there a difference between 'make upload FILES=' and 'make new-sources > FILES=' ? That would be _very_ unusual. In Makefile.common, both use the same upload-request function, so there is no difference in accessing the lookaside cache server. The only difference between the two targets is that "make upload ..." appends successfully uploaded files to the "sources" file, whereas "make new-sources ..." starts with an empty "sources" file. From andreas.bierfert at lowlatency.de Sun Apr 16 21:53:53 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 16 Apr 2006 23:53:53 +0200 Subject: File upload doesn't work In-Reply-To: <20060415234637.296ce227.bugs.michael@gmx.net> References: <1143622945.3838.19.camel@perun.kabelta.loc> <20060415101038.44f8ebfd@alkaid.a.lan> <1145136408.5963.4.camel@localhost.localdomain> <20060415234637.296ce227.bugs.michael@gmx.net> Message-ID: <20060416235353.73abe62b@alkaid.a.lan> On Sat, 15 Apr 2006 23:46:37 +0200 Michael Schwendt wrote: > Two days ago Ville was hit by an expired client certificate > (~/.fedora.cert) needed to download a fresh one at > https://admin.fedoraproject.org/accounts/ Ah... seems same happened here... Though one would think of a different error message for this but anyways ;) Thanks for the help... - 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From katzj at redhat.com Mon Apr 17 17:16:20 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Apr 2006 13:16:20 -0400 Subject: Heads-up: Possible extras buildsys downtime Message-ID: <1145294180.26993.50.camel@orodruin.boston.redhat.com> Just a heads-up that the Extras build system may be down for a portion of tomorrow evening as the backend storage at the colo is moved around. The official downtime is from 0100-0700 UTC on 19 April. We should hopefully only have a minor blip, if at all, but was worth making everyone aware of it Jeremy From katzj at redhat.com Mon Apr 17 18:48:11 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Apr 2006 14:48:11 -0400 Subject: Fedora Core 6 Draft Schedule Message-ID: <1145299691.26993.90.camel@orodruin.boston.redhat.com> So one of the discussions that was held at FUDCon in Boston a week and a half ago was around the schedule for Fedora Core 6. We started off with a discussion around the merits of a six month vs a nine month schedule. While the longer schedule did allow us to get more "stuff" in, from my point of view of trying to get the release out, the more "stuff" actually made it significantly more difficult to finish the release. Also, a six month schedule tends to make it so that we line up better with a variety of other projects that we depend on. There was more, but suffice to say that the overwhelming consensus was that six month schedules work "better". So, given that, here's the pass at the schedule for Fedora Core 6. Note that there is a slight change from the discussion at FUDCon due to the Red Hat Summit -- trying to get test1 frozen and available to mirrors when the release team is in Nashville isn't likely to work :) The dates line up as 7 June - FC6 Test1 Development Freeze 14 June - FC6 Test1 Release 5 July - FC6 Test2 Development Freeze, feature freeze 12 July - FC6 Test2 Release 9 August - FC6 Test3 Development Freeze 16 August - FC6 Test3 Release 12 September - Final Devel Freeze. All package builds completed. 20 September - FC6 General Availability This is all reflected at http://fedoraproject.org/wiki/Core/Schedule -- we'll be trying to use this for the canonical schedule location rather than off of fedora.redhat.com to help make things easier for updating. Beyond just dates, I'd like to also propose an attempt to actually try to have some discipline around freezes also. With FC5, there were a lot of things which people wanted to get in late in the cycle. If we set the proper expectations up front, hopefully we can avoid some of the tension and mistaken expectations about the release process. So, I'd like for all "major" features to at least be starting to be in a testing state in time for Test1 with a drop-dead date (ie, the call is made on whether the feature is complete enough to make the release or if it should be dropped from the release and we'll pick it up the next time around) of the Test2 freeze. This will help to ensure that we're more functionally complete earlier and therefore have more testing and a better final release. Comments, feedback, etc? Jeremy From caolanm at redhat.com Tue Apr 18 08:08:36 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 18 Apr 2006 09:08:36 +0100 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145299691.26993.90.camel@orodruin.boston.redhat.com> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> Message-ID: <1145347716.28816.5.camel@localhost.localdomain> On Mon, 2006-04-17 at 14:48 -0400, Jeremy Katz wrote: > The dates line up as > 7 June - FC6 Test1 Development Freeze > 14 June - FC6 Test1 Release > 5 July - FC6 Test2 Development Freeze, feature freeze > 12 July - FC6 Test2 Release > 9 August - FC6 Test3 Development Freeze > 16 August - FC6 Test3 Release > 12 September - Final Devel Freeze. All package builds completed. > 20 September - FC6 General Availability > > This is all reflected at http://fedoraproject.org/wiki/Core/Schedule -- > we'll be trying to use this for the canonical schedule location rather > than off of fedora.redhat.com to help make things easier for updating. > > Beyond just dates, I'd like to also propose an attempt to actually try > to have some discipline around freezes also. With FC5, there were a lot > of things which people wanted to get in late in the cycle. If we set > the proper expectations up front, hopefully we can avoid some of the > tension and mistaken expectations about the release process. Perhaps it's worth noting where the various major packages that we ship keep their release schedules, and when they are. e.g. OOo's release schedule lives here http://wiki.services.openoffice.org/wiki/OOoRelease203 and the 2.0.3 release dates are compatible with the above FC6 deadlines. C. From katzj at redhat.com Tue Apr 18 12:47:37 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Apr 2006 08:47:37 -0400 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145347716.28816.5.camel@localhost.localdomain> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <1145347716.28816.5.camel@localhost.localdomain> Message-ID: <1145364457.2930.52.camel@aglarond.local> On Tue, 2006-04-18 at 09:08 +0100, Caolan McNamara wrote: > On Mon, 2006-04-17 at 14:48 -0400, Jeremy Katz wrote: > > The dates line up as > > 7 June - FC6 Test1 Development Freeze > > 14 June - FC6 Test1 Release > > 5 July - FC6 Test2 Development Freeze, feature freeze > > 12 July - FC6 Test2 Release > > 9 August - FC6 Test3 Development Freeze > > 16 August - FC6 Test3 Release > > 12 September - Final Devel Freeze. All package builds completed. > > 20 September - FC6 General Availability > > > > This is all reflected at http://fedoraproject.org/wiki/Core/Schedule -- > > we'll be trying to use this for the canonical schedule location rather > > than off of fedora.redhat.com to help make things easier for updating. > > > > Beyond just dates, I'd like to also propose an attempt to actually try > > to have some discipline around freezes also. With FC5, there were a lot > > of things which people wanted to get in late in the cycle. If we set > > the proper expectations up front, hopefully we can avoid some of the > > tension and mistaken expectations about the release process. > > Perhaps it's worth noting where the various major packages that we ship > keep their release schedules, and when they are. Although generally, we're probably not going to move the schedule around for just one project (miss this one, there's always the next release in six months), I can definitely see the value in having easy access to the schedules. I've gone ahead and added links at the bottom of the page for OOo and the GNOME schedule. Having others listed would be great! Jeremy From pjones at redhat.com Tue Apr 18 15:21:58 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 18 Apr 2006 11:21:58 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <20060412003316.eeb6b02d.bugs.michael@gmx.net> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> Message-ID: <1145373718.27679.20.camel@localhost.localdomain> On Wed, 2006-04-12 at 00:33 +0200, Michael Schwendt wrote: > Do Core package maintainers accept the current FE packaging guidelines? Or > will reviews result in lengthy discussions about personal preferences? Obviously, there will always be some contention. This isn't just due to personal egos; as more developers look at the guidelines, some legitimate issues are sure to be raised as well. That's life. -- Peter From skvidal at linux.duke.edu Tue Apr 18 15:28:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 18 Apr 2006 11:28:15 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <1145373718.27679.20.camel@localhost.localdomain> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> <1145373718.27679.20.camel@localhost.localdomain> Message-ID: <1145374095.1568.47.camel@cutter> On Tue, 2006-04-18 at 11:21 -0400, Peter Jones wrote: > On Wed, 2006-04-12 at 00:33 +0200, Michael Schwendt wrote: > > > Do Core package maintainers accept the current FE packaging guidelines? Or > > will reviews result in lengthy discussions about personal preferences? > > Obviously, there will always be some contention. This isn't just due to > personal egos; A Huge amount of the bullshit has been b/c of egos, though. -sv From bdpepple at ameritech.net Tue Apr 18 15:54:01 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 18 Apr 2006 11:54:01 -0400 Subject: new for FC6 and later: Package Review! In-Reply-To: <1145374095.1568.47.camel@cutter> References: <20060411164716.GC13288@devserv.devel.redhat.com> <20060412003316.eeb6b02d.bugs.michael@gmx.net> <1145373718.27679.20.camel@localhost.localdomain> <1145374095.1568.47.camel@cutter> Message-ID: <1145375641.14369.6.camel@shuttle.piedmont.com> On Tue, 2006-04-18 at 11:28 -0400, seth vidal wrote: > On Tue, 2006-04-18 at 11:21 -0400, Peter Jones wrote: > > On Wed, 2006-04-12 at 00:33 +0200, Michael Schwendt wrote: > > > > > Do Core package maintainers accept the current FE packaging guidelines? Or > > > will reviews result in lengthy discussions about personal preferences? > > > > Obviously, there will always be some contention. This isn't just due to > > personal egos; > > A Huge amount of the bullshit has been b/c of egos, though. > That's what I've noticed so far also, which really makes me unmotivated to look at these packages. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From tiemann at redhat.com Tue Apr 18 21:45:08 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Tue, 18 Apr 2006 17:45:08 -0400 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145364457.2930.52.camel@aglarond.local> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <1145347716.28816.5.camel@localhost.localdomain> <1145364457.2930.52.camel@aglarond.local> Message-ID: <1145396708.25446.43.camel@localhost.localdomain> On Tue, 2006-04-18 at 08:47 -0400, Jeremy Katz wrote: > Although generally, we're probably not going to move the schedule around > for just one project (miss this one, there's always the next release in > six months), I can definitely see the value in having easy access to the > schedules. I've gone ahead and added links at the bottom of the page > for OOo and the GNOME schedule. Having others listed would be great! A novel use for Google Calendar? M From jspaleta at gmail.com Tue Apr 18 21:54:52 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Apr 2006 17:54:52 -0400 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145299691.26993.90.camel@orodruin.boston.redhat.com> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> Message-ID: <604aa7910604181454q4471514fibea5d635a9d1889f@mail.gmail.com> On 4/17/06, Jeremy Katz wrote: > Comments, feedback, etc? Anyway we can have some restrictions on how late in the cycle items get punted out of Core? Or atleast some restrictions on the minimum amount of notice Extras maintainers are given with regard to the intent to punt something out of Core and some guidance as to what constitutes appropriate notice, so we can avoid a scramble to reimport something into Extras after it is dropped from Core. I'd like to be in a position where Extras maintainers can reasonable have enough time to get a soon to be dropped Core library through Extras review and in Extras cvs an ready to fire off a build as soon as its dropped from Core. This isn't the sort of thing Extras can dictate to Core, Core needs to have some established guidance to make sure this sort of thing gets communicated in a way that Extras maintainers are not caught with their pants down with 2 weeks before final release. -jef From katzj at redhat.com Tue Apr 18 22:00:25 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Apr 2006 18:00:25 -0400 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <604aa7910604181454q4471514fibea5d635a9d1889f@mail.gmail.com> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <604aa7910604181454q4471514fibea5d635a9d1889f@mail.gmail.com> Message-ID: <1145397625.2463.72.camel@orodruin.boston.redhat.com> On Tue, 2006-04-18 at 17:54 -0400, Jeff Spaleta wrote: > On 4/17/06, Jeremy Katz wrote: > > Comments, feedback, etc? > > Anyway we can have some restrictions on how late in the cycle items > get punted out of Core? Or atleast some restrictions on the minimum > amount of notice Extras maintainers are given with regard to the > intent to punt something out of Core and some guidance as to what > constitutes appropriate notice, so we can avoid a scramble to reimport > something into Extras after it is dropped from Core. Personally, I think this falls (largely) into the category of feature freeze. Calling out "end of new module/module removal" makes sense. Granted, if we're 200k over the size of a CD, we'll probably end up making the call of remove something, but those should be exception cases that we wave our hands wildly about, and not the norm. > I'd like to be in a position where Extras maintainers can reasonable > have enough time to get a soon to be dropped Core library through > Extras review and in Extras cvs an ready to fire off a build as soon > as its dropped from Core. This isn't the sort of thing Extras can > dictate to Core, Core needs to have some established guidance to make > sure this sort of thing gets communicated in a way that Extras > maintainers are not caught with their pants down with 2 weeks before > final release. In general, I'm trying to get a little bit of better notification in place for handling of the Core/Extras divide by delegating the addition of some steps to the process ;) Jeremy From jwboyer at jdub.homelinux.org Wed Apr 19 01:14:27 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 18 Apr 2006 20:14:27 -0500 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145396708.25446.43.camel@localhost.localdomain> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <1145347716.28816.5.camel@localhost.localdomain> <1145364457.2930.52.camel@aglarond.local> <1145396708.25446.43.camel@localhost.localdomain> Message-ID: <1145409268.24535.0.camel@yoda.jdub.homelinux.org> On Tue, 2006-04-18 at 17:45 -0400, Michael Tiemann wrote: > On Tue, 2006-04-18 at 08:47 -0400, Jeremy Katz wrote: > > > Although generally, we're probably not going to move the schedule around > > for just one project (miss this one, there's always the next release in > > six months), I can definitely see the value in having easy access to the > > schedules. I've gone ahead and added links at the bottom of the page > > for OOo and the GNOME schedule. Having others listed would be great! > > A novel use for Google Calendar? I can set that up and make it public if people are interested. josh From jwboyer at jdub.homelinux.org Wed Apr 19 02:19:15 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 18 Apr 2006 21:19:15 -0500 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145409268.24535.0.camel@yoda.jdub.homelinux.org> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <1145347716.28816.5.camel@localhost.localdomain> <1145364457.2930.52.camel@aglarond.local> <1145396708.25446.43.camel@localhost.localdomain> <1145409268.24535.0.camel@yoda.jdub.homelinux.org> Message-ID: <1145413155.24941.4.camel@yoda.jdub.homelinux.org> On Tue, 2006-04-18 at 20:14 -0500, Josh Boyer wrote: > On Tue, 2006-04-18 at 17:45 -0400, Michael Tiemann wrote: > > On Tue, 2006-04-18 at 08:47 -0400, Jeremy Katz wrote: > > > > > Although generally, we're probably not going to move the schedule around > > > for just one project (miss this one, there's always the next release in > > > six months), I can definitely see the value in having easy access to the > > > schedules. I've gone ahead and added links at the bottom of the page > > > for OOo and the GNOME schedule. Having others listed would be great! > > > > A novel use for Google Calendar? > > I can set that up and make it public if people are interested. I got bored and did it anyway. http://www.google.com/calendar/ical/18n9a7am4euol1d8uuub8u8ou8 at group.calendar.google.com/public/basic or http://www.google.com/calendar/feeds/18n9a7am4euol1d8uuub8u8ou8 at group.calendar.google.com/public/basic I'll add schedule info from other projects as I find time. josh From katzj at redhat.com Wed Apr 19 14:47:26 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 19 Apr 2006 10:47:26 -0400 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <4445BFBB.7040100@redhat.com> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> <4445BFBB.7040100@redhat.com> Message-ID: <1145458046.5386.0.camel@orodruin.boston.redhat.com> On Wed, 2006-04-19 at 10:12 +0530, A S Alam wrote: > can we include "Translation" word some where, so that Translation Teams > can get Deadline for GUI like Gnome? Yep -- the plan was just to start with the high-level schedule and then work with the leaders of the parts of Fedora other than just the code (including docs and translation) to ensure that there are deadlines in place for their needs Jeremy From skvidal at linux.duke.edu Thu Apr 20 00:28:27 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 19 Apr 2006 20:28:27 -0400 Subject: Extras buildsys downtime Message-ID: <1145492907.12794.10.camel@cutter> Hi, We were planning on doing this tonight but given that this rsync is taking longer than expected and that I'd like to double-check all the steps we'll move the time around a bit. Thursday starting at: 10:00 EDT (GMT-4) 09:00 CDT (GMT-5) 08:00 MDT (GMT-6) 07:00 PDT (GMT-7) and 14:00 UTC And hopefully ending w/i 1 hour - but 2 hours is the MAX. The extras buildsystem will be down to upgrade the OS on the build master. Thanks! -sv From jpo at lsd.di.uminho.pt Thu Apr 20 14:31:13 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 20 Apr 2006 15:31:13 +0100 Subject: Perl modules that could be update Message-ID: <44479B31.7060303@lsd.di.uminho.pt> Hi, The attached file contains a list of perl modules that can/could be updated. Right now the script compares the FE5 perl-* SRPMs versions against the ones that exist in CPAN. The script still needs to be improved as there are a lot of exceptions to handle: perl modules that don't exist in CPAN, problems in parsing the CPAN modules list, version comparisons, ... In the future I'm planning to also check the binary perl-* RPMS and execute a couple more tests: site vs vendor perl dirs, look for provides like perl(main), doc files permissions, ... Suggestions are welcome, 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 * -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: report20060420.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 paul at city-fan.org Thu Apr 20 14:39:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 20 Apr 2006 15:39:27 +0100 Subject: Perl modules that could be update In-Reply-To: <44479B31.7060303@lsd.di.uminho.pt> References: <44479B31.7060303@lsd.di.uminho.pt> Message-ID: <44479D1F.7020500@city-fan.org> Jose Pedro Oliveira wrote: > Hi, > > The attached file contains a list of perl modules that can/could be > updated. Right now the script compares the FE5 perl-* SRPMs versions > against the ones that exist in CPAN. The script still needs to be > improved as there are a lot of exceptions to handle: perl modules that > don't exist in CPAN, problems in parsing the CPAN modules list, version > comparisons, ... > > In the future I'm planning to also check the binary perl-* RPMS and > execute a couple more tests: site vs vendor perl dirs, look for provides > like perl(main), doc files permissions, ... > > Suggestions are welcome, > jpo ... > Licenses > ---------------------------------------------------------------------- > 18 Artistic > 12 Artistic or GPL > 1 BSD-style > 1 BSDish > 7 Distributable Which ones are "Distributable"? I'd have thought something more specific would be required for Extras packages. Paul. From jpo at lsd.di.uminho.pt Thu Apr 20 15:04:13 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 20 Apr 2006 16:04:13 +0100 Subject: Perl modules (license: distributable) In-Reply-To: <44479D1F.7020500@city-fan.org> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> Message-ID: <4447A2ED.9030501@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Jose Pedro Oliveira wrote: ... >> Licenses >> ---------------------------------------------------------------------- >> 18 Artistic >> 12 Artistic or GPL >> 1 BSD-style >> 1 BSDish >> 7 Distributable > > Which ones are "Distributable"? I'd have thought something more specific > would be required for Extras packages. License: distributable - ---- perl-Lingua-EN-Inflect-Number - Distributable perl-Mail-Sender - Distributable perl-Mail-Sendmail - Distributable perl-Crypt-Blowfish - Distributable perl-Time-modules - Distributable perl-Class-DBI-Loader-Relationship - Distributable perl-UNIVERSAL-exports - Distributable - ---- The Mail::Sender module has the following license: "This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. There is only one aditional condition, you may NOT use this module for SPAMing! NEVER! (see http://spam.abuse.net/ for definition)" 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFER6Ltl0metZG9hRsRAt56AKCcciV2YqqwPfj9JsjVla8d5L6S/QCgzK8I CkHf85bOyhlIgUXD+jXGcAk= =BnMg -----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 tibbs at math.uh.edu Thu Apr 20 15:39:31 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 20 Apr 2006 10:39:31 -0500 Subject: Perl modules (license: distributable) In-Reply-To: <4447A2ED.9030501@lsd.di.uminho.pt> (Jose Pedro Oliveira's message of "Thu, 20 Apr 2006 16:04:13 +0100") References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> Message-ID: >>>>> "JPO" == Jose Pedro Oliveira writes: JPO> The Mail::Sender module has the following license: "This program JPO> is free software; you can redistribute it and/or modify it under JPO> the same terms as Perl itself. There is only one aditional JPO> condition, you may NOT use this module for SPAMing! NEVER! (see JPO> http://spam.abuse.net/ for definition)" Nice and contradictory; perl is GPL (and Artistic, of course) and the GPL prevents adding restrictions. The module shouldn't have been included. Crypt::Blowfish just says: ---- The implementation of the Blowfish algorithm was developed by, and is copyright of, A.M. Kuchling. Other parts of the perl extension and module are copyright of Systemics Ltd ( http://www.systemics.com/ ). Code revisions, updates, and standalone release are copyright 1999-2001 W3Works, LLC. ---- I expect this kind of thing is repeated; there's a copyright, but it gives no hint that it can be redistributed. Everyone assumes that it's implicit because the author uploaded it to CPAN, but CPAN explicitly says that you can't assume that. At least one other module is held up in review for just this issue. (perl-Log-Dispatch-FileRotate, I think). Each of these "Distributable" modules needs a rereview and will probably have to be pulled unless the authors will clarify. I know Crypt::Blowfish has modules which depend on it, so this will cause problems. - J< From paul at city-fan.org Thu Apr 20 15:46:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 20 Apr 2006 16:46:48 +0100 Subject: Perl modules (license: distributable) In-Reply-To: References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> Message-ID: <4447ACE8.6090301@city-fan.org> Jason L Tibbitts III wrote: >>>>>> "JPO" == Jose Pedro Oliveira writes: > > JPO> The Mail::Sender module has the following license: "This program > JPO> is free software; you can redistribute it and/or modify it under > JPO> the same terms as Perl itself. There is only one aditional > JPO> condition, you may NOT use this module for SPAMing! NEVER! (see > JPO> http://spam.abuse.net/ for definition)" > > Nice and contradictory; perl is GPL (and Artistic, of course) and the > GPL prevents adding restrictions. The module shouldn't have been > included. > > Crypt::Blowfish just says: > > ---- > The implementation of the Blowfish algorithm was developed by, > and is copyright of, A.M. Kuchling. > > Other parts of the perl extension and module are > copyright of Systemics Ltd ( http://www.systemics.com/ ). > > Code revisions, updates, and standalone release are copyright > 1999-2001 W3Works, LLC. > ---- > > I expect this kind of thing is repeated; there's a copyright, but it > gives no hint that it can be redistributed. Everyone assumes that > it's implicit because the author uploaded it to CPAN, but CPAN > explicitly says that you can't assume that. At least one other module > is held up in review for just this issue. > (perl-Log-Dispatch-FileRotate, I think). Same with perl-RPM2 > Each of these "Distributable" modules needs a rereview and will > probably have to be pulled unless the authors will clarify. I know > Crypt::Blowfish has modules which depend on it, so this will cause > problems. Including the packages of mine you approved yesterday :-) Paul. From jpo at lsd.di.uminho.pt Thu Apr 20 16:42:03 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 20 Apr 2006 17:42:03 +0100 Subject: Perl modules (license: distributable) In-Reply-To: <4447ACE8.6090301@city-fan.org> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> <4447ACE8.6090301@city-fan.org> Message-ID: <4447B9DB.1020507@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Jason L Tibbitts III wrote: ... >> I expect this kind of thing is repeated; there's a copyright, but it >> gives no hint that it can be redistributed. Everyone assumes that >> it's implicit because the author uploaded it to CPAN, but CPAN >> explicitly says that you can't assume that. At least one other module >> is held up in review for just this issue. >> (perl-Log-Dispatch-FileRotate, I think). > > Same with perl-RPM2 The perl modules RPM2 and RPM::Specfile don't include any copyright information in the tarballs but they are both authored by Chip Turner which has been a RedHat empolyee for several years. Several months ago, after Chip Turner left Red Hat, I opened two tickets in rt.cpan (one against RPM2 and a second one against RPM::Specfile) asking him to add copyright information to the tarballs (no answer until now). I don't know if Warren is still able to contact him. 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFER7nbl0metZG9hRsRAnlpAKDDJjjHUJwDB84+T8AWLyzA3S3tPgCgpDUd u7hxYELsup8UJTYSWvIjFDE= =E2eH -----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 aalam at redhat.com Wed Apr 19 04:42:35 2006 From: aalam at redhat.com (A S Alam) Date: Wed, 19 Apr 2006 10:12:35 +0530 Subject: Fedora Core 6 Draft Schedule In-Reply-To: <1145299691.26993.90.camel@orodruin.boston.redhat.com> References: <1145299691.26993.90.camel@orodruin.boston.redhat.com> Message-ID: <4445BFBB.7040100@redhat.com> Jeremy Katz ?? ?????: > So one of the discussions that was held at FUDCon in Boston a week and a > half ago was around the schedule for Fedora Core 6. > > We started off with a discussion around the merits of a six month vs a > nine month schedule. While the longer schedule did allow us to get more > "stuff" in, from my point of view of trying to get the release out, the > more "stuff" actually made it significantly more difficult to finish the > release. Also, a six month schedule tends to make it so that we line up > better with a variety of other projects that we depend on. There was > more, but suffice to say that the overwhelming consensus was that six > month schedules work "better". > > So, given that, here's the pass at the schedule for Fedora Core 6. Note > that there is a slight change from the discussion at FUDCon due to the > Red Hat Summit -- trying to get test1 frozen and available to mirrors > when the release team is in Nashville isn't likely to work :) > > The dates line up as > 7 June - FC6 Test1 Development Freeze > 14 June - FC6 Test1 Release > 5 July - FC6 Test2 Development Freeze, feature freeze > 12 July - FC6 Test2 Release > 9 August - FC6 Test3 Development Freeze > 16 August - FC6 Test3 Release > 12 September - Final Devel Freeze. All package builds completed. > 20 September - FC6 General Availability > can we include "Translation" word some where, so that Translation Teams can get Deadline for GUI like Gnome? regards -- A S Alam join us at #fedora-l10n (freenode) "Either find a way or make one" From mattdm at mattdm.org Thu Apr 20 20:18:54 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 Apr 2006 16:18:54 -0400 Subject: Perl modules (license: distributable) In-Reply-To: References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> Message-ID: <20060420201854.GA25861@jadzia.bu.edu> On Thu, Apr 20, 2006 at 10:39:31AM -0500, Jason L Tibbitts III wrote: > JPO> The Mail::Sender module has the following license: "This program > JPO> is free software; you can redistribute it and/or modify it under > JPO> the same terms as Perl itself. There is only one aditional > JPO> condition, you may NOT use this module for SPAMing! NEVER! (see > JPO> http://spam.abuse.net/ for definition)" > Nice and contradictory; perl is GPL (and Artistic, of course) and the > GPL prevents adding restrictions. The module shouldn't have been > included. Nothing prevents you from licensing your code as "GPL + additional restrictions". You just can't add additional restrictions to code that was licensed _to you_ under the GPL. And of course, any such additional restrictions make the result not GPL-compatible. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From garrick at usc.edu Fri Apr 21 07:25:53 2006 From: garrick at usc.edu (Garrick Staples) Date: Fri, 21 Apr 2006 00:25:53 -0700 Subject: Perl modules (license: distributable) In-Reply-To: <20060420201854.GA25861@jadzia.bu.edu> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> <20060420201854.GA25861@jadzia.bu.edu> Message-ID: <20060421072553.GA21989@polop.usc.edu> On Thu, Apr 20, 2006 at 04:18:54PM -0400, Matthew Miller alleged: > On Thu, Apr 20, 2006 at 10:39:31AM -0500, Jason L Tibbitts III wrote: > > JPO> The Mail::Sender module has the following license: "This program > > JPO> is free software; you can redistribute it and/or modify it under > > JPO> the same terms as Perl itself. There is only one aditional > > JPO> condition, you may NOT use this module for SPAMing! NEVER! (see > > JPO> http://spam.abuse.net/ for definition)" > > Nice and contradictory; perl is GPL (and Artistic, of course) and the > > GPL prevents adding restrictions. The module shouldn't have been > > included. > > Nothing prevents you from licensing your code as "GPL + additional > restrictions". You just can't add additional restrictions to code that was > licensed _to you_ under the GPL. And of course, any such additional > restrictions make the result not GPL-compatible. Not that I disagree with you, but that limit on usage, even for spamming, still violates the FSF free software definition. "The freedom to run the program, for any purpose" "any kind of person or organization to use it on any kind of computer system, for any kind of overall job" -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 21 09:16:41 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 21 Apr 2006 11:16:41 +0200 Subject: Perl modules (license: distributable) In-Reply-To: <20060421072553.GA21989@polop.usc.edu> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> <20060420201854.GA25861@jadzia.bu.edu> <20060421072553.GA21989@polop.usc.edu> Message-ID: <20060421111641.4fb0f5b1@python2> Garrick Staples wrote : > On Thu, Apr 20, 2006 at 04:18:54PM -0400, Matthew Miller alleged: > > On Thu, Apr 20, 2006 at 10:39:31AM -0500, Jason L Tibbitts III wrote: > > > JPO> The Mail::Sender module has the following license: "This program > > > JPO> is free software; you can redistribute it and/or modify it under > > > JPO> the same terms as Perl itself. There is only one aditional > > > JPO> condition, you may NOT use this module for SPAMing! NEVER! (see > > > JPO> http://spam.abuse.net/ for definition)" > > > Nice and contradictory; perl is GPL (and Artistic, of course) and the > > > GPL prevents adding restrictions. The module shouldn't have been > > > included. > > > > Nothing prevents you from licensing your code as "GPL + additional > > restrictions". You just can't add additional restrictions to code that was > > licensed _to you_ under the GPL. And of course, any such additional > > restrictions make the result not GPL-compatible. > > Not that I disagree with you, but that limit on usage, even for > spamming, still violates the FSF free software definition. > > "The freedom to run the program, for any purpose" > > "any kind of person or organization to use it on any kind of computer > system, for any kind of overall job" Yeah, problematic situation. The worst part is : Do you really think spammers would even care? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.25 0.70 0.97 From paul at city-fan.org Fri Apr 21 09:47:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Apr 2006 10:47:30 +0100 Subject: Perl modules (license: distributable) In-Reply-To: <20060421111641.4fb0f5b1@python2> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> <20060420201854.GA25861@jadzia.bu.edu> <20060421072553.GA21989@polop.usc.edu> <20060421111641.4fb0f5b1@python2> Message-ID: <4448AA32.6040002@city-fan.org> Matthias Saou wrote: > Garrick Staples wrote : > >> On Thu, Apr 20, 2006 at 04:18:54PM -0400, Matthew Miller alleged: >>> On Thu, Apr 20, 2006 at 10:39:31AM -0500, Jason L Tibbitts III wrote: >>>> JPO> The Mail::Sender module has the following license: "This program >>>> JPO> is free software; you can redistribute it and/or modify it under >>>> JPO> the same terms as Perl itself. There is only one aditional >>>> JPO> condition, you may NOT use this module for SPAMing! NEVER! (see >>>> JPO> http://spam.abuse.net/ for definition)" >>>> Nice and contradictory; perl is GPL (and Artistic, of course) and the >>>> GPL prevents adding restrictions. The module shouldn't have been >>>> included. >>> Nothing prevents you from licensing your code as "GPL + additional >>> restrictions". You just can't add additional restrictions to code that was >>> licensed _to you_ under the GPL. And of course, any such additional >>> restrictions make the result not GPL-compatible. >> Not that I disagree with you, but that limit on usage, even for >> spamming, still violates the FSF free software definition. >> >> "The freedom to run the program, for any purpose" >> >> "any kind of person or organization to use it on any kind of computer >> system, for any kind of overall job" > > Yeah, problematic situation. The worst part is : Do you really think > spammers would even care? No, they wouldn't. I've personally received spam with an X-Mailer suggesting that Mail::Sender was used. Paul. From jnovy at redhat.com Fri Apr 21 11:14:06 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 21 Apr 2006 13:14:06 +0200 Subject: extras buildsys broken? Message-ID: <1145618046.5298.12.camel@localhost.localdomain> Hi, I successfully imported bsdiff package after approval to extras CVS, but when trying to build it I see: $ /usr/bin/plague-client build bsdiff bsdiff-4_3-1_fc6 devel Error connecting to build server: '(113, 'No route to host')' The plague client config ~/.plague-client.cfg points to https://buildsys.fedoraproject.org:8887 but: $ host buildsys.fedoraproject.org extras64.linux.duke.edu has address 152.3.220.164 $ telnet 152.3.220.164 8887 Trying 152.3.220.164... telnet: connect to address 152.3.220.164: No route to host telnet: Unable to connect to remote host: No route to host Thanks for help. Jindrich From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 21 11:26:11 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 21 Apr 2006 13:26:11 +0200 Subject: extras buildsys broken? In-Reply-To: <1145618046.5298.12.camel@localhost.localdomain> References: <1145618046.5298.12.camel@localhost.localdomain> Message-ID: <20060421132611.2a83ca54@python2> Jindrich Novy wrote : > I successfully imported bsdiff package after approval to extras CVS, but > when trying to build it I see: > > $ /usr/bin/plague-client build bsdiff bsdiff-4_3-1_fc6 devel > Error connecting to build server: '(113, 'No route to host')' [...] Same here, and the web server on that host doesn't respond currently either. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.78 0.65 0.57 From skvidal at linux.duke.edu Fri Apr 21 11:50:07 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 21 Apr 2006 07:50:07 -0400 Subject: extras buildsys broken? In-Reply-To: <20060421132611.2a83ca54@python2> References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> Message-ID: <1145620207.7813.10.camel@cutter> On Fri, 2006-04-21 at 13:26 +0200, Matthias Saou wrote: > Jindrich Novy wrote : > > > I successfully imported bsdiff package after approval to extras CVS, but > > when trying to build it I see: > > > > $ /usr/bin/plague-client build bsdiff bsdiff-4_3-1_fc6 devel > > Error connecting to build server: '(113, 'No route to host')' > [...] > > Same here, and the web server on that host doesn't respond currently > either. > Yes, It is down. I posted yesterday about a downtime. It due to network and scheduling problems has taken much longer. We'll get it taken care of today. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 21 14:07:53 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 21 Apr 2006 16:07:53 +0200 Subject: extras buildsys broken? In-Reply-To: <1145620207.7813.10.camel@cutter> References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> <1145620207.7813.10.camel@cutter> Message-ID: <20060421160753.4e14990f@python2> seth vidal wrote : > On Fri, 2006-04-21 at 13:26 +0200, Matthias Saou wrote: > > Jindrich Novy wrote : > > > > > I successfully imported bsdiff package after approval to extras CVS, but > > > when trying to build it I see: > > > > > > $ /usr/bin/plague-client build bsdiff bsdiff-4_3-1_fc6 devel > > > Error connecting to build server: '(113, 'No route to host')' > > [...] > > > > Same here, and the web server on that host doesn't respond currently > > either. > > > > Yes, It is down. I posted yesterday about a downtime. It due to network > and scheduling problems has taken much longer. We'll get it taken care > of today. That's what I suspected :-) Currently, I can't upload new sources through "make new-sources FILES=", is that related in any way? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.17 0.39 0.42 From skvidal at linux.duke.edu Fri Apr 21 14:13:06 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 21 Apr 2006 10:13:06 -0400 Subject: extras buildsys broken? In-Reply-To: <20060421160753.4e14990f@python2> References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> <1145620207.7813.10.camel@cutter> <20060421160753.4e14990f@python2> Message-ID: <1145628787.9912.0.camel@cutter> On Fri, 2006-04-21 at 16:07 +0200, Matthias Saou wrote: > seth vidal wrote : > > > On Fri, 2006-04-21 at 13:26 +0200, Matthias Saou wrote: > > > Jindrich Novy wrote : > > > > > > > I successfully imported bsdiff package after approval to extras CVS, but > > > > when trying to build it I see: > > > > > > > > $ /usr/bin/plague-client build bsdiff bsdiff-4_3-1_fc6 devel > > > > Error connecting to build server: '(113, 'No route to host')' > > > [...] > > > > > > Same here, and the web server on that host doesn't respond currently > > > either. > > > > > > > Yes, It is down. I posted yesterday about a downtime. It due to network > > and scheduling problems has taken much longer. We'll get it taken care > > of today. > > That's what I suspected :-) > Currently, I can't upload new sources through "make new-sources FILES=", > is that related in any way? > nope. -sv From kaboom at oobleck.net Fri Apr 21 14:13:04 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 21 Apr 2006 10:13:04 -0400 (EDT) Subject: extras buildsys broken? In-Reply-To: <1145628787.9912.0.camel@cutter> References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> <1145620207.7813.10.camel@cutter> <20060421160753.4e14990f@python2> <1145628787.9912.0.camel@cutter> Message-ID: On Fri, 21 Apr 2006, seth vidal wrote: > > That's what I suspected :-) > > Currently, I can't upload new sources through "make new-sources FILES=", > > is that related in any way? > > > > nope. If you get some sort of cryptic error uploading files, it may be that your cert is expired -- happened to me yesterday later, chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 21 14:52:36 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 21 Apr 2006 16:52:36 +0200 Subject: extras buildsys broken? In-Reply-To: References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> <1145620207.7813.10.camel@cutter> <20060421160753.4e14990f@python2> <1145628787.9912.0.camel@cutter> Message-ID: <20060421165236.7d4bc991@python2> Chris Ricker wrote : > On Fri, 21 Apr 2006, seth vidal wrote: > > > > That's what I suspected :-) > > > Currently, I can't upload new sources through "make new-sources FILES=", > > > is that related in any way? > > > > nope. > > If you get some sort of cryptic error uploading files, it may be that your > cert is expired -- happened to me yesterday Seems like that was it, thanks for the tip. The error was : Checking : proftpd-1.3.0.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 If it could easily be changed to something like "Your client certificate has expired", it would definitely be a useful improvement. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.03 0.22 0.31 From qspencer at ieee.org Fri Apr 21 15:20:42 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 21 Apr 2006 10:20:42 -0500 Subject: extras buildsys broken? In-Reply-To: <20060421165236.7d4bc991@python2> References: <1145618046.5298.12.camel@localhost.localdomain> <20060421132611.2a83ca54@python2> <1145620207.7813.10.camel@cutter> <20060421160753.4e14990f@python2> <1145628787.9912.0.camel@cutter> <20060421165236.7d4bc991@python2> Message-ID: <4448F84A.6030300@ieee.org> Matthias Saou wrote: > Chris Ricker wrote : > > >> On Fri, 21 Apr 2006, seth vidal wrote: >> >> >>>> That's what I suspected :-) >>>> Currently, I can't upload new sources through "make new-sources FILES=", >>>> is that related in any way? >>>> >>> nope. >>> >> If you get some sort of cryptic error uploading files, it may be that your >> cert is expired -- happened to me yesterday >> > > Seems like that was it, thanks for the tip. The error was : > > Checking : proftpd-1.3.0.tar.bz2 on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-sources] Error 255 > > If it could easily be changed to something like "Your client certificate > has expired", it would definitely be a useful improvement. > +1 I had the same thing happen yesterday and was going to request the same feature. -Quentin From mattdm at mattdm.org Sat Apr 22 15:27:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 22 Apr 2006 11:27:33 -0400 Subject: Perl modules (license: distributable) In-Reply-To: <20060421072553.GA21989@polop.usc.edu> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> <20060420201854.GA25861@jadzia.bu.edu> <20060421072553.GA21989@polop.usc.edu> Message-ID: <20060422152733.GA9334@jadzia.bu.edu> On Fri, Apr 21, 2006 at 12:25:53AM -0700, Garrick Staples wrote: > Not that I disagree with you, but that limit on usage, even for > spamming, still violates the FSF free software definition. > "The freedom to run the program, for any purpose" > "any kind of person or organization to use it on any kind of computer > system, for any kind of overall job" I agree that it's problematic and unfortunately unacceptable for Fedora. And furthermore rather pointless. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Sun Apr 23 19:00:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Apr 2006 21:00:59 +0200 Subject: RFC: FESCO future Message-ID: <1145818859.2767.45.camel@localhost.localdomain> Just FYI, the Fedora Extras Steering Commitee is now round about a year old and it's time for a rotations/some fresh blood and ideas. I proposed a rough plan for that in https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01383.html Please discuss on fedora-extras-list! CU thl -- Thorsten Leemhuis From tcallawa at redhat.com Sun Apr 23 22:30:30 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 23 Apr 2006 17:30:30 -0500 Subject: Perl modules (license: distributable) In-Reply-To: <4447A2ED.9030501@lsd.di.uminho.pt> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> Message-ID: <1145831430.19474.42.camel@localhost.localdomain> On Thu, 2006-04-20 at 16:04 +0100, Jose Pedro Oliveira wrote: > License: distributable > - ---- > perl-Lingua-EN-Inflect-Number - Distributable Attempted to communicate with upstream author, no response. Code has not been touched since 2004. Unfortunately, this is a hard requirement for Maypole. jpo approved this: http://www.redhat.com/archives/fedora-extras-list/2005-July/msg01489.html Debian thinks this is GPL or Artistic, I think it is safe to assume they heard from the author at some point: http://packages.debian.org/changelogs/pool/main/libl/liblingua-en-inflect-number-perl/liblingua-en-inflect-number-perl_1.1-1/liblingua-en-inflect-number-perl.copyright > perl-Class-DBI-Loader-Relationship - Distributable Same author as Lingua::EN::Inflect::Number. Code has not been touched since 2004, hard requirement for Maypole. Debian thinks this is GPL or Artistic, I think it is safe to assume they heard from the author at some point: http://packages.debian.org/changelogs/pool/main/libc/libclass-dbi-loader-relationship-perl/libclass-dbi-loader-relationship-perl_1.2-1/libclass-dbi-loader-relationship-perl.copyright I emailed the author again, but it looks safe to follow Debian here. > perl-UNIVERSAL-exports - Distributable This should be GPL or Artistic. Looks like Debian managed to get a response from the author at some point, based on this post, and the current copyright setting: http://lists.debian.org/debian-devel/2002/07/msg00789.html http://packages.debian.org/changelogs/pool/main/libu/libuniversal-exports-perl/libuniversal-exports-perl_0.03-8/libuniversal-exports-perl.copyright Unless anyone is opposed to following Debian, I'll make these changes soon. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Sun Apr 23 22:32:18 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 23 Apr 2006 17:32:18 -0500 Subject: [Fwd: Re: Licensing for Lingua::EN::Inflect::Number, Class::DBI::Loader::Relationship] Message-ID: <1145831538.19474.46.camel@localhost.localdomain> Author replies! -------- Forwarded Message -------- From: Simon Cozens To: Tom 'spot' Callaway Subject: Re: Licensing for Lingua::EN::Inflect::Number, Class::DBI::Loader::Relationship Date: Sun, 23 Apr 2006 23:22:33 +0100 Tom 'spot' Callaway: > You seem to be the author for Lingua::EN::Inflect::Number and > Class::DBI::Loader::Relationship. I am the package maintainer for these > perl modules in Fedora Extras, and I need to confirm their licenses. > Are these modules licensed under the same license as perl? (GPL or > Artistic) They are, yes. I'm trying to retire maintainership of my CPAN packages, so I don't particularly want to update these (to reflect the licensing) without finding a new maintainer to take over. Is this confirmation all that you need, or should I be trying to find someone to put license info in the package as well? Simon -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at lsd.di.uminho.pt Sun Apr 23 23:04:26 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 24 Apr 2006 00:04:26 +0100 Subject: Perl modules (license: distributable) - Mail::Sendmail In-Reply-To: <4447A2ED.9030501@lsd.di.uminho.pt> References: <44479B31.7060303@lsd.di.uminho.pt> <44479D1F.7020500@city-fan.org> <4447A2ED.9030501@lsd.di.uminho.pt> Message-ID: <444C07FA.8010300@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jose Pedro Oliveira wrote: > > License: distributable > ---- > perl-Mail-Sendmail - Distributable > ---- The README file of Mail::Sendmail includes the following copyright information: - ------ You can use this module freely. (Someone complained this is too vague. So, more precisely: do whatever you want with it, but be warned that terrible things will happen to you if you use it badly, like for sending spam, or ...?) - ------ Is this copyright acceptable? And does this fall under the Distributable license? jpo References: [1] - http://search.cpan.org/src/MIVKOVIC/Mail-Sendmail-0.79/README [2] - Debian package http://packages.debian.org/changelogs/pool/main/libm/libmail-sendmail-perl/current/copyright - -- 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.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFETAf6l0metZG9hRsRApetAJ4mfeDSrO4+oQW4w94qqBzFz2lrJgCg0kSd JuayCp7tzEb+gaMV4xrx47Q= =2Mp8 -----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 fedora at camperquake.de Tue Apr 25 19:52:55 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Apr 2006 21:52:55 +0200 Subject: Downloading .fedora.cert Message-ID: <20060425215255.487a9da2@nausicaa.camperquake.de> Hi. I don't seem to be able to get a new certificate out of https://admin.fedora.redhat.com/accounts/gen-cert.cgi. All I get is a 0 byte sized file... -- "The only problem with drinking to drown your sorrows is that they very quickly learn to swim." -- Janet McKnight From sopwith at redhat.com Tue Apr 25 21:21:17 2006 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 25 Apr 2006 17:21:17 -0400 (EDT) Subject: Downloading .fedora.cert In-Reply-To: <20060425215255.487a9da2@nausicaa.camperquake.de> References: <20060425215255.487a9da2@nausicaa.camperquake.de> Message-ID: On Tue, 25 Apr 2006, Ralf Ertzinger wrote: > I don't seem to be able to get a new certificate out of > https://admin.fedora.redhat.com/accounts/gen-cert.cgi. All I get is a 0 byte > sized file... Thanks for the heads-up (but next time, let sysadmins know - e-mail admin at fedoraproject.org :) Can you try now and see if it works? -- Elliot From gauret at free.fr Wed Apr 26 13:43:29 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 26 Apr 2006 15:43:29 +0200 Subject: Downloading .fedora.cert In-Reply-To: References: <20060425215255.487a9da2@nausicaa.camperquake.de> Message-ID: <200604261543.30348.gauret@free.fr> Le Mardi 25 Avril 2006 23:21, Elliot Lee a ?crit : > On Tue, 25 Apr 2006, Ralf Ertzinger wrote: > > I don't seem to be able to get a new certificate out of > > https://admin.fedora.redhat.com/accounts/gen-cert.cgi. All I get is a 0 > > byte sized file... > > Thanks for the heads-up (but next time, let sysadmins know - e-mail > admin at fedoraproject.org :) > > Can you try now and see if it works? I have the same problem right now. The .fedora.cert file is 0 byte. Thanks, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Never trust a computer you can't throw out a window." -- Steve Wozniak -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Wed Apr 26 16:44:45 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 26 Apr 2006 18:44:45 +0200 Subject: Downloading .fedora.cert In-Reply-To: <444F9FC6.1060709@elfshadow.net> References: <20060425215255.487a9da2@nausicaa.camperquake.de> <200604261543.30348.gauret@free.fr> <444F9FC6.1060709@elfshadow.net> Message-ID: <200604261844.45377.gauret@free.fr> Le Mercredi 26 Avril 2006 18:28, Jeffrey Tadlock a ?crit : > Aurelien Bompard wrote: > > I have the same problem right now. The .fedora.cert file is 0 byte. > > Please try it again. It should be working now. It does, thanks a lot. Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "When you're new to computers, you think they're magic. Then you learn some stuff and think you understand them. Then you learn more and realize they're basically magic." From katzj at redhat.com Fri Apr 28 18:23:48 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Apr 2006 14:23:48 -0400 Subject: Improving the way we select multilib packages for trees Message-ID: <1146248628.9570.39.camel@aglarond.local> If you're a user on x86_64, you've probably noticed the less than ideal way in which packages are chosen for being shipped in both x86 and x86_64 forms. Originally, the policy was just the LSB set. Then, it was expanded to be "most" libraries based on the contents of a file used at tree compose time. Now, it's time for the next expansion and actually getting to where we ship a 32-bit development environment on x86_64. To do so, we're going to change to using the existence of a -devel package to say that we should be shipping multiple arches of a package. I've just built a new version of RPM containing a patch so that the -devel packages will end up requiring the correct library package[1]. What does this mean to you as a package maintainer? In a lot of cases, hopefully nothing. But there are cases where header files included in packages are generated at build-time and have an architecture or build specific nature. These conflicts will need to be fixed similar to how things have been fixed for runtime library issues -- either moving files around or removing the cause for the difference. If there is a valid reason for them to be different, then you might want to explore having a common stub header that includes the different headers as appropriate (eg, how /usr/include/gnu/stubs.h is handled) You'll need to finish fixing these in time for the Test1 freeze on June 7th so that we can have a sane tree. Also, note that while we're not going down the road of starting to pull x86 packages into the x86_64 trees for Extras yet, there is interest in having this available, so it would be valuable to go ahead and look into potential problems there now as I'd really like to have our multilib package set policy more consistent for Fedora Core 6. Thanks, Jeremy [1] Basically, we resolve the soname of the target of the libfoo.so devel symlink and make that a requires of the package. From petersen at redhat.com Sat Apr 29 06:18:44 2006 From: petersen at redhat.com (Jens Petersen) Date: Sat, 29 Apr 2006 15:18:44 +0900 Subject: [packaging question] multilib gtkimm (Input Method modules) Message-ID: <44530544.2050403@redhat.com> Hi, Is there some way to encourage yum and pirut to always install scim-libs.i386 too on x86_64 when scim-libs.x86_64 gets installed? ie if I do "yum install scim-anthy" or "yum groupinstall japanese-support" on x86_64, I want it to install scim-libs.i386 as well as scim-libs.x86_64 (a dependency of scim-anthy), just as happens when installing with anaconda. The context [1] for this question is users of 32bit apps on x86_64 complaining that IM doesn't work for them and it is not at all obvious that this is due to scim-libs.i386 not being installed. My initial idea for a solution was to add something like: # require 32bit gtk IM module for 64bit multilib arches %ifarch x86_64 s390x Requires: %{_prefix}/lib/gtk-2.0/immodules/im-scim.so %endif to the main scim package, so that installing scim.x86_64 would pull in scim-libs.i386. Is there a better to deal with this? Can something be added to comps.xml to help? Jens [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188398 ps Another side of the problem is that gtk2 doesn't behave very well when asked to use an IM module that is not available: eg if GTK_IM_MODULE is set to "scim", scim-libs.x86_64 is installed, and scim-libs.i386 not installed, then 64bit gtk apps will be fine, but IM will behave quite strangely on 32bit apps. In this case it would be better if gtk tried to fallback to XIM say IMHO (I believe qtimm does this). In this sense relying on /etc/gtk-2.0/*/gtk.immodules would be safer, but we really need a more reliable way than that to choose which immodule is used by default. From jorton at redhat.com Sat Apr 29 10:10:46 2006 From: jorton at redhat.com (Joe Orton) Date: Sat, 29 Apr 2006 11:10:46 +0100 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146248628.9570.39.camel@aglarond.local> References: <1146248628.9570.39.camel@aglarond.local> Message-ID: <20060429101046.GA3880@redhat.com> On Fri, Apr 28, 2006 at 02:23:48PM -0400, Jeremy Katz wrote: > What does this mean to you as a package maintainer? In a lot of cases, > hopefully nothing. But there are cases where header files included in > packages are generated at build-time and have an architecture or build > specific nature. These conflicts will need to be fixed similar to how > things have been fixed for runtime library issues -- either moving files > around or removing the cause for the difference. If there is a valid > reason for them to be different, then you might want to explore having a > common stub header that includes the different headers as appropriate > (eg, how /usr/include/gnu/stubs.h is handled) Nobody has come up with a feasible plan for dealing with %{_bindir}/foo-config scripts AFAIK. joe From tgl at redhat.com Sat Apr 29 19:47:27 2006 From: tgl at redhat.com (Tom Lane) Date: Sat, 29 Apr 2006 15:47:27 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <20060429101046.GA3880@redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> Message-ID: <26282.1146340047@sss.pgh.pa.us> Joe Orton writes: > Nobody has come up with a feasible plan for dealing with > %{_bindir}/foo-config scripts AFAIK. Indeed. I don't have a reasonable solution for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190093 for instance. (The one proposed by Bastien in the bug is not reasonable.) I've always thought that the decision to have only one bin-dir for both arches was a serious mistake. Maybe we could revisit that before we start trying to stretch the entire world upon that Procrustean bed. regards, tom lane