From katzj at redhat.com Mon Feb 21 19:46:15 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Feb 2005 14:46:15 -0500 Subject: testing Message-ID: <1109015175.17200.8.camel@bree.local.net> testing, testing 1 2 3 From katzj at redhat.com Mon Feb 21 19:49:51 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Feb 2005 14:49:51 -0500 Subject: testing read-only Message-ID: <1109015391.17200.10.camel@bree.local.net> testing mail to readonly From katzj at redhat.com Mon Feb 21 19:59:32 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Feb 2005 14:59:32 -0500 Subject: readonly test, take 2 Message-ID: <1109015972.17200.14.camel@bree.local.net> From katzj at redhat.com Mon Feb 21 20:01:14 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Feb 2005 15:01:14 -0500 Subject: readonly test 3 Message-ID: <1109016075.17200.16.camel@bree.local.net> From notting at redhat.com Wed Feb 23 02:24:26 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Feb 2005 21:24:26 -0500 Subject: gimp-print-cups Message-ID: <20050223022426.GA28271@nostromo.devel.redhat.com> Remind me again - what uses gimp-print-cups? Bill From jkeating at j2solutions.net Wed Feb 23 08:51:29 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 23 Feb 2005 00:51:29 -0800 Subject: gimp-print-cups In-Reply-To: <20050223022426.GA28271@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> Message-ID: <1109148690.3258.1.camel@localhost.localdomain> On Tue, 2005-02-22 at 21:24 -0500, Bill Nottingham wrote: > Remind me again - what uses gimp-print-cups? Is this the equal to 'kprinter' in the kde world? Pops up a dialog box from which you can choose the printer to use, the options for the printer, such as duplex or whatnot, number of copies and all that fun stuff? I used kprinter a lot from mozilla, as moz's print system was subpar. I still use it from xpdf or acroread. If that is the case, this is something I wouldn't mind seeing in extras. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 twaugh at redhat.com Wed Feb 23 09:13:15 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 23 Feb 2005 09:13:15 +0000 Subject: gimp-print-cups In-Reply-To: <1109148690.3258.1.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <1109148690.3258.1.camel@localhost.localdomain> Message-ID: <20050223091315.GL23106@redhat.com> On Wed, Feb 23, 2005 at 12:51:29AM -0800, Jesse Keating wrote: > Is this the equal to 'kprinter' in the kde world? No, it's just a load of PPD files. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Wed Feb 23 09:08:30 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 23 Feb 2005 09:08:30 +0000 Subject: gimp-print-cups In-Reply-To: <20050223022426.GA28271@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> Message-ID: <20050223090830.GJ23106@redhat.com> On Tue, Feb 22, 2005 at 09:24:27PM -0500, Bill Nottingham wrote: > Remind me again - what uses gimp-print-cups? People who don't want to use system-config-printer. I think it's probably okay to remove the package from the CD. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Feb 23 18:49:34 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 13:49:34 -0500 Subject: gimp-print-cups In-Reply-To: <20050223090830.GJ23106@redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> Message-ID: <20050223184934.GA4260@nostromo.devel.redhat.com> Tim Waugh (twaugh at redhat.com) said: > On Tue, Feb 22, 2005 at 09:24:27PM -0500, Bill Nottingham wrote: > > > Remind me again - what uses gimp-print-cups? > > People who don't want to use system-config-printer. I think it's > probably okay to remove the package from the CD. Yeah, I'd go ahead and do it. Woo, 25MB! :) Bill From tcallawa at redhat.com Wed Feb 23 18:57:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 12:57:13 -0600 Subject: gimp-print-cups In-Reply-To: <20050223184934.GA4260@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> Message-ID: <1109185033.13305.97.camel@localhost.localdomain> On Wed, 2005-02-23 at 13:49 -0500, Bill Nottingham wrote: >Tim Waugh (twaugh at redhat.com) said: >> On Tue, Feb 22, 2005 at 09:24:27PM -0500, Bill Nottingham wrote: >> >> > Remind me again - what uses gimp-print-cups? >> >> People who don't want to use system-config-printer. I think it's >> probably okay to remove the package from the CD. > >Yeah, I'd go ahead and do it. Woo, 25MB! :) Tim, are you going to maintain this in Fedora Extras? Anything we drop from FC4 should go into Extras, unless its unmaintained upstream or a license change has happened. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at princeton.edu Wed Feb 23 19:11:14 2005 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 23 Feb 2005 14:11:14 -0500 Subject: gimp-print-cups In-Reply-To: <1109185033.13305.97.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> Message-ID: <1109185873.15872.5.camel@spatula.pppl.gov> On Wed, 2005-02-23 at 13:57, Tom 'spot' Callaway wrote: > Tim, are you going to maintain this in Fedora Extras? Anything we drop > from FC4 should go into Extras, unless its unmaintained upstream or a > license change has happened. since this is a subpackage of gimp-print.. thats tougher. You'd have to split this off as a new srpm. Current infrastructure constraints dictate Extras/Core must be split at srpm level. So any subpackage that is dropped has to be re-engineered as its own srpm to show up in Extras. Somehow I don't get the feeling Red Hat is prepared to expend the resources to re-engineer subpackages as new packages as general rule when there is pressure to prune subpackages. The subpackage barrier is somewhat problematic in this regard. -jef From notting at redhat.com Wed Feb 23 19:13:39 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 14:13:39 -0500 Subject: gimp-print-cups In-Reply-To: <1109185033.13305.97.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> Message-ID: <20050223191339.GB4490@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > >> > Remind me again - what uses gimp-print-cups? > >> > >> People who don't want to use system-config-printer. I think it's > >> probably okay to remove the package from the CD. > > > >Yeah, I'd go ahead and do it. Woo, 25MB! :) > > Tim, are you going to maintain this in Fedora Extras? Anything we drop > from FC4 should go into Extras, unless its unmaintained upstream or a > license change has happened. (Note that this is a subpackage, FWIW.) I disagree. Whether or not a package removed from Core should be in Extras depends on many things, including: how useful it was to begin with, whether or not there's any interest from the community and maintaining it, what the burden of maintaining it in Fedora is, etc. There's no reason to demand that something like xloadimage or comsat be in Extras if no one cares about it, and whether or not will happen I don't feel is a determining factor on the package's status for remaining in Core. Bill From gdk at redhat.com Wed Feb 23 19:24:34 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 23 Feb 2005 14:24:34 -0500 (EST) Subject: gimp-print-cups In-Reply-To: <20050223191339.GB4490@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> Message-ID: Perhaps the right thing to do in this kind of case is to: 1. Move the package into extras. If no owner *immediately* steps forward, tag it as "unmaintained". Unmaintained modules sit in CVS but never get built. 2. Come up with a mechanism for notifying folks about the unmaintained modules. 3. If a module is unmaintained for a certain period of time, we may choose to dump it from CVS. Or not. That way, something like xloadimage gets archived until that time if/when someone chooses to pick it back up. Just thinkin'. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Wed, 23 Feb 2005, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > >> > Remind me again - what uses gimp-print-cups? > > >> > > >> People who don't want to use system-config-printer. I think it's > > >> probably okay to remove the package from the CD. > > > > > >Yeah, I'd go ahead and do it. Woo, 25MB! :) > > > > Tim, are you going to maintain this in Fedora Extras? Anything we drop > > from FC4 should go into Extras, unless its unmaintained upstream or a > > license change has happened. > > (Note that this is a subpackage, FWIW.) > > I disagree. Whether or not a package removed from Core should be > in Extras depends on many things, including: how useful it was to > begin with, whether or not there's any interest from the community > and maintaining it, what the burden of maintaining it in Fedora > is, etc. > > There's no reason to demand that something like xloadimage or comsat > be in Extras if no one cares about it, and whether or not will > happen I don't feel is a determining factor on the package's status > for remaining in Core. > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jkeating at j2solutions.net Wed Feb 23 19:35:00 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 23 Feb 2005 11:35:00 -0800 Subject: gimp-print-cups In-Reply-To: References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> Message-ID: <1109187300.26202.8.camel@jkeating2.hq.pogolinux.com> On Wed, 2005-02-23 at 14:24 -0500, Greg DeKoenigsberg wrote: > > Perhaps the right thing to do in this kind of case is to: > > 1. Move the package into extras. If no owner *immediately* steps > forward, > tag it as "unmaintained". Unmaintained modules sit in CVS but never > get > built. > > 2. Come up with a mechanism for notifying folks about the > unmaintained > modules. > > 3. If a module is unmaintained for a certain period of time, we may > choose > to dump it from CVS. Or not. > > That way, something like xloadimage gets archived until that time > if/when > someone chooses to pick it back up. > > Just thinkin'. > > Seems a bit overkill. Why not just a mail to fedora-list or something asking "If we drop this, will anybody pick it up for Extras?" If nobody answers in a day or so, bombs away. If somebody does speak up, hand them the CVS module. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From dwmw2 at infradead.org Wed Feb 23 19:38:59 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 19:38:59 +0000 Subject: gimp-print-cups In-Reply-To: <1109185873.15872.5.camel@spatula.pppl.gov> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <1109185873.15872.5.camel@spatula.pppl.gov> Message-ID: <1109187539.5420.19.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 14:11 -0500, Jef Spaleta wrote: > since this is a subpackage of gimp-print.. thats tougher. You'd have to > split this off as a new srpm. Current infrastructure constraints dictate > Extras/Core must be split at srpm level. So any subpackage that is > dropped has to be re-engineered as its own srpm to show up in Extras. > Somehow I don't get the feeling Red Hat is prepared to expend the > resources to re-engineer subpackages as new packages as general rule > when there is pressure to prune subpackages. The subpackage barrier is > somewhat problematic in this regard. In general it's hard, yes -- but I've done precisely that for the exim- doc package already. In fact the exim-doc subpackage probably shouldn't have been a subpackage of exim in the first place, because it has its own source tarballs which are updated out of sync with the program itself, and the docs go entirely into their own package. So we now have an exim-doc package which I can't build in dist-fc4, because even though it replaces an existing 'exim-doc' package in FC4, the _source_ package 'exim-doc' isn't listed. Are we going to put that back in dist-fc4 as before, or move it to Extras? I'm happy with either, but I'd like a decision. My preference would be just to put it back into dist-fc4 where it was yesterday -- because it was in FC3, and because I think it's silly for us to be busting a gut to drop just one FC4 architecture down to 4 CDs from 5, when anaconda in FC5 will make it so much easier to do this _properly_. -- dwmw2 From jspaleta at princeton.edu Wed Feb 23 20:00:53 2005 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 23 Feb 2005 15:00:53 -0500 Subject: gimp-print-cups In-Reply-To: <1109187300.26202.8.camel@jkeating2.hq.pogolinux.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109187300.26202.8.camel@jkeating2.hq.pogolinux.com> Message-ID: <1109188852.15872.30.camel@spatula.pppl.gov> On Wed, 2005-02-23 at 14:35, Jesse Keating wrote: > Seems a bit overkill. Why not just a mail to fedora-list or something Lists are a blackhole. There could very well be a case of someone in the userbase who is willing to maintain a package but doesn't track rawhide nor the high noise lists (at the moment the package is dropped from Core)... but will notice as soon as they install the next release and the package is not there. It's much easier to keep a centralized list of orphaned packages through the test period and release transition to point people as complains roll in than to search and reference multiple list posts. Keep a list of orphans long enough to make sure everyone who didn't notice till they installed the new core release has a chance to see the list and volunteer... wipe the list clean before the next test phase of core begins. How to handle dropping stuff from a rolling extras is a bit tougher with appropriate notice. -jef From gdk at redhat.com Wed Feb 23 20:10:36 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 23 Feb 2005 15:10:36 -0500 (EST) Subject: gimp-print-cups In-Reply-To: <1109188852.15872.30.camel@spatula.pppl.gov> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109187300.26202.8.camel@jkeating2.hq.pogolinux.com> <1109188852.15872.30.camel@spatula.pppl.gov> Message-ID: On Wed, 23 Feb 2005, Jef Spaleta wrote: > On Wed, 2005-02-23 at 14:35, Jesse Keating wrote: > > Seems a bit overkill. Why not just a mail to fedora-list or something > > Lists are a blackhole... Exactly. We make this mistake repeatedly. Information that should be PERSISTENT and ORGANIZED ("this is stuff we need to take care of") is, instead, TRANSITORY and DISORGANIZED ("which mailing list archive should I be combing through again?") /me goes to put this on the list of TODOs -- list of orphaned/abandoned packages. I asked mschwendt if he'd be willing to tackle policy on this, but no word yet. :-) --g > ... There could very well be a case of someone in the userbase who is > willing to maintain a package but doesn't track rawhide nor the high > noise lists (at the moment the package is dropped from Core)... but will > notice as soon as they install the next release and the package is not > there. It's much easier to keep a centralized list of orphaned packages > through the test period and release transition to point people as > complains roll in than to search and reference multiple list posts. > > Keep a list of orphans long enough to make sure everyone who didn't > notice till they installed the new core release has a chance to see the > list and volunteer... wipe the list clean before the next test phase of > core begins. > > How to handle dropping stuff from a rolling extras is a bit tougher with > appropriate notice. > > -jef _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From tcallawa at redhat.com Wed Feb 23 20:10:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 14:10:51 -0600 Subject: gimp-print-cups In-Reply-To: <20050223191339.GB4490@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> Message-ID: <1109189451.13305.102.camel@localhost.localdomain> On Wed, 2005-02-23 at 14:13 -0500, Bill Nottingham wrote: >I disagree. Whether or not a package removed from Core should be >in Extras depends on many things, including: how useful it was to >begin with, whether or not there's any interest from the community >and maintaining it, what the burden of maintaining it in Fedora >is, etc. Fair enough, but it should go on an orphaned list if the Core maintainer doesn't feel that it has value in Extras, so that someone else can take it if they want to. In this case, this is a lot of support for printers, which may or may not work as well with the default configurations. I really don't think we want to regress on someone who relies on gimp-print-cups to have useful printing functionality. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Wed Feb 23 20:38:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 23 Feb 2005 21:38:50 +0100 Subject: orphans (was: gimp-print-cups) In-Reply-To: References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109187300.26202.8.camel@jkeating2.hq.pogolinux.com> <1109188852.15872.30.camel@spatula.pppl.gov> Message-ID: <20050223213850.142c8f59.bugs.michael@gmx.net> On Wed, 23 Feb 2005 15:10:36 -0500 (EST), Greg DeKoenigsberg wrote: > > On Wed, 23 Feb 2005, Jef Spaleta wrote: > > > On Wed, 2005-02-23 at 14:35, Jesse Keating wrote: > > > Seems a bit overkill. Why not just a mail to fedora-list or something > > > > Lists are a blackhole... > > Exactly. We make this mistake repeatedly. Information that should be > PERSISTENT and ORGANIZED ("this is stuff we need to take care of") is, > instead, TRANSITORY and DISORGANIZED ("which mailing list archive should I > be combing through again?") > > /me goes to put this on the list of TODOs -- list of orphaned/abandoned > packages. I asked mschwendt if he'd be willing to tackle policy on this, > but no word yet. :-) The list itself is not the problem. We do have such a list already in the Wiki, albeit mostly free-form for now. Questions to answer will be, for instance: Where to report a potentially unmaintained package? Usually, a random user requests an upgrade in bugzilla. Sometimes this is due to impatience, sometimes the included package is really out-of-date. Who notices when a package owner doesn't seem to reply to bug reports or upgrade requests? Create a separate issue tracker? Use bugzilla? Use a special contact address? Use a well-defined protocol with how to probe whether a primary package owner cannot be reached anymore: Mail, wait for reply for XX days, announce package ownership change publicly, Cc old owner, wait X days, then make permanent? How long to wait before deleting binaries from a repository? (software getting out-of-date compared with upstream releases, risk of undiscovered security vulnerabilities, critical incompatibilities upon distribution version upgrade) What to do with packages in fedora.us? When to declare the old Extras for RHL9/FC1 as "unsupported" (end-of-life)? What to do when package owner no longer can test updates on an old distribution version? Revise the "pending" step and publish builds without verification (we do this in FC3 Extras, too!)? If an extra package for an old (or legacy) distribution is no longer being maintained actively, do we pull it (because of risk of security vulnerabilities) or only declare it unmaintained/orphaned? Or do we published untested builds (which are only assumed to work because they build) in a separate "testing" repository and community QA contributors can vote on promoting updates into the main repository? From notting at redhat.com Wed Feb 23 20:55:44 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 15:55:44 -0500 Subject: gimp-print-cups In-Reply-To: <1109189451.13305.102.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109189451.13305.102.camel@localhost.localdomain> Message-ID: <20050223205544.GC4978@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > In this case, this is a lot of support for printers, which may or may > not work as well with the default configurations. I really don't think > we want to regress on someone who relies on gimp-print-cups to have > useful printing functionality. It adds no support for any printers that are not already supported; it is merely an alternate form of the support we already ship. Bill From tcallawa at redhat.com Wed Feb 23 20:58:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 14:58:29 -0600 Subject: gimp-print-cups In-Reply-To: <20050223205544.GC4978@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109189451.13305.102.camel@localhost.localdomain> <20050223205544.GC4978@nostromo.devel.redhat.com> Message-ID: <1109192309.13305.120.camel@localhost.localdomain> On Wed, 2005-02-23 at 15:55 -0500, Bill Nottingham wrote: >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> In this case, this is a lot of support for printers, which may or may >> not work as well with the default configurations. I really don't think >> we want to regress on someone who relies on gimp-print-cups to have >> useful printing functionality. > >It adds no support for any printers that are not already supported; >it is merely an alternate form of the support we already ship. I'm just trying to avoid the "You broke my printer" flames. It could very well be the case that the gimp-print-cups drivers are superior (or inferior) to the alternate drivers in Core, and if so, we may be regressing for some printers. I hate printers, so I can't confirm this one way or the other. I'm just trying to make sure we're not being arrogant in trashing things that may be useful to people trying to print. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From notting at redhat.com Wed Feb 23 21:12:48 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 16:12:48 -0500 Subject: gimp-print-cups In-Reply-To: <1109192309.13305.120.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109189451.13305.102.camel@localhost.localdomain> <20050223205544.GC4978@nostromo.devel.redhat.com> <1109192309.13305.120.camel@localhost.localdomain> Message-ID: <20050223211248.GD4978@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > I'm just trying to avoid the "You broke my printer" flames. > > It could very well be the case that the gimp-print-cups drivers are > superior (or inferior) to the alternate drivers in Core, and if so, we > may be regressing for some printers. Perhaps I'm not being clear. They're the *exact same drivers* as the other Core drivers; it's just PPDs used for manual setup as opposed to using the print tool. (Tim, please correct me if I'm mistaken.) Bill From tcallawa at redhat.com Wed Feb 23 21:36:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 15:36:13 -0600 Subject: gimp-print-cups In-Reply-To: <20050223211248.GD4978@nostromo.devel.redhat.com> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109189451.13305.102.camel@localhost.localdomain> <20050223205544.GC4978@nostromo.devel.redhat.com> <1109192309.13305.120.camel@localhost.localdomain> <20050223211248.GD4978@nostromo.devel.redhat.com> Message-ID: <1109194573.13305.125.camel@localhost.localdomain> On Wed, 2005-02-23 at 16:12 -0500, Bill Nottingham wrote: >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> I'm just trying to avoid the "You broke my printer" flames. >> >> It could very well be the case that the gimp-print-cups drivers are >> superior (or inferior) to the alternate drivers in Core, and if so, we >> may be regressing for some printers. > >Perhaps I'm not being clear. They're the *exact same drivers* as the >other Core drivers; it's just PPDs used for manual setup as opposed >to using the print tool. (Tim, please correct me if I'm mistaken.) If they're exactly the same, then I suppose the need for including them in Extras isn't urgent. I think it should still go on the orphaned list. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From gemi at bluewin.ch Wed Feb 23 21:58:41 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 23 Feb 2005 22:58:41 +0100 Subject: gimp-print-cups In-Reply-To: <1109194573.13305.125.camel@localhost.localdomain> References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> <1109189451.13305.102.camel@localhost.localdomain> <20050223205544.GC4978@nostromo.devel.redhat.com> <1109192309.13305.120.camel@localhost.localdomain> <20050223211248.GD4978@nostromo.devel.redhat.com> <1109194573.13305.125.camel@localhost.localdomain> Message-ID: <1109195921.3603.1.camel@scriabin.tannenrauch.ch> On Wed, 2005-02-23 at 15:36 -0600, Tom 'spot' Callaway wrote: > On Wed, 2005-02-23 at 16:12 -0500, Bill Nottingham wrote: > >Tom 'spot' Callaway (tcallawa at redhat.com) said: > >> I'm just trying to avoid the "You broke my printer" flames. > >> > >> It could very well be the case that the gimp-print-cups drivers are > >> superior (or inferior) to the alternate drivers in Core, and if so, we > >> may be regressing for some printers. > > > >Perhaps I'm not being clear. They're the *exact same drivers* as the > >other Core drivers; it's just PPDs used for manual setup as opposed > >to using the print tool. (Tim, please correct me if I'm mistaken.) When are these gimp-print-cups drivers actually accessed. When using localhost:631 to configure printers? I always had some difficulties in understanding how all this cups stuff hangs together. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From mharris at redhat.com Wed Feb 23 23:20:22 2005 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 23 Feb 2005 18:20:22 -0500 (EST) Subject: gimp-print-cups In-Reply-To: References: <20050223022426.GA28271@nostromo.devel.redhat.com> <20050223090830.GJ23106@redhat.com> <20050223184934.GA4260@nostromo.devel.redhat.com> <1109185033.13305.97.camel@localhost.localdomain> <20050223191339.GB4490@nostromo.devel.redhat.com> Message-ID: On Wed, 23 Feb 2005, Greg DeKoenigsberg wrote: >Date: Wed, 23 Feb 2005 14:24:34 -0500 (EST) >From: Greg DeKoenigsberg >To: List for Fedora Package Maintainers >Content-Type: TEXT/PLAIN; charset=US-ASCII >Reply-To: List for Fedora Package Maintainers > >X-BeenThere: fedora-maintainers at redhat.com >Subject: Re: gimp-print-cups > > >Perhaps the right thing to do in this kind of case is to: > >1. Move the package into extras. If no owner *immediately* steps forward, >tag it as "unmaintained". Unmaintained modules sit in CVS but never get >built. > >2. Come up with a mechanism for notifying folks about the unmaintained >modules. > >3. If a module is unmaintained for a certain period of time, we may choose >to dump it from CVS. Or not. > >That way, something like xloadimage gets archived until that time if/when >someone chooses to pick it back up. > >Just thinkin'. I agree completely with this approach, and think it is a nice organized way to tackle things. The only change I would make, would be to get you to reply underneath postings instead of on top, but that's just a technical detail. ;o) TTYL /me runs -- Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd. IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor From dwmw2 at infradead.org Thu Feb 24 08:21:08 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 08:21:08 +0000 Subject: Summary of Dropped Packages In-Reply-To: <1109233259.10915.70.camel@cutter> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> Message-ID: <1109233269.4631.12.camel@localhost.localdomain> On Thu, 2005-02-24 at 03:20 -0500, seth vidal wrote: >I'm thinking for the future - why don't we consider pulling this >discussion off of fedora-devel and onto fedora-maintainers? Sound >reasonable? Yeah. I suspect this is just an script error because the exim-doc subpackage is gone. That comes from its own SRPM now, which can easily be moved to Extras or just dropped. Exim itself needs to stay, and removing it wasn't under consideration AFAICT. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 09:11:33 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 10:11:33 +0100 Subject: Summary of Dropped Packages In-Reply-To: <1109233269.4631.12.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> Message-ID: <20050224101133.4341fbd6@python2> David Woodhouse wrote : > On Thu, 2005-02-24 at 03:20 -0500, seth vidal wrote: > >I'm thinking for the future - why don't we consider pulling this > >discussion off of fedora-devel and onto fedora-maintainers? Sound > >reasonable? > > I suspect this is just an script error because the exim-doc subpackage > is gone. That comes from its own SRPM now, which can easily be moved to > Extras or just dropped. Exim itself needs to stay, and removing it > wasn't under consideration AFAICT. I'm also a bit disappointed to see xfce dropped... FC is now short of a powerful but light desktop manager and still has two huge heavyweight ones. I saw bzflag and tuxracer got removed too, which means that there is not a single nifty 3D game left to show off hardware acceleration right after install. Well, there's the sproingies screensaver, but the interaction is quite limited ;-) I'd love to see at least one 3D game left in. My personal preference would go for neverball and neverputt... but they're even bigger than tuxracer and bzflag, so I doubt that'll happen. I do volunteer to take back bzflag for maintainership in Extras. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 1.45 1.52 1.45 From dwmw2 at infradead.org Thu Feb 24 09:41:02 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 09:41:02 +0000 Subject: Summary of Dropped Packages In-Reply-To: <20050224101133.4341fbd6@python2> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> Message-ID: <1109238062.4631.38.camel@localhost.localdomain> On Thu, 2005-02-24 at 10:11 +0100, Matthias Saou wrote: >I'm also a bit disappointed to see xfce dropped... FC is now short of a >powerful but light desktop manager and still has two huge heavyweight >ones. Yeah. I think this whole last-minute attempt to cut down just one of the supported architectures to 4 CDs is misguided. We can do this properly in FC5 when anaconda can support multiple repositories. Why are we bothering with it now? And if we're going to start ditching random stuff to make space, can't we at least try to keep the damage limited to the one arch we seem to be doing this for? We could gain about 25M by dropping the Xen kernels, for example. Those weren't in FC3. Making kernel-devel packages share the base files from a core package but just include their own build-specific headers and asm-offsets.h would get rid of another 8M or so, too. More than that if we still have the Xen kernel-devel packages in the tree. And would have the added benefit of not requiring us to run hardlink in %post. -- dwmw2 From jakub at redhat.com Thu Feb 24 09:47:49 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 24 Feb 2005 04:47:49 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109238062.4631.38.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> Message-ID: <20050224094748.GA853@devserv.devel.redhat.com> On Thu, Feb 24, 2005 at 09:41:02AM +0000, David Woodhouse wrote: > Making kernel-devel packages share the base files from a core package > but just include their own build-specific headers and asm-offsets.h > would get rid of another 8M or so, too. More than that if we still have Alternatively there can be just one kernel-devel that provides all 4 and is hardlinked within the package. > the Xen kernel-devel packages in the tree. And would have the added > benefit of not requiring us to run hardlink in %post. Hardlink in %post is so that files can be shared accross different kernels, so would be still desirable. But perhaps something could be speeded up by not using a general hardlinking proglet, but instead a specialized one (in kernel*devel* one would expect mainly just files with the same relative name under the kernel specific subdir to be identical, so a specialized proglet can check just those; furthermore, it can only compare the newly added kernel with the current ones, doesn't have to compare the already installed kernel-devel's against each other). Jakub From dwmw2 at infradead.org Thu Feb 24 09:56:27 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 09:56:27 +0000 Subject: Summary of Dropped Packages In-Reply-To: <20050224094748.GA853@devserv.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> <20050224094748.GA853@devserv.devel.redhat.com> Message-ID: <1109238987.4631.42.camel@localhost.localdomain> On Thu, 2005-02-24 at 04:47 -0500, Jakub Jelinek wrote: >Alternatively there can be just one kernel-devel that provides all 4 >and is hardlinked within the package. That's actually attractive to me for other reasons -- for kernel-module packages we currently have no way of knowing which variants exist (smp,hugemem,xen0,xenU,etc.). If they were all present in the kernel-devel package that wouldn't be a problem. Also, it's impossible to install i586 and i686 kernel-devel packages side by side. I did my testing on ppc by installing ppc and ppc64 kernel-devel packages together, but that's a special case. Again, putting them all in one fixes this. -- dwmw2 From dwmw2 at infradead.org Thu Feb 24 12:44:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 12:44:22 +0000 Subject: Summary of Dropped Packages In-Reply-To: <1109231991.4631.7.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> Message-ID: <1109249063.5420.29.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 07:59 +0000, David Woodhouse wrote: > On Wed, 2005-02-23 at 23:37 -0500, Bill Nottingham wrote: > >> Packages removed from Fedora Core 4 development tree on 2005-02-23 > >> ... > >> exim > > Er, do you mean exim-doc, which was split into a separate package? Exim > itself is fairly tiny and is a potential candidate for being the default > MTA. There was no discussion of removing Exim entirely, and it was > shipped in FC3. Looking at this morning's rawhide compose... no, it really looks like all 1721 KiB of Exim is missing. That seems a little over the top -- can we put it back please? -- dwmw2 From hp at redhat.com Thu Feb 24 13:20:44 2005 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Feb 2005 08:20:44 -0500 Subject: Summary of Dropped Packages In-Reply-To: <20050224101133.4341fbd6@python2> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> Message-ID: <1109251244.8440.26.camel@localhost.localdomain> On Thu, 2005-02-24 at 10:11 +0100, Matthias Saou wrote: > I'd love to see at least one 3D game left in. My personal preference would > go for neverball and neverputt... but they're even bigger than tuxracer and > bzflag, so I doubt that'll happen. We wanted one or two of these in the default install, I don't remember which ones, anyhow so the ones in the default install should remain. Havoc From ville.skytta at iki.fi Thu Feb 24 16:31:21 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 18:31:21 +0200 Subject: Summary of Dropped Packages In-Reply-To: <1109238987.4631.42.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> <20050224094748.GA853@devserv.devel.redhat.com> <1109238987.4631.42.camel@localhost.localdomain> Message-ID: <1109262681.6386.370.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 09:56 +0000, David Woodhouse wrote: > On Thu, 2005-02-24 at 04:47 -0500, Jakub Jelinek wrote: > >Alternatively there can be just one kernel-devel that provides all 4 > >and is hardlinked within the package. > > That's actually attractive to me for other reasons -- for kernel-module > packages we currently have no way of knowing which variants exist > (smp,hugemem,xen0,xenU,etc.). If they were all present in the > kernel-devel package that wouldn't be a problem. > > Also, it's impossible to install i586 and i686 kernel-devel packages > side by side. I did my testing on ppc by installing ppc and ppc64 > kernel-devel packages together, but that's a special case. Again, > putting them all in one fixes this. This has already been done a long time ago in the fedora.us kernel-module-devel package. It's not hardlinked, but symlinked, though. http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/kernel-module-devel/ http://cachalot.mine.nu/3/RPMS.extras/kernel-module-devel-2.6.10-1.766_FC3-0.6-0.fdr.1.i386.rpm http://cachalot.mine.nu/3/SRPMS.extras/kernel-module-devel-2.6.10-1.766_FC3-0.6-0.fdr.1.src.rpm From jgarzik at redhat.com Thu Feb 24 18:55:16 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Thu, 24 Feb 2005 13:55:16 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109251244.8440.26.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109251244.8440.26.camel@localhost.localdomain> Message-ID: <20050224185516.GA2983@devserv.devel.redhat.com> Let me propose a wild suggestion: Increase to 5 CDs rather than dropping packages others have expressed should stay (xfce, exim). Revisist in FC5, when we can do multiple repositories. Jeff From notting at redhat.com Thu Feb 24 19:59:02 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 14:59:02 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109238062.4631.38.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> Message-ID: <20050224195901.GD11644@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > And if we're going to start ditching random stuff to make space, It's not random; it's following fairly simple guidelines: - removal of duplicate functionality - removal of functionality that (arguably) doesn't fit the normal Core usage cases - games Bill From dwmw2 at infradead.org Fri Feb 25 13:28:16 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 13:28:16 +0000 Subject: Summary of Dropped Packages In-Reply-To: <20050224195901.GD11644@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> <20050224195901.GD11644@nostromo.devel.redhat.com> Message-ID: <1109338096.26364.145.camel@localhost.localdomain> On Thu, 2005-02-24 at 14:59 -0500, Bill Nottingham wrote: > >It's not random; it's following fairly simple guidelines: > >- removal of duplicate functionality >- removal of functionality that (arguably) doesn't fit the normal > Core usage cases >- games Non-random would have seen Postfix dropped too, under the same criteria. Not that I'm suggesting that would be a good thing to do at this point either; mind you. I don't use Postfix myself but it's in FC3 and people are using it so we can't drop it. It's not about favourite-MTA advocacy -- it wasn't me who added Exim to Fedora (or RHEL) and I don't own the package there. Neither was it me who first suggested making it the default IIRC, although I'm inclined to agree. If it had never been added to Fedora, that would have been fine by me -- but dropping packages which were in FC3 is broken, especially as we _know_ we can make a far better job of trimming Core down to size when Extras works nicely in FC5. I'm not suggesting that we shouldn't _ever_ move Exim and Postfix to Extras -- I'm suggesting that we shouldn't do it _now_ in such an uncontrolled fashion; instead we should do it in FC5 when the upgrade will be able to cope. The same goes for XFCE as far as I can tell -- we're cutting off a large set of machines which will no longer be able to run Fedora graphically. Avoiding bloat is a sane enough goal -- but the 4 CD target seems somewhat over the top. Three reasons were given for it IIRC: - 25% increase in media costs for those making CDs. In _media_ costs alone maybe. In fact you could phrase it differently -- you could call it a 100% increase in "5th CD media cost". Or you could perhaps quote a percentage of the _total_ costs of such operators -- about 1% maybe? CDs are dirt cheap, and I suspect that the media cost really isn't a large proportion of the total. - Mirror sites might drop Fedora if it grows The only mirror admin who I've seen respond has basically said "bring it on". Are there examples of those who've said otherwise? 300M on a mirror site doesn't seem like much. This sounds dubious to me. - Users will drop Fedora if it grows This one is the most spurious of all -- I suspect you'll see more users dropping Fedora if we lose XFCE than you'd lose just because they have to download an extra half-CD worth of packages for FC4. We can fix this properly in FC5, and make Extras a first-class citizen; Extras really isn't ready yet for us to be using it as an excuse or mechanism for dumping packages from Core. -- dwmw2 From aoliva at redhat.com Fri Feb 25 20:03:40 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Feb 2005 17:03:40 -0300 Subject: Summary of Dropped Packages In-Reply-To: <1109338096.26364.145.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> <1109233269.4631.12.camel@localhost.localdomain> <20050224101133.4341fbd6@python2> <1109238062.4631.38.camel@localhost.localdomain> <20050224195901.GD11644@nostromo.devel.redhat.com> <1109338096.26364.145.camel@localhost.localdomain> Message-ID: In general, I tend to not voice my opinion when someone else has already done so, but... On Feb 25, 2005, David Woodhouse wrote: > We can fix this properly in FC5, and make Extras a first-class citizen; > Extras really isn't ready yet for us to be using it as an excuse or > mechanism for dumping packages from Core. +3 -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sopwith at redhat.com Fri Feb 25 21:34:44 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 25 Feb 2005 16:34:44 -0500 (EST) Subject: Fedora Extras heads-up - CVS is branching Message-ID: Hey there hackers! In order to allow Extras development to proceed full-speed, all the Fedora Extras module will have an FC-3 branch very shortly. The main thing to keep in mind is that the 'devel' branch is now targetting FC4, while the new 'FC-3' branch will be Fedora Extras for FC3. Again, when committing, put FC3 stuff on the FC-3 branch, and FC4+ stuff on the devel branch. Questions welcome as always. Best, -- Elliot From skvidal at phy.duke.edu Fri Feb 25 21:41:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:41:28 -0500 Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: References: Message-ID: <1109367688.23111.47.camel@cutter> On Fri, 2005-02-25 at 16:34 -0500, Elliot Lee wrote: >Hey there hackers! > >In order to allow Extras development to proceed full-speed, all the Fedora >Extras module will have an FC-3 branch very shortly. > >The main thing to keep in mind is that the 'devel' branch is now >targetting FC4, while the new 'FC-3' branch will be Fedora Extras for FC3. > >Again, when committing, put FC3 stuff on the FC-3 branch, and FC4+ stuff >on the devel branch. > >Questions welcome as always. > When fc4 final comes out will we make a branch then from devel->FC-4? can we do it at the same time as final freeze for FC4? -sv From bugs.michael at gmx.net Fri Feb 25 21:46:54 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 25 Feb 2005 22:46:54 +0100 Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: References: Message-ID: <20050225224654.2ad9eacb.bugs.michael@gmx.net> On Fri, 25 Feb 2005 16:34:44 -0500 (EST), Elliot Lee wrote: > Hey there hackers! > > In order to allow Extras development to proceed full-speed, all the Fedora > Extras module will have an FC-3 branch very shortly. > > The main thing to keep in mind is that the 'devel' branch is now > targetting FC4, while the new 'FC-3' branch will be Fedora Extras for FC3. > > Again, when committing, put FC3 stuff on the FC-3 branch, and FC4+ stuff > on the devel branch. > > Questions welcome as always. Who will increase the release versions for a build for FC4 test1? From skvidal at phy.duke.edu Fri Feb 25 21:52:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:52:03 -0500 Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: <20050225224654.2ad9eacb.bugs.michael@gmx.net> References: <20050225224654.2ad9eacb.bugs.michael@gmx.net> Message-ID: <1109368324.23111.58.camel@cutter> On Fri, 2005-02-25 at 22:46 +0100, Michael Schwendt wrote: >On Fri, 25 Feb 2005 16:34:44 -0500 (EST), Elliot Lee wrote: > >> Hey there hackers! >> >> In order to allow Extras development to proceed full-speed, all the Fedora >> Extras module will have an FC-3 branch very shortly. >> >> The main thing to keep in mind is that the 'devel' branch is now >> targetting FC4, while the new 'FC-3' branch will be Fedora Extras for FC3. >> >> Again, when committing, put FC3 stuff on the FC-3 branch, and FC4+ stuff >> on the devel branch. >> >> Questions welcome as always. > >Who will increase the release versions for a build for FC4 test1? > Can you do it for your packages? -sv From skvidal at phy.duke.edu Fri Feb 25 22:01:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 17:01:07 -0500 Subject: bump release script Message-ID: <1109368867.23111.65.camel@cutter> This fine script, provided by our very own Elliot Lee might help with package release number iterating. as he said "it could use a cleanup". -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: bumpspecfile.py Type: application/x-python Size: 2277 bytes Desc: not available URL: From skvidal at phy.duke.edu Fri Feb 25 22:09:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 17:09:46 -0500 Subject: slight clean up to the bump spec script Message-ID: <1109369386.23111.68.camel@cutter> Hi folks see attached. first arg is your name string rest of args are spec files. -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: bumpspecfile.py Type: application/x-python Size: 2249 bytes Desc: not available URL: From gafton at redhat.com Fri Feb 25 22:33:02 2005 From: gafton at redhat.com (Cristian Gafton) Date: Fri, 25 Feb 2005 17:33:02 -0500 (EST) Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: References: Message-ID: On Fri, 25 Feb 2005, Elliot Lee wrote: > In order to allow Extras development to proceed full-speed, all the Fedora > Extras module will have an FC-3 branch very shortly. Branching is done. All modules that had a devel/ branch present (ie, were not "dead") have been branched. Currently, the devel and FC-3 branches have the same content, so feel free to diverge as you see fit. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From bugs.michael at gmx.net Sat Feb 26 01:11:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 02:11:01 +0100 Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: <1109368324.23111.58.camel@cutter> References: <20050225224654.2ad9eacb.bugs.michael@gmx.net> <1109368324.23111.58.camel@cutter> Message-ID: <20050226021101.52e58782.bugs.michael@gmx.net> On Fri, 25 Feb 2005 16:52:03 -0500, seth vidal wrote: > >Who will increase the release versions for a build for FC4 test1? > > > > Can you do it for your packages? Sure, but I own only a very few. With a small modification, the same Perl script I used for the 0.fdr bump can also handle pre-release versions and other things correctly. The posted Python script fails there. From skvidal at phy.duke.edu Sat Feb 26 03:55:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 22:55:26 -0500 Subject: rawhide/fc4 extras builds Message-ID: <1109390126.27384.3.camel@cutter> Hey folks, for requesting builds of packages for fc4/rawhide. http://fedoraproject.org/wiki/Extras/FC4Status put them there. Thanks! -sv From wtogami at redhat.com Sat Feb 26 10:25:48 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 26 Feb 2005 00:25:48 -1000 Subject: rawhide/fc4 extras builds In-Reply-To: <1109390126.27384.3.camel@cutter> References: <1109390126.27384.3.camel@cutter> Message-ID: <42204EAC.9010800@redhat.com> seth vidal wrote: > Hey folks, > for requesting builds of packages for fc4/rawhide. > > http://fedoraproject.org/wiki/Extras/FC4Status > > put them there. > > Thanks! > -sv Wouldn't it be worthwhile to wait until after rawhide is rebuilt with gcc4 before building stuff into FE4? Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Sat Feb 26 14:46:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 15:46:52 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <42204EAC.9010800@redhat.com> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> Message-ID: <20050226154652.21d09ff4.bugs.michael@gmx.net> On Sat, 26 Feb 2005 00:25:48 -1000, Warren Togami wrote: > seth vidal wrote: > > Hey folks, > > for requesting builds of packages for fc4/rawhide. > > > > http://fedoraproject.org/wiki/Extras/FC4Status > > > > put them there. > > > > Thanks! > > -sv > > Wouldn't it be worthwhile to wait until after rawhide is rebuilt with > gcc4 before building stuff into FE4? What are the plans on filling the FE4 repository (where will it be located? "development"?) anyway? Start with an empty directory and only fulfill build requests? Or start with a mass-rebuild (e.g. for FC4 T1) and then fix things gradually? From jspaleta at gmail.com Sat Feb 26 15:12:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 10:12:29 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226154652.21d09ff4.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> Message-ID: <604aa7910502260712217ecafc@mail.gmail.com> On Sat, 26 Feb 2005 15:46:52 +0100, Michael Schwendt wrote: > What are the plans on filling the FE4 repository (where will it be > located? "development"?) anyway? Start with an empty directory and only > fulfill build requests? Or start with a mass-rebuild (e.g. for FC4 T1) and > then fix things gradually? personally.. i would say do a mass rebuild if possible.. to give the test release tester something to test.. if we are talking about the fc4t1 timeframe. Don't spoil them with crap that works, testers of test1 releases know they are chewing on shards of glass. You might need to do mass-rebuilds on a regular basis during the core testing phase to make syncing with rawhide dependancies managable. -jef From skvidal at phy.duke.edu Sat Feb 26 16:12:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:12:07 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226154652.21d09ff4.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> Message-ID: <1109434328.27384.68.camel@cutter> >What are the plans on filling the FE4 repository (where will it be >located? "development"?) anyway? Start with an empty directory and only >fulfill build requests? Or start with a mass-rebuild (e.g. for FC4 T1) and >then fix things gradually? > I'm doing builds as requested. I'm doing that b/c if people don't bump release numbers then it just seems like it could cause problems. -sv From skvidal at phy.duke.edu Sat Feb 26 16:13:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:13:05 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <604aa7910502260712217ecafc@mail.gmail.com> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <604aa7910502260712217ecafc@mail.gmail.com> Message-ID: <1109434385.27384.70.camel@cutter> On Sat, 2005-02-26 at 10:12 -0500, Jeff Spaleta wrote: >On Sat, 26 Feb 2005 15:46:52 +0100, Michael Schwendt > wrote: >> What are the plans on filling the FE4 repository (where will it be >> located? "development"?) anyway? Start with an empty directory and only >> fulfill build requests? Or start with a mass-rebuild (e.g. for FC4 T1) and >> then fix things gradually? > >personally.. i would say do a mass rebuild if possible.. to give the >test release tester something to test.. if we are talking about the >fc4t1 timeframe. Don't spoil them with crap that works, testers of >test1 releases know they are chewing on shards of glass. You might >need to do mass-rebuilds on a regular basis during the core testing >phase to make syncing with rawhide dependancies managable. While I don't think doing a mass rebuild this moment is a good idea I do think you're right. My point in doing builds now rather than just later is to make sure we have a leg to stand on vs some of the vocal critics of extras. -sv From bugs.michael at gmx.net Sat Feb 26 16:20:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:20:28 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <1109434328.27384.68.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> Message-ID: <20050226172028.03b28d62.bugs.michael@gmx.net> On Sat, 26 Feb 2005 11:12:07 -0500, seth vidal wrote: > > >What are the plans on filling the FE4 repository (where will it be > >located? "development"?) anyway? Start with an empty directory and only > >fulfill build requests? Or start with a mass-rebuild (e.g. for FC4 T1) and > >then fix things gradually? > > > > I'm doing builds as requested. > > I'm doing that b/c if people don't bump release numbers then it just > seems like it could cause problems. I volunteer to bump all release versions. But there were a few commits to FC-3 and devel branches last night, which need special care. From skvidal at phy.duke.edu Sat Feb 26 16:39:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:39:25 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226172028.03b28d62.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> Message-ID: <1109435966.27384.78.camel@cutter> >I volunteer to bump all release versions. But there were a few commits >to FC-3 and devel branches last night, which need special care. I tested out that bumpspec script (the second one) on a bunch of specfiles last night - it does, mostly, the right thing. -sv From bugs.michael at gmx.net Sat Feb 26 16:44:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 17:44:00 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <1109435966.27384.78.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> Message-ID: <20050226174400.30d1e828.bugs.michael@gmx.net> On Sat, 26 Feb 2005 11:39:25 -0500, seth vidal wrote: > > >I volunteer to bump all release versions. But there were a few commits > >to FC-3 and devel branches last night, which need special care. > > I tested out that bumpspec script (the second one) on a bunch of > specfiles last night - it does, mostly, the right thing. I still disagree. But that doesn't move us forward. So, what is the plan? From skvidal at phy.duke.edu Sat Feb 26 16:57:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:57:55 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226174400.30d1e828.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> Message-ID: <1109437075.27384.83.camel@cutter> On Sat, 2005-02-26 at 17:44 +0100, Michael Schwendt wrote: >On Sat, 26 Feb 2005 11:39:25 -0500, seth vidal wrote: > >> >> >I volunteer to bump all release versions. But there were a few commits >> >to FC-3 and devel branches last night, which need special care. >> >> I tested out that bumpspec script (the second one) on a bunch of >> specfiles last night - it does, mostly, the right thing. > >I still disagree. But that doesn't move us forward. So, what is the plan? you disagree with the script? If you want to do them by hand that's fine by me. I'm not sure what we're disagreeing about. Do you want to do a mass rebuild as a test now? -sv From skvidal at phy.duke.edu Sat Feb 26 17:03:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 12:03:10 -0500 Subject: Fedora Extras heads-up - CVS is branching In-Reply-To: <20050226021101.52e58782.bugs.michael@gmx.net> References: <20050225224654.2ad9eacb.bugs.michael@gmx.net> <1109368324.23111.58.camel@cutter> <20050226021101.52e58782.bugs.michael@gmx.net> Message-ID: <1109437390.27384.85.camel@cutter> >Sure, but I own only a very few. > >With a small modification, the same Perl script I used for the 0.fdr bump >can also handle pre-release versions and other things correctly. The >posted Python script fails there. I completely missed this post, sorry. Whatever script works for you. -sv From bugs.michael at gmx.net Sat Feb 26 17:19:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 18:19:50 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <1109437075.27384.83.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> Message-ID: <20050226181950.683f7de3.bugs.michael@gmx.net> On Sat, 26 Feb 2005 11:57:55 -0500, seth vidal wrote: > >> >I volunteer to bump all release versions. But there were a few commits > >> >to FC-3 and devel branches last night, which need special care. > >> > >> I tested out that bumpspec script (the second one) on a bunch of > >> specfiles last night - it does, mostly, the right thing. > > > >I still disagree. But that doesn't move us forward. So, what is the plan? > > you disagree with the script? Yes, it fails to deal with several types of release versions, e.g. fedora.us pre-release versioning scheme and macros in the release tag. > If you want to do them by hand that's fine by me. I'm not sure what > we're disagreeing about. Do you want to do a mass rebuild as a test now? I want to avoid [more] chaos if that's possible, please. We have the FC-3-split in CVS now, but how do we proceed? Every commit to FC-3 branch moves "devel" more out-of-sync. It is not clear to me what you have planned. Do you want every individual package owner to bump release versions in current "devel" tree on some day between now and FC4T1? At fedora.us we've had mass-rebuilds for the first or second test release, and the dist tag made a release bump unnecessary. In Fedora Extras, this is the first time we branch in CVS, and we need a concept. And no, I don't want to bump >571 versions "by hand". I didn't do that with the 0.fdr.x.y versions after import either. Thanks Perl! From skvidal at phy.duke.edu Sat Feb 26 17:38:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 12:38:08 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226181950.683f7de3.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> Message-ID: <1109439489.27384.97.camel@cutter> >Yes, it fails to deal with several types of release versions, e.g. >fedora.us pre-release versioning scheme and macros in the release tag. ah, I didn't realize. >> If you want to do them by hand that's fine by me. I'm not sure what >> we're disagreeing about. Do you want to do a mass rebuild as a test now? > >I want to avoid [more] chaos if that's possible, please. What's chaotic right now? >We have the FC-3-split in CVS now, but how do we proceed? Every commit to >FC-3 branch moves "devel" more out-of-sync. yes, that's the same that happens with fedora core. >It is not clear to me what you have planned. Do you want every individual >package owner to bump release versions in current "devel" tree on some day >between now and FC4T1? I didn't have much of anything planned. We wanted the branch for extras so people could work on new versions of changed build deps due to fc4. The goal was to make extras cvs match core cvs so that people could follow 'development' sanely. >At fedora.us we've had mass-rebuilds for the first or second test release, >and the dist tag made a release bump unnecessary. Right but if you read the packaging guidelines, I'm not sure we're quite there yet for those bits of infrastructure. >In Fedora Extras, this is the first time we branch in CVS, and we need a >concept. The concept is simple - give a place to start from and to start merging to. When fc-4 gets finally branched in core cvs then we should branch fc-4 in extras as well and 'devel' becomes the new location for: 1. the fedora extras development repository 2. the new work for fc5 Then the FC-4 branch in extras becomes where you merge changes for FC-4 extras packages to. FC-3 for FC-3 extras package changes. etc etc etc. thats the the structure that I think was intended. So extras matches how core is developed. does that make sense to you? -sv -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at phy.duke.edu Sat Feb 26 17:39:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 12:39:23 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <1109439489.27384.97.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> Message-ID: <1109439563.27384.99.camel@cutter> >>At fedora.us we've had mass-rebuilds for the first or second test release, >>and the dist tag made a release bump unnecessary. > >Right but if you read the packaging guidelines, I'm not sure we're >quite there yet for those bits of infrastructure. > > >>In Fedora Extras, this is the first time we branch in CVS, and we need a >>concept. > >The concept is simple - give a place to start from and to start merging >to. When fc-4 gets finally branched in core cvs then we should branch >fc-4 in extras as well and 'devel' becomes the new location for: > 1. the fedora extras development repository > 2. the new work for fc5 > >Then the FC-4 branch in extras becomes where you merge changes for FC-4 >extras packages to. >FC-3 for FC-3 extras package changes. >etc >etc >etc. > >thats the the structure that I think was intended. So extras matches >how core is developed. > >does that make sense to you? >-sv Sorry for that being html-mail - the workaround to a composer bug in evo is to write in html-mode then swap it back to text-mode when you finish. I forgot to do that. -sv From bugs.michael at gmx.net Sat Feb 26 18:28:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 19:28:30 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <1109439489.27384.97.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> Message-ID: <20050226192830.36b8f59e.bugs.michael@gmx.net> On Sat, 26 Feb 2005 12:38:08 -0500, seth vidal wrote: > >> If you want to do them by hand that's fine by me. I'm not sure what > >> we're disagreeing about. Do you want to do a mass rebuild as a test now? > > > >I want to avoid [more] chaos if that's possible, please. > > > What's chaotic right now? Chaos at several fronts: a sudden mass-rebuild from a non-ready CVS for pre-extras, rushed attempts at trimming down core, uncoordinated package submissions, potentially orphaned packages (maybe even a few more), not every packager has CVS access, rebuilds without build requests (e.g. PPC builds of xv or unreviewed packages). I think coordination could be better. > >It is not clear to me what you have planned. Do you want every individual > >package owner to bump release versions in current "devel" tree on some day > >between now and FC4T1? > > > I didn't have much of anything planned. We wanted the branch for extras > so people could work on new versions of changed build deps due to fc4. > The goal was to make extras cvs match core cvs so that people could > follow 'development' sanely. And that means more chaos, because packages have build requirements and hence depend on other packages to be ready, too. > >At fedora.us we've had mass-rebuilds for the first or second test release, > >and the dist tag made a release bump unnecessary. > > > Right but if you read the packaging guidelines, I'm not sure we're quite > there yet for those bits of infrastructure. I didn't mean that. I don't like dist tags, and they don't add value unless you rebuild each and every update for all distributions. -snip- > does that make sense to you? No, it doesn't. Sorry. It doesn't answer my earlier questions. It doesn't answer when and whether to mass-rebuild. From skvidal at phy.duke.edu Sun Feb 27 01:16:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 20:16:55 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050226192830.36b8f59e.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> <20050226192830.36b8f59e.bugs.michael@gmx.net> Message-ID: <1109467015.27384.123.camel@cutter> >Chaos at several fronts: a sudden mass-rebuild from a non-ready CVS for >pre-extras, that was over a month ago and extras actually looks pretty good to me, right now. > not >every packager has CVS access, rebuilds without build requests (e.g. PPC >builds of xv or unreviewed packages). I think coordination could be better. How would you improve coordination w/o slowing things to a snails pace? your list sound less like 'chaos' and more like 'everything isn't perfect' >And that means more chaos, because packages have build requirements >and hence depend on other packages to be ready, too. no! packages have build requirements?!?! All this time I thought they were magically getting resolved. Well I'll be damned. Cmon Michael, I know this - but you should know that rawhide is not a stable place all the time and I wouldn't expect or demand that the 'devel' branch of fedora extras be stable either. >No, it doesn't. Sorry. It doesn't answer my earlier questions. It doesn't >answer when and whether to mass-rebuild. Well I think the answer, if you want to take my direction is this: 1. you get YOUR packages together. 2. we all encourage the other packagers to do the same for theirs 3. We set a bright deadline for devel tree release of extras and ask the packagers to stick to it. - I think maybe we should have that bright line be one week before the fc4t1 release - essentially slushy-freeze extras for 'devel' at the same time core freezes. 4. we figure out what's broken and fix it in that week, then release on-around the same time. 5. wash-rinse-repeat for fc4t2, t3 and final. Then we're ready to go! in the meantime I'm working on the build system stuff (mach2 + yum) so hopefully I'll have something for you use to test out your builds and it'll be a more controlled environment that you've been desiring. I'd personally love to get a cvs makefile options of 'make mach-$arch', though it might just be simplest to do: make srpm; mach rebuild $package.src.rpm -sv -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at phy.duke.edu Sun Feb 27 01:19:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 20:19:00 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <1109467015.27384.123.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> <20050226192830.36b8f59e.bugs.michael@gmx.net> <1109467015.27384.123.camel@cutter> Message-ID: <1109467140.27384.126.camel@cutter> >Well I think the answer, if you want to take my direction is this: > >1. you get YOUR packages together. >2. we all encourage the other packagers to do the same for theirs >3. We set a bright deadline for devel tree release of extras and ask >the packagers to stick to it. > - I think maybe we should have that bright line be one week before >the fc4t1 release - essentially slushy-freeze extras for 'devel' at the >same time core freezes. >4. we figure out what's broken and fix it in that week, then release >on-around the same time. > >5. wash-rinse-repeat for fc4t2, t3 and final. One more addendum: michael if you have time and want to do step 1 (obviously) and work on step 2 (prodding other maintainers) I think that'd be very cool. If you don't have time then I'll bring it up at the next fesco meeting as a bright deadline for release, if we have time. -sv From bugs.michael at gmx.net Sun Feb 27 01:58:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 27 Feb 2005 02:58:59 +0100 Subject: rawhide/fc4 extras builds In-Reply-To: <1109467015.27384.123.camel@cutter> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> <20050226192830.36b8f59e.bugs.michael@gmx.net> <1109467015.27384.123.camel@cutter> Message-ID: <20050227025859.407b1405.bugs.michael@gmx.net> On Sat, 26 Feb 2005 20:16:55 -0500, seth vidal wrote: > >No, it doesn't. Sorry. It doesn't answer my earlier questions. It doesn't > >answer when and whether to mass-rebuild. > > > Well I think the answer, if you want to take my direction is this: > > 1. you get YOUR packages together. > 2. we all encourage the other packagers to do the same for theirs > 3. We set a bright deadline for devel tree release of extras and ask the > packagers to stick to it. > - I think maybe we should have that bright line be one week before the > fc4t1 release - essentially slushy-freeze extras for 'devel' at the same > time core freezes. > 4. we figure out what's broken and fix it in that week, then release > on-around the same time. > > 5. wash-rinse-repeat for fc4t2, t3 and final. > > Then we're ready to go! My plan would have been this: 1. bump release of every package in "devel" 2. make sure that every update of FC-3 and older either loses RPM version comparison compared with "devel" or is also imported into "devel" tree with a higher release number Then we would be ready for a mass-rebuild any time. From skvidal at phy.duke.edu Sun Feb 27 02:56:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 21:56:42 -0500 Subject: rawhide/fc4 extras builds In-Reply-To: <20050227025859.407b1405.bugs.michael@gmx.net> References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com> <20050226154652.21d09ff4.bugs.michael@gmx.net> <1109434328.27384.68.camel@cutter> <20050226172028.03b28d62.bugs.michael@gmx.net> <1109435966.27384.78.camel@cutter> <20050226174400.30d1e828.bugs.michael@gmx.net> <1109437075.27384.83.camel@cutter> <20050226181950.683f7de3.bugs.michael@gmx.net> <1109439489.27384.97.camel@cutter> <20050226192830.36b8f59e.bugs.michael@gmx.net> <1109467015.27384.123.camel@cutter> <20050227025859.407b1405.bugs.michael@gmx.net> Message-ID: <1109473002.27384.129.camel@cutter> >My plan would have been this: > > 1. bump release of every package in "devel" > 2. make sure that every update of FC-3 and older either loses > RPM version comparison compared with "devel" or is also imported > into "devel" tree with a higher release number > >Then we would be ready for a mass-rebuild any time. Let's ask if anyone is bothered by you doing #1 with your script. Anyone got a problem with that? We can do #2 iteratively post-mass-rebuild. I bet it will only be a handful of items anyway. then on with the rebuild-foo. the only item we might want to delay a tiny bit on is gcc->gcc4. -sv From twaugh at redhat.com Mon Feb 28 09:34:45 2005 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 28 Feb 2005 09:34:45 +0000 Subject: Saving space: drop Omni? Message-ID: <20050228093444.GL3626@redhat.com> All the recent talk of saving space on CDs reminded me of a suggestion from a while back. Should we drop Omni? Does anyone actually use it successfully with their printer? (How to tell: go to System Settings->Printing, double-click on each queue name, go to the Printer driver tab and see if omni-compiled is selected.) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 28 21:01:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 16:01:55 -0500 Subject: Saving space: drop Omni? In-Reply-To: <20050228093444.GL3626@redhat.com> References: <20050228093444.GL3626@redhat.com> Message-ID: <20050228210155.GE10778@nostromo.devel.redhat.com> Tim Waugh (twaugh at redhat.com) said: > All the recent talk of saving space on CDs reminded me of a suggestion > from a while back. > > Should we drop Omni? Does anyone actually use it successfully with > their printer? I have a sample of one printer that doesn't use Omni. :) Is there some way to drill out a list of what printers default to Omni? Bill