From byte at aeon.com.my Fri Apr 1 00:47:15 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 01 Apr 2005 10:47:15 +1000 Subject: kernel 2.6 In-Reply-To: <6.1.2.0.2.20050323171235.03b2f120@mail.easyhosting.nl> References: <001601c52fc3$27c865a0$5a4e84c8@anp4> <6.1.2.0.2.20050323171235.03b2f120@mail.easyhosting.nl> Message-ID: <1112316435.8582.366.camel@arena.soho.bytebot.net> On Wed, 2005-03-23 at 17:13 +0100, Jeroen Wunnink wrote: > It's going to boil down to compiling it yourself, there's no official > or legacy 2.6 kernels for RH9 afaik One good thing about a 2.6 kernel is that something as magical as "make rpm" will work, so RPM can manage your new 2.6 kernel As per the thread though, read up and beware the things that need changing... -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From cave.dnb at tiscali.fr Fri Apr 1 01:00:27 2005 From: cave.dnb at tiscali.fr (nigel henry) Date: Fri, 1 Apr 2005 02:00:27 +0100 Subject: kernel 2.4.22-1.2199.4.legacy.nptl for FC1 Message-ID: <200504010200.27978.cave.dnb@tiscali.fr> Hi folks. Just a small query to break the tension from the big mysql debate. DL'd the latest legacy kernel for FC1 on 1 machine ok. I've another instance of FC1 that runs on the same machine but as it runs a later kernel from planetccrma for multimedia apps I didn't expect fedora legacy to update that one. But on the other machine which I boot from floppy to a 2.4.22-1.2199.nptl kernel no update to the 2199.4.legacy.nptl has appeared. I havn't missed the update caus it's not in /boot, and isn't on the yum log. Has the updated kernel been removed for some reason? Nigel. From shurdeek at routehat.org Fri Apr 1 10:56:30 2005 From: shurdeek at routehat.org (Peter Surda) Date: Fri, 1 Apr 2005 12:56:30 +0200 Subject: Automatic updates again (well mysql actually) Message-ID: <20050401105623.GC29701@soldats.localdomain> Hello, while I agree that you should test updates (by whatever means required) before installing them on productions machines, it remans a fact that after updating mysql-server without stopping it before, you often reach a state where getting it working requires manuain intervention (service mysqld restart often isn't enough). This isn't new. Previous mysql-server updates also behaved like this, just apparently noone complained in the list. Unless there is a technical reason for it to behave like this (which I don't think because I use other distributions as well and these don't suffer from this problem), I think it is safe to say that this is a bug, and it makes sense to fix it (please note I didn't say "it is necessary to fix it", just that it makes sense). So could we perhaps stick to the technical part, try to find a fix and leave the patch management policies to someone else? Bye, Peter Surda (Shurdeek) , ICQ 10236103, +436505122023 -- Don't drink and su. From Axel.Thimm at ATrpms.net Fri Apr 1 12:12:17 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 1 Apr 2005 14:12:17 +0200 Subject: Upcoming FC2 smooth takeover: create repo now? Message-ID: <20050401121217.GJ12606@neu.nirvana> Hi, would it make sense this time to prepare a repo for FC2 before its goes EOL and only place the current updates inside (no FL stuff yet)? depsolver configurations could start pointing to FL so that when FL takes over FC2 most users will already have their config pointing to the right place. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Apr 1 12:09:05 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 1 Apr 2005 14:09:05 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <424C32F6.20409@lxpro.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> Message-ID: <20050401120905.GI12606@neu.nirvana> On Thu, Mar 31, 2005 at 10:27:18AM -0700, Greg Bailey wrote: > Jesse Keating wrote: > > >On Sat, 2005-03-26 at 23:31 +0100, Axel Thimm wrote: > > > > > >>Could the parts that are mirrored from Red Hat be timestamped back to > >>their original values? For instance: > >> > >>58217 Oct 29 2003 > >>download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ncompress-4.2.4-34.src.rpm > >>58217 Feb 27 2004 > >>download.fedoralegacy.org/fedora/1/os/SRPMS/ncompress-4.2.4-34.src.rpm > >> > >>This would allow mirrors of both RH and FL to run hardlink over the > >>folders and rescue some bits. > >> > >> > > > >Got a good suggestion on how to do that w/out re-downloading every file > >from RH mirrors? > > > > > > > Wouldn't running rsync over the mirrored parts go fairly quickly if you > already have the full fileset? I recall doing this sort of thing when I > was a RedHat mirror admin in a former life. It didn't take long at all > with the speedup rsync provides. Yes, that would be the easiest. And if one wants to tune this, one can use the -B switch to rsync to use larger blocks for the checksums, but that's probably not neccessary. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Fri Apr 1 16:47:25 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 1 Apr 2005 10:47:25 -0600 Subject: Automatic updates again (well mysql actually) In-Reply-To: <20050401105623.GC29701@soldats.localdomain> References: <20050401105623.GC29701@soldats.localdomain> Message-ID: <1112374045.0e5b2c5439a21@mail.ph.utexas.edu> Quoting Peter Surda : > Unless there is a technical reason for it to behave like this (which I don't > think because I use other distributions as well and these don't suffer from > this problem), I think it is safe to say that this is a bug, and it makes > sense to fix it (please note I didn't say "it is necessary to fix it", just > that it makes sense). IIRC, a bug has been filed to fix this problem. > So could we perhaps stick to the technical part, try to find a fix and leave > the patch management policies to someone else? I think we need to address both. Fixing mysql won't make the other problems go away, as they are sure to happen again at some point with some other application. And I think that FL is making progress on fixing both problems (patch managment and mysql failure). Others may disagree. > Bye, > > Peter Surda (Shurdeek) , ICQ 10236103, +436505122023 -- Eric Rostetter From shurdeek at routehat.org Fri Apr 1 17:01:02 2005 From: shurdeek at routehat.org (Peter Surda) Date: Fri, 1 Apr 2005 19:01:02 +0200 Subject: Automatic updates again (well mysql actually) In-Reply-To: <1112374045.0e5b2c5439a21@mail.ph.utexas.edu> References: <20050401105623.GC29701@soldats.localdomain> <1112374045.0e5b2c5439a21@mail.ph.utexas.edu> Message-ID: <20050401170101.GE29701@soldats.localdomain> On Fri, Apr 01, 2005 at 10:47:25AM -0600, Eric Rostetter wrote: > IIRC, a bug has been filed to fix this problem. Ok, I'll add some more info into it. > Eric Rostetter Bye, Peter Surda (Shurdeek) , ICQ 10236103, +436505122023 -- rm -f /bin/laden From J.S.Peatfield at damtp.cam.ac.uk Fri Apr 1 19:38:14 2005 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 1 Apr 2005 20:38:14 +0100 (BST) Subject: STOP USING FEDORA.US BUGZILLA In-Reply-To: <1112226715.3471.343.camel@jkeating2.hq.pogolinux.com> References: <1112226715.3471.343.camel@jkeating2.hq.pogolinux.com> Message-ID: On Wed, 30 Mar 2005, Jesse Keating wrote: > Thats right folks, we have migrated all bug data from fedora.us to Red > Hat this afternoon. Please do not use fedora.us anymore as any changes > will not be recorded. > > All bugs have been moved over, but they have new numbers. Please see > the Fedora Legacy component at Red Hat's bugzilla to find your bugs. Could each of the old bugs (on fedora.us) have a pointer to the equivalent new one, or there be some obvious mapping somewhere? I am trying to keep track of a few of these but I seem to be having difficulty finding some of them in the new bugzilla -- almost certainly my fault but a link from the old bug page would help the transition! My attempts to search for ALL fedora legacy bugs (core1/rh73/rh9) on bugzilla.redhat.com only finds 10 bugs so I'm doing something wrong! -- Jon From jkeating at j2solutions.net Fri Apr 1 19:48:53 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 01 Apr 2005 11:48:53 -0800 Subject: STOP USING FEDORA.US BUGZILLA In-Reply-To: References: <1112226715.3471.343.camel@jkeating2.hq.pogolinux.com> Message-ID: <1112384933.3471.455.camel@jkeating2.hq.pogolinux.com> On Fri, 2005-04-01 at 20:38 +0100, Jon Peatfield wrote: > My attempts to search for ALL fedora legacy bugs (core1/rh73/rh9) on > bugzilla.redhat.com only finds 10 bugs so I'm doing something wrong! Try this query: https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora +Legacy&version=core1&version=rhl7.3&version=rhl9&version=unspecified&bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ASSIGN_TO_PM&bug_status=INVESTIGATE&bug_status=SPEC&bug_status=ON_DEV&bug_status=QA_READY&bug_status=ON_QA&bug_status=PROD_READY&bug_status=FAILS_QA&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= Basically I selected Fedora Legacy, selected each OS version, did NOT select a component, but then selected each and every bug state. I get 281 bugs. -- 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 rostetter at mail.utexas.edu Fri Apr 1 23:40:40 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 1 Apr 2005 17:40:40 -0600 Subject: STOP USING FEDORA.US BUGZILLA In-Reply-To: <1112384933.3471.455.camel@jkeating2.hq.pogolinux.com> References: <1112226715.3471.343.camel@jkeating2.hq.pogolinux.com> <1112384933.3471.455.camel@jkeating2.hq.pogolinux.com> Message-ID: <1112398840.63e9aba75147a@mail.ph.utexas.edu> Quoting Jesse Keating : > On Fri, 2005-04-01 at 20:38 +0100, Jon Peatfield wrote: > > My attempts to search for ALL fedora legacy bugs (core1/rh73/rh9) on > > bugzilla.redhat.com only finds 10 bugs so I'm doing something wrong! > > Try this query: [...] It seems to work with just: https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Legacy > Basically I selected Fedora Legacy, selected each OS version, did NOT > select a component, but then selected each and every bug state. I get > 281 bugs. The above, which is now on the main web page, also gets 281 bugs. -- Eric Rostetter From unix at bikesn4x4s.com Fri Apr 1 23:57:13 2005 From: unix at bikesn4x4s.com (Paul) Date: Fri, 1 Apr 2005 18:57:13 -0500 (EST) Subject: mysql-server In-Reply-To: <1112311857.2f628bc7848bb@mail.ph.utexas.edu> References: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza> <1112195208.b768cfa1990cf@mail.ph.utexas.edu> <1112311857.2f628bc7848bb@mail.ph.utexas.edu> Message-ID: <4720.192.168.103.1.1112399833.squirrel@192.168.103.1> On Thu, March 31, 2005 6:30 pm, Eric Rostetter said: > > For anyone who wants to further study the issue of "best practices" for > update managment, the following Microsoft (of all things) link may be of > interest. While it is specific to Microsoft Windows, the basic concepts > all apply to linux. The basic premise is: don't do automatic updates > on production servers, don't blindly install every update that comes out, > and have a plan that you follow for doing updates. The link is: > > http://www.microsoft.com/technet/security/bestprac/bpsp.mspx > > Another doc that may be of interest as well is: > > www.cressida.info/pdfs/whitepapers/bestpractices.pdf Yea, it's just common sense. I do all that manually. I even will do a major backup of the whole system so I can back out of it. I just can't believe anyone would complain. You guys word at donating time for these updates, why anyone would complain is beyond me. From beartooth at adelphia.net Sat Apr 2 18:41:01 2005 From: beartooth at adelphia.net (beartooth) Date: Sat, 02 Apr 2005 13:41:01 -0500 Subject: Synaptic trouble under FC2 Message-ID: Apologies if it's premature to put an FC2 question here! I've been running it on one machine, updating with synaptic, which I invoke from a launcher on the panel. This morning that kept failing: the program would demand root's password, get it, start to open, and then suddenly disappear. So I tried it another way : ===== [root at localhost root]# synaptic & [1] 24587 [root at localhost root]# (synaptic:24587): Gtk-CRITICAL **: file gtkwidget.c: line 2041 (gtk_widget_hide): assertion `GTK_IS_WIDGET (widget)' failed [root at localhost root]# (synaptic:24587): Gtk-CRITICAL **: file gtktreeview.c: line 7732 (gtk_tree_view_unref_tree_helper): assertion `node != NULL' failed ==== After a couple error messages like that, at least one mentioning a segmentation fault, iirc, I did "yum update synaptic" -- only to be told it was already installed and the latest version. But next time -- i.e., the iteration shown above -- it did open, stay open, and appeared to work. I'd been planning to start upgrading FC1 machines to FC2, as soon as I could be sure I'd gotten an updater on the first machine through the transition to legacy. But now, it seems, synaptic is having real troubles even before the transition -- unless there's some relevance there that I don't see. Any comment a/o advice welcome! -- Beartooth Implacable, Linux Evangelist & Gadfly neo-redneck, curmudgeonly codger with FC1&2, YDL4 Pine 4.62, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0 Bear in mind that I have little idea what I am talking about. From kwade at redhat.com Wed Apr 6 00:49:08 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 05 Apr 2005 17:49:08 -0700 Subject: [RFC] Legacy documentation Message-ID: <1112748548.14163.5.camel@erato.phig.org> I've been wondering about this for a while, so when Stuart brought up the age of the Keeping Up to Date tutorial: http://fedora.redhat.com/docs/updates/ today on #fedora-docs, I figured it was time to open this discussion. I'm hoping you are interested in taking over some documentation. We have a few documents that are FC2 specific and are going to be orphaned when FC2 moves over to the Legacy Project. The Docs Project (FDP) follows the Fedora Core release and maintenance schedule, meaning when a version of Core goes to the Legacy Project, the docs should go with it. I'll list what those docs are (just a few), bring up some ideas about what can be done with them, and finish with a few useful URLs. ## The Docs: We'll have a list that is a bit longer for FC3 when that time comes. Keeping Up to Date (FC2) http://fedora.redhat.com/docs/updates/ We're likely to update this for FC4, if a writer pops up wanting it. Fedora Jargon Buster http://fedora.redhat.com/docs/jargon-buster/ This was written originally under FC1. It may not be out of date, but it hasn't been updated in six months. Package List for Fedora Core 2 http://fedora.redhat.com/docs/package-list/fc2/ I don't know anything about this or its value. Release notes for FC2 http://fedora.redhat.com/docs/release-notes/fc2/x86/ http://fedora.redhat.com/docs/release-notes/fc2/x86_64/ Not sure that you'd ever want to update them, and we can certainly leave them in place. For relnotes in particular it's a good thing to keep old ones around. Fedora Core 2 SELinux FAQ http://fedora.redhat.com/docs/selinux-faq-fc2/ SELinux had a breakdown in updates to FC2, and this FAQ says at the top to upgrade to FC3. However, if anyone is trying to work with SELinux in FC2, this FAQ might be valuable. ## What to Do? I'm just throwing out a few ideas, which may even be somewhat exclusive of each other. 1. Legacy Docs could be a sub-project of the Docs Project. There is no rule that says what is in our purview. I keep the nose of the project turned in the direction Fedora Core is going, but the rest of the head can be doing other things at the same time. Currently, we don't have enough writers to work on new documents that are needed for FC. I don't know of anyone interested in the Legacy docs. IMO, maintenance of a set of Legacy docs is likely to be easier than a doc that tracks something with an active update schedule in FC. I had this with the SELinux FAQ. It was very active during the early parts of the release, and tapered off as rawhide become more of the next version. This means that one or two people could maintain quite a large set of docs. This could be great experience for someone interested in technical writing, open source projects, or need to support a legacy app. By integrating the efforts, current docs could be written with Legacy needs in mind. Whatever those turn out to be. 2. Legacy Project can form the Legacy Docs as a sub-project. This is more of a throw over the wall scheme. I'd recommend that the FDP remain available to help train on the tools. Since the Legacy Project is going to need to staff the a documentation effort with writers, you might as well keep them close to the rest of the project. 3. Legacy Project could cherry-pick from the versioned docs. The FDP would likely keep the outdated docs available, but mark them clearly as not current. The FDP will help get Legacy writers up to speed, mainly through our standard docs and procedures, then mailing list support where needed. ## URLs FDP page: http://fedora.redhat.com/projects/docs/ For an overview of the docs process: http://fedora.redhat.com/participate/documentation-quick-start/ Our Wiki page is still being added to, we'll be adding process documentation through this medium: http://fedoraproject.org/wiki/DocsProject Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 dsccable at comcast.net Wed Apr 6 04:01:48 2005 From: dsccable at comcast.net (David Curry) Date: Wed, 06 Apr 2005 00:01:48 -0400 Subject: [RFC] Legacy documentation In-Reply-To: <1112748548.14163.5.camel@erato.phig.org> References: <1112748548.14163.5.camel@erato.phig.org> Message-ID: <42535F2C.5080404@comcast.net> Karsten Wade wrote: >I've been wondering about this for a while, so when Stuart brought up >the age of the Keeping Up to Date tutorial: > >http://fedora.redhat.com/docs/updates/ > >today on #fedora-docs, I figured it was time to open this discussion. >I'm hoping you are interested in taking over some documentation. > >We have a few documents that are FC2 specific and are going to be >orphaned when FC2 moves over to the Legacy Project. The Docs Project >(FDP) follows the Fedora Core release and maintenance schedule, meaning >when a version of Core goes to the Legacy Project, the docs should go >with it. I'll list what those docs are (just a few), bring up some >ideas about what can be done with them, and finish with a few useful >URLs. > > I will certainly pitch in on FC2 documentation and FL documentation generally in near future. At the moment, I'm still getting past the reality noted in the Documentation Quick Start Guide, " Since reading the Documentation Guide can be a bit overwhelming ...." Don't have much in the way of technical skills so editing is a non-starter. Even a writing effort will need guidance toward selection of topics. Hard to write about something one knows little about. >## The Docs: > >We'll have a list that is a bit longer for FC3 when that time comes. > >Keeping Up to Date (FC2) > http://fedora.redhat.com/docs/updates/ > We're likely to update this for FC4, if a writer pops up wanting it. > >Fedora Jargon Buster > > http://fedora.redhat.com/docs/jargon-buster/ > > This was written originally under FC1. It may not be out of date, > but it hasn't been updated in six months. > >Package List for Fedora Core 2 > http://fedora.redhat.com/docs/package-list/fc2/ > > I don't know anything about this or its value. > >Release notes for FC2 > > http://fedora.redhat.com/docs/release-notes/fc2/x86/ > http://fedora.redhat.com/docs/release-notes/fc2/x86_64/ > > Not sure that you'd ever want to update them, and we can certainly > leave them in place. For relnotes in particular it's a good thing to > keep old ones around. > >Fedora Core 2 SELinux FAQ > > http://fedora.redhat.com/docs/selinux-faq-fc2/ > > SELinux had a breakdown in updates to FC2, and this FAQ says at the > top to upgrade to FC3. However, if anyone is trying to work with > SELinux in FC2, this FAQ might be valuable. > >## What to Do? > >I'm just throwing out a few ideas, which may even be somewhat exclusive >of each other. > >1. Legacy Docs could be a sub-project of the Docs Project. > >There is no rule that says what is in our purview. I keep the nose of >the project turned in the direction Fedora Core is going, but the rest >of the head can be doing other things at the same time. > >Currently, we don't have enough writers to work on new documents that >are needed for FC. I don't know of anyone interested in the Legacy >docs. > >IMO, maintenance of a set of Legacy docs is likely to be easier than a >doc that tracks something with an active update schedule in FC. I had >this with the SELinux FAQ. It was very active during the early parts of >the release, and tapered off as rawhide become more of the next version. > >This means that one or two people could maintain quite a large set of >docs. This could be great experience for someone interested in >technical writing, open source projects, or need to support a legacy >app. > >By integrating the efforts, current docs could be written with Legacy >needs in mind. Whatever those turn out to be. > > It matters not to me whether I work through Fedora docs, FL docs, or both. >2. Legacy Project can form the Legacy Docs as a sub-project. > >This is more of a throw over the wall scheme. I'd recommend that the >FDP remain available to help train on the tools. > >Since the Legacy Project is going to need to staff the a documentation >effort with writers, you might as well keep them close to the rest of >the project. > > >3. Legacy Project could cherry-pick from the versioned docs. The FDP >would likely keep the outdated docs available, but mark them clearly as >not current. The FDP will help get Legacy writers up to speed, mainly >through our standard docs and procedures, then mailing list support >where needed. > > >## URLs > >FDP page: > >http://fedora.redhat.com/projects/docs/ > >For an overview of the docs process: > >http://fedora.redhat.com/participate/documentation-quick-start/ > >Our Wiki page is still being added to, we'll be adding process >documentation through this medium: > >http://fedoraproject.org/wiki/DocsProject > > >Thanks - Karsten > > >------------------------------------------------------------------------ > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From leonard at den.ottolander.nl Wed Apr 6 13:08:49 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Apr 2005 15:08:49 +0200 Subject: mc CAN issues Message-ID: <1112792929.4810.115.camel@athlon.localdomain> Hi, I was wondering if there is any progress on fixing the CAN issues for mc (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152705 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152889). Nothing has happened for quite a while although test packages with all fixes included are available. A new issues has also surfaced in the mean time: CAN-2005-0763 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153982). Only affects mc <= 4.5.55 (RHL 7.3). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From skvidal at phy.duke.edu Wed Apr 6 18:30:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 14:30:48 -0400 Subject: yum force? In-Reply-To: <20050406182107.M8359@mm-vanecek.cc> References: <20050406182107.M8359@mm-vanecek.cc> Message-ID: <1112812249.10327.103.camel@cutter> > # uname -a > Linux mm-vanecek.cc 2.4.20-42.9.legacy #1 Sun Feb 20 14:31:58 EST 2005 i686 > athlon i386 GNU/Linux > > Should the i686 version of glibc-2.3.2-27.9.7.i686.rpm be installed? > > In either case, how does one do a yum --force install? > you don't. yum doesn't have a --force and never will if I have anything to say about it. and in the case of glibc - there's no glibc.athlon so glibc.i686 is the best one. -sv From lewis.jon at att.net Thu Apr 7 16:50:47 2005 From: lewis.jon at att.net (lewis.jon at att.net) Date: Thu, 07 Apr 2005 16:50:47 +0000 Subject: FC1 and SATA Message-ID: <040720051650.17394.425564E6000C12D1000043F22160280748020106D29C07990A04@att.net> I am trying to install Fedora Core 1 but it does not recognize my SATA drives. Does it support SATA? I may have an old distribution, I got it from PlanetCCRMA's (Stanford Universities low-latency audio kernal) site. Could this be my problem? I do want to try to stick with core 1 because it seems to be the most stable with CCRMA. If need be, I could use an old IDE drive for the OS, but will FC1 be able to use the SATAs once it is installed and happy on an IDE drive? Thanks, Jon From gbailey at lxpro.com Thu Apr 7 17:23:54 2005 From: gbailey at lxpro.com (Greg Bailey) Date: Thu, 07 Apr 2005 10:23:54 -0700 Subject: FC1 and SATA In-Reply-To: <040720051650.17394.425564E6000C12D1000043F22160280748020106D29C07990A04@att.net> References: <040720051650.17394.425564E6000C12D1000043F22160280748020106D29C07990A04@att.net> Message-ID: <42556CAA.8050605@lxpro.com> lewis.jon at att.net wrote: >I am trying to install Fedora Core 1 but it does not recognize my SATA drives. Does it support SATA? I may have an old distribution, I got it from PlanetCCRMA's (Stanford Universities low-latency audio kernal) site. Could this be my problem? I do want to try to stick with core 1 because it seems to be the most stable with CCRMA. If need be, I could use an old IDE drive for the OS, but will FC1 be able to use the SATAs once it is installed and happy on an IDE drive? >Thanks, >Jon > > > I think the SATA drivers were added sometime around 2.4.27, so chances are the kernel that comes with Fedora 1 (or PlanetCCRMA for that matter) wouldn't have those drivers unless RedHat has backported them. I recently ran into this problem in trying to modify RedHat 9 so that it could be installed on hardware with SATA drives. It's doable, but a bit of work. Basically, you'd have to modify and reproduce the following updated RPMS: kernel (IMPORTANT: you'll need RedHat's linux-2.4.2-changeloop.patch to support anaconda), kernel-smp, kernel-BOOT (this is used by anaconda at installation time), mkinitrd (to fix some bug in order to include the SATA modules on the initrd image--may not be necessary for FC1), anaconda, anaconda-runtime (to include PCI information for the SATA hardware in order to recognize it), and hwdata (I just grabbed the one for RHEL3). Then you'll need to use "buildinstall" from anaconda to rebuild the installation part of the CD image. For RedHat 9, I used: /usr/lib/anaconda-runtime/buildinstall \ --comp dist-9 \ --product "Red Hat Linux" \ --version 9 \ --release "Redhat 9 (Shrike)" \ $BASEFSDIR As for creating bootable media with updated RPMS, etc., there's already a fairly decent amount of information that exists for that part of the process. Sorry if this is too much information or slightly off topic, but it took me a considerable amount of time to get SATA-compatible installable media and thought it might save someone time who's trying to do something similar... Greg From mattdm at mattdm.org Mon Apr 11 17:38:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 13:38:56 -0400 Subject: so, we've got FC2 now... Message-ID: <20050411173856.GA17107@jadzia.bu.edu> There's currently 16 open FC2 bugs in RH bugzilla (and maybe some others with restricted status?). Should these get moved to Legacy and triaged? More specifically, should I do it? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Mon Apr 11 18:19:16 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 11 Apr 2005 11:19:16 -0700 Subject: so, we've got FC2 now... In-Reply-To: <20050411173856.GA17107@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> Message-ID: <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-11 at 13:38 -0400, Matthew Miller wrote: > There's currently 16 open FC2 bugs in RH bugzilla (and maybe some > others > with restricted status?). Should these get moved to Legacy and > triaged? More > specifically, should I do it? > > If you would like, that would be great (: As our front page says, we're still getting the infrastructure up for FC2. -- 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 rostetter at mail.utexas.edu Mon Apr 11 19:04:32 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 11 Apr 2005 14:04:32 -0500 Subject: wording question Message-ID: <1113246272.77cf62f2252c5@mail.ph.utexas.edu> In the Fedora Legacy docs, we use the terms "Consensus" and "Veto" which maybe are not the best way to do things. Consensus seeks that all or the vast majority of the participants be "for" a position. Veto means that something can be rejected without cause or reason. Instead, it might be suggested we switch to a system of "Consent" in which we don't need everyone to agree on something, but rather just that no one is against it. In order for it not to pass, anyone who is against it must be supported by a valid argument for their position. In other words, instead of requiring mass support, we just need to lack of opposition. And in order to oppose it, the opposition must provide a valid argument against it. Thoughts? -- Eric Rostetter From beartooth at adelphia.net Mon Apr 11 20:15:26 2005 From: beartooth at adelphia.net (beartooth) Date: Mon, 11 Apr 2005 16:15:26 -0400 Subject: so, we've got FC2 now... References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> Message-ID: On Mon, 11 Apr 2005 11:19:16 -0700, Jesse Keating wrote: [....] > As our front page says, we're > still getting the infrastructure up for FC2. Meaning, by 'front page,' www.fedoralegacy.org? Will it be announced there, or here, or (preferably) both when the mirrors are ready for yum and synaptic, and how to reset those apps? As soon as I have updating working smoothly, I have three more home machines I want to upgrade from FC1. Color me chomping at the bit. :-) Strength to all your arms! -- Beartooth Neo-Redneck, Linux Evangelist FC1&2; YDL4; Pine 4.62, Pan 0.14.2; Privoxy 3.0.1; Dillo-0.8.4-0.fdr.1.1, Opera 7.54, Firefox 1.0 Remember that I have little idea what I am talking about. From rostetter at mail.utexas.edu Mon Apr 11 20:53:12 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 11 Apr 2005 15:53:12 -0500 Subject: so, we've got FC2 now... In-Reply-To: References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113252792.3a483ce6a6465@mail.ph.utexas.edu> Quoting beartooth : > On Mon, 11 Apr 2005 11:19:16 -0700, Jesse Keating wrote: [....] > > > As our front page says, we're > > still getting the infrastructure up for FC2. > > Meaning, by 'front page,' www.fedoralegacy.org? Yes, that's what he means. > Will it be announced there, or here, or (preferably) both when the mirrors > are ready for yum and synaptic, and how to reset those apps? At least on the web page, probably on both but that I can't really say for sure. -- Eric Rostetter From mattdm at mattdm.org Mon Apr 11 21:58:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 17:58:04 -0400 Subject: so, we've got FC2 now... In-Reply-To: <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050411215804.GA25859@jadzia.bu.edu> On Mon, Apr 11, 2005 at 11:19:16AM -0700, Jesse Keating wrote: > If you would like, that would be great (: As our front page says, we're > still getting the infrastructure up for FC2. Hmmm. No 'fc2' version in the Fedora Legacy product. (It would be really good if when this is created, it'd be "fc2" rather than "core2", so that bugs can be easily transferred.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Mon Apr 11 22:08:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Apr 2005 18:08:30 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411215804.GA25859@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> Message-ID: <20050411220830.GC17345@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Mon, Apr 11, 2005 at 11:19:16AM -0700, Jesse Keating wrote: > > If you would like, that would be great (: As our front page says, we're > > still getting the infrastructure up for FC2. > > Hmmm. No 'fc2' version in the Fedora Legacy product. > > (It would be really good if when this is created, it'd be "fc2" rather than > "core2", so that bugs can be easily transferred.) Added. Bill From mattdm at mattdm.org Mon Apr 11 22:14:01 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 18:14:01 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411220830.GC17345@nostromo.devel.redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> Message-ID: <20050411221401.GA26936@jadzia.bu.edu> On Mon, Apr 11, 2005 at 06:08:30PM -0400, Bill Nottingham wrote: > > Hmmm. No 'fc2' version in the Fedora Legacy product. > > (It would be really good if when this is created, it'd be "fc2" rather than > > "core2", so that bugs can be easily transferred.) > Added. That was quick -- thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Apr 11 22:34:27 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 18:34:27 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411221401.GA26936@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> Message-ID: <20050411223427.GA27476@jadzia.bu.edu> On Mon, Apr 11, 2005 at 06:14:01PM -0400, Matthew Miller wrote: > On Mon, Apr 11, 2005 at 06:08:30PM -0400, Bill Nottingham wrote: > > > Hmmm. No 'fc2' version in the Fedora Legacy product. > > > (It would be really good if when this is created, it'd be "fc2" rather than > > > "core2", so that bugs can be easily transferred.) > > Added. > That was quick -- thanks! Hmm. For some reason, it didn't magically work though, and the version number had to be reassigned when moving across products. I thought that worked with my bugzilla. And all of the components got reset to 4Suite. Ah well -- I cleaned up the mess. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Mon Apr 11 22:42:21 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Apr 2005 18:42:21 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411223427.GA27476@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> Message-ID: <20050411224221.GA1337@redhat.com> On Mon, Apr 11, 2005 at 06:34:27PM -0400, Matthew Miller wrote: > On Mon, Apr 11, 2005 at 06:14:01PM -0400, Matthew Miller wrote: > > On Mon, Apr 11, 2005 at 06:08:30PM -0400, Bill Nottingham wrote: > > > > Hmmm. No 'fc2' version in the Fedora Legacy product. > > > > (It would be really good if when this is created, it'd be "fc2" rather than > > > > "core2", so that bugs can be easily transferred.) > > > Added. > > That was quick -- thanks! > > Hmm. For some reason, it didn't magically work though, and the version > number had to be reassigned when moving across products. I thought that > worked with my bugzilla. And all of the components got reset to 4Suite. Ah > well -- I cleaned up the mess. :) btw, there's ~600 kernel bugs assigned to FC2 right now. I've sent mail to dkl to ask him to perform some sql magic on the database to make some changes en masse. - A lot of them are very old, and a lot of them have been in NEEDINFO for _months_. These are probably never going to see any responses again. - Recently the FC2/FC3 kernels were very similar, so some bugs may still apply to FC3. For all those still open, I've asked they be transitioned to legacy bugs, with a comment added along the lines of "if this is still present in FC3, please clone this bug and adjust accordingly" Right now FC3 is on 2.6.11, and FC2 is on 2.6.10. I'm guessing you won't want to play the rebase-to-upstream game with -legacy, so you'll be in for some backporting ahead. The good news is the recent FC2 update I did fixes up all the currently known security issues so you should be safe for a while. When it comes to picking up your first bits for a kernel errata feel free to ping me and if I'm not too busy (ha!) I'll try to lend a hand / answer questions etc. (At least whilst 2.6.10 is fresh in my head :) Dave From mattdm at mattdm.org Mon Apr 11 22:47:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 18:47:37 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411224221.GA1337@redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> <20050411224221.GA1337@redhat.com> Message-ID: <20050411224737.GA27992@jadzia.bu.edu> On Mon, Apr 11, 2005 at 06:42:21PM -0400, Dave Jones wrote: > btw, there's ~600 kernel bugs assigned to FC2 right now. Sheeh. > - A lot of them are very old, and a lot of them have been in NEEDINFO > for _months_. These are probably never going to see any responses > again. I think we should close all of those, with a "reopen if this is a security issue and it is still an issue". > The good news is the recent FC2 update I did fixes up all the > currently known security issues so you should be safe for a while. Thanks. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Mon Apr 11 22:52:20 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Apr 2005 18:52:20 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411224737.GA27992@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> <20050411224221.GA1337@redhat.com> <20050411224737.GA27992@jadzia.bu.edu> Message-ID: <20050411225220.GC1337@redhat.com> On Mon, Apr 11, 2005 at 06:47:37PM -0400, Matthew Miller wrote: > On Mon, Apr 11, 2005 at 06:42:21PM -0400, Dave Jones wrote: > > btw, there's ~600 kernel bugs assigned to FC2 right now. > Sheeh. :-/ Theres bugs in there dating back to 2.6.5 era (maybe even earlier if you dig hard enough). There's a pretty good chance that those bugs got fixed in one of the next 5 upstream revisions. > > - A lot of them are very old, and a lot of them have been in NEEDINFO > > for _months_. These are probably never going to see any responses > > again. > I think we should close all of those, with a "reopen if this is a security > issue and it is still an issue". I'm 99.99999999999999% sure theres no security implications of any of them. If you spot any that are I'd like to know about it, because as I mentioned lots of these are FC3 bugs too. Dave From dsccable at comcast.net Mon Apr 11 23:14:02 2005 From: dsccable at comcast.net (David Curry) Date: Mon, 11 Apr 2005 19:14:02 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411173856.GA17107@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> Message-ID: <425B04BA.2020106@comcast.net> Matthew Miller wrote: >There's currently 16 open FC2 bugs in RH bugzilla (and maybe some others >with restricted status?). Should these get moved to Legacy and triaged? More >specifically, should I do it? > > > Since I don't really understand much about bugzilla --> updates, the response may be completely redundant. I hope not, but if it is I need to learn. The fedora download servers list 15 FC2 rpms in testing. See http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/ and follow the respective links for i386 and x86_64. What happens with those prospective updates? From davej at redhat.com Mon Apr 11 23:15:24 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Apr 2005 19:15:24 -0400 Subject: so, we've got FC2 now... In-Reply-To: <425B04BA.2020106@comcast.net> References: <20050411173856.GA17107@jadzia.bu.edu> <425B04BA.2020106@comcast.net> Message-ID: <20050411231524.GF1337@redhat.com> On Mon, Apr 11, 2005 at 07:14:02PM -0400, David Curry wrote: > Matthew Miller wrote: > > >There's currently 16 open FC2 bugs in RH bugzilla (and maybe some others > >with restricted status?). Should these get moved to Legacy and triaged? > >More > >specifically, should I do it? > > > > > > > Since I don't really understand much about bugzilla --> updates, the > response may be completely redundant. I hope not, but if it is I need > to learn. > > The fedora download servers list 15 FC2 rpms in testing. See > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/ > and follow the respective links for i386 and x86_64. What happens with > those prospective updates? ye gads, a kernel-hugemem update. That's a fun one, as it's been superceded by a newer kernel releases that don't have the 4g4g patch at all any more. Given no-one filed a bug on this (or even noticed) until now, it's probably a non-issue, and you can just drop that one. Dave From mattdm at mattdm.org Tue Apr 12 03:50:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 23:50:32 -0400 Subject: so, we've got FC2 now... In-Reply-To: <425B04BA.2020106@comcast.net> References: <20050411173856.GA17107@jadzia.bu.edu> <425B04BA.2020106@comcast.net> Message-ID: <20050412035032.GA4571@jadzia.bu.edu> On Mon, Apr 11, 2005 at 07:14:02PM -0400, David Curry wrote: > The fedora download servers list 15 FC2 rpms in testing. See > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/ > and follow the respective links for i386 and x86_64. What happens with > those prospective updates? Good question. Here's what's up with each one: dovecot-0.99.10.6-1,FC2,1: superceded by actual update to 0.99.13-4.FC2 libgnomeui-2.6.2-1: not sure -- can't find in bugzilla. says "update to fix filechooser crasher" mc-4.6.1-0.13.FC2: bug #148865 -- unreleased security fix nfs-utils-1.0.6-23: "Fixed some security issues found by SGI" -- bug #133556, *** WHICH IS MARKED RESTRICTED *** but doesn't appear to be addressed. I believe it's . policy-1.11.3-3.1 Small tweak ("add devnull sid") to selinux policy. SE Linux is pretty much not practically functional in FC2 anyway; I think they just gave up trying to fix it. And I think we'd be insane to try to tackle this. If we *were* insane, I think updating to something based on the very latest for FC3 (or RHEL4) would be the only workable approach. kernel-hugemem-2.6.9-1.9_FC2 (binary only) -- this one is just a holdover that didn't get cleaned up -- the kernel, as Dave Jones notes, is way past this now and no longer includes the hugemem patch at all. So, that really leaves mc and nfs-utils to worry about. Can someone shed some light on bug #133556? (Maybe mark unrestricted, since the debian update is already out?) libgnomeui we could maybe update, but unless someone can dig up more info on the mentioned crash and whether it's conceivably security related, we could probably leave it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Apr 12 04:45:46 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 00:45:46 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412035032.GA4571@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <425B04BA.2020106@comcast.net> <20050412035032.GA4571@jadzia.bu.edu> Message-ID: <20050412044546.GA7028@jadzia.bu.edu> On Mon, Apr 11, 2005 at 11:50:32PM -0400, Matthew Miller wrote: > nfs-utils-1.0.6-23: "Fixed some security issues found by SGI" -- > bug #133556, *** WHICH IS MARKED RESTRICTED *** > but doesn't appear to be addressed. I believe it's > . On further review, I think this *is* fixed in FC3, along with a few other things which didn't make it into FC2. See bug #138098. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Apr 12 13:38:20 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Apr 2005 09:38:20 -0400 Subject: FC2 mc testing update In-Reply-To: <1113311821.29405.45.camel@obelix.redhat.usu> References: <1113311821.29405.45.camel@obelix.redhat.usu> Message-ID: <20050412133820.GA12197@nostromo.devel.redhat.com> CC'ing fedora-legacy-list. Jindrich Novy (jnovy at redhat.com) said: > do you think it's still possible to make a final from testing FC2 update > even if FC2 is now moved to the fedora-legacy? I suppose if it's just moving test->final it's OK. Depends on what the legacy people think. Bill From pekkas at netcore.fi Tue Apr 12 14:14:26 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 12 Apr 2005 17:14:26 +0300 (EEST) Subject: so, we've got FC2 now... In-Reply-To: <20050411215804.GA25859@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> Message-ID: yOn Mon, 11 Apr 2005, Matthew Miller wrote: > (It would be really good if when this is created, it'd be "fc2" rather than > "core2", so that bugs can be easily transferred.) So.. Why do we want these bugs? If Fedora didn't fix them while they had the responsibility, they surely shouldn't be shorned in our direction either ? Maybe fc2 should be marked read-only (cannot report new bugs), and open new one, 'fc2-legacy'. Or something -- just to make the point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jnovy at redhat.com Tue Apr 12 14:23:20 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 12 Apr 2005 16:23:20 +0200 Subject: FC2 mc testing update In-Reply-To: <20050412133820.GA12197@nostromo.devel.redhat.com> References: <1113311821.29405.45.camel@obelix.redhat.usu> <20050412133820.GA12197@nostromo.devel.redhat.com> Message-ID: <1113315800.29405.67.camel@obelix.redhat.usu> On Tue, 2005-04-12 at 09:38 -0400, Bill Nottingham wrote: > CC'ing fedora-legacy-list. > > Jindrich Novy (jnovy at redhat.com) said: > > do you think it's still possible to make a final from testing FC2 update > > even if FC2 is now moved to the fedora-legacy? > > I suppose if it's just moving test->final it's OK. Depends on what > the legacy people think. The updated mc package introduces mc-4.6.1-pre3 to FC2 users and fixes several security vulnerabilities in the old mc so FC2 users won't be angry if the update will go to final, IMNSHO :) Cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From mattdm at mattdm.org Tue Apr 12 15:02:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 11:02:50 -0400 Subject: so, we've got FC2 now... In-Reply-To: References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> Message-ID: <20050412150250.GA21684@jadzia.bu.edu> On Tue, Apr 12, 2005 at 05:14:26PM +0300, Pekka Savola wrote: > So.. Why do we want these bugs? If Fedora didn't fix them while they > had the responsibility, they surely shouldn't be shorned in our > direction either ? Um, because some of them are security bugs that they never got around to fixing. That's kind of annoying (Fedora security process definitely seems to be disturbingly low priority -- see the perl-suid buffer overflow trivial root exploit, for example) but I don't really care whose responsibility it ought to be, since there are people who are depending on us to make available patches to secure their systems. I think all the non-security FC2 bugs should be closed as WONTFIX, with the note: "Fedora Core 2 is now maintained for security updates only by the Fedora Legacy project. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC4 test release, reopen and change the version to match." But I am a bit reluctant to do this to 1100+ bugs without some general agreement that this is a good idea. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cra at WPI.EDU Tue Apr 12 15:04:32 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 12 Apr 2005 11:04:32 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412150250.GA21684@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> Message-ID: <20050412150432.GM8833@angus.ind.WPI.EDU> On Tue, Apr 12, 2005 at 11:02:50AM -0400, Matthew Miller wrote: > "Fedora Core 2 is now maintained for security updates only by the Fedora > Legacy project. If this problem is a security issue, please reopen and > reassign to the Fedora Legacy product. If it is not a security issue and > hasn't been resolved in the current FC4 test release, reopen and change the > version to match." > > But I am a bit reluctant to do this to 1100+ bugs without some general > agreement that this is a good idea. Sounds like an excellent idea. From harri.haataja at smilehouse.com Tue Apr 12 15:40:18 2005 From: harri.haataja at smilehouse.com (Harri Haataja) Date: Tue, 12 Apr 2005 18:40:18 +0300 Subject: so, we've got FC2 now... In-Reply-To: <20050412150432.GM8833@angus.ind.WPI.EDU> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <20050412150432.GM8833@angus.ind.WPI.EDU> Message-ID: <20050412154017.GD24762@harriha-dsl.oulu.fi> On Tue, Apr 12, 2005 at 11:04:32AM -0400, Chuck R. Anderson wrote: > On Tue, Apr 12, 2005 at 11:02:50AM -0400, Matthew Miller wrote: > > "Fedora Core 2 is now maintained for security updates only by the > > Fedora Legacy project. If this problem is a security issue, please > > reopen and reassign to the Fedora Legacy product. If it is not a > > security issue and hasn't been resolved in the current FC4 test > > release, reopen and change the version to match." > > > > But I am a bit reluctant to do this to 1100+ bugs without some > > general agreement that this is a good idea. > > Sounds like an excellent idea. There also don't seem to be many alternatives. I believe that action would reflect what FL is supposed to provide and leave a fine description about it, too. -- I'm not going to have some reporters pawing through our papers. We are the president. -- Hillary Clinton commenting on the release of subpoenaed documents From rostetter at mail.utexas.edu Tue Apr 12 16:05:32 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 12 Apr 2005 11:05:32 -0500 Subject: so, we've got FC2 now... In-Reply-To: <20050412150250.GA21684@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> Message-ID: <1113321932.0ac1b67d2860d@mail.ph.utexas.edu> Quoting Matthew Miller : > On Tue, Apr 12, 2005 at 05:14:26PM +0300, Pekka Savola wrote: > > So.. Why do we want these bugs? If Fedora didn't fix them while they > > had the responsibility, they surely shouldn't be shorned in our > > direction either ? > > Um, because some of them are security bugs that they never got around to > fixing. That's kind of annoying (Fedora security process definitely seems to Exactly. > I think all the non-security FC2 bugs should be closed as WONTFIX, with the > note: > > "Fedora Core 2 is now maintained for security updates only by the Fedora > Legacy project. If this problem is a security issue, please reopen and > reassign to the Fedora Legacy product. If it is not a security issue and > hasn't been resolved in the current FC4 test release, reopen and change the > version to match." I agree 100% on this. Only exception might be if it is one of those packages in the testing stage, and we want to push it out after our own QA. But if it isn't security, and isn't already to the testing state, then mark it as WONTFIX. > But I am a bit reluctant to do this to 1100+ bugs without some general > agreement that this is a good idea. My opinion is that you are 100% correct in your thinking. FL is about security updates, period. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> -- Eric Rostetter From jkeating at j2solutions.net Tue Apr 12 17:18:41 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 12 Apr 2005 10:18:41 -0700 Subject: so, we've got FC2 now... In-Reply-To: <20050412150250.GA21684@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> Message-ID: <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-04-12 at 11:02 -0400, Matthew Miller wrote: > "Fedora Core 2 is now maintained for security updates only by the > Fedora > Legacy project. If this problem is a security issue, please reopen and > reassign to the Fedora Legacy product. If it is not a security issue > and > hasn't been resolved in the current FC4 test release, reopen and > change the > version to match." > Matt, I agree 100% with the above text. Please use this. -- 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 jkeating at j2solutions.net Tue Apr 12 17:19:36 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 12 Apr 2005 10:19:36 -0700 Subject: FC2 mc testing update In-Reply-To: <20050412133820.GA12197@nostromo.devel.redhat.com> References: <1113311821.29405.45.camel@obelix.redhat.usu> <20050412133820.GA12197@nostromo.devel.redhat.com> Message-ID: <1113326376.13504.39.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-04-12 at 09:38 -0400, Bill Nottingham wrote: > > I suppose if it's just moving test->final it's OK. Depends on what > the legacy people think. If there were no reported problems, I'm OK with publishing MC, however I'd like to do it within our build system, since I've already synced most of the content from RH systems. -- 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 mattdm at mattdm.org Tue Apr 12 17:20:43 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 13:20:43 -0400 Subject: a little bug triage... Message-ID: <20050412172043.GA26576@jadzia.bu.edu> A few bugs currently belonging to Fedora Legacy which I'm intending to close WONTFIX/NOTABUG: 152924 ? sk98lin driver drops udp packets [low priority, maybe wontfix] 152887 - wiki was spammed [should this be tracked in bugzilla, really?] 152858 ? up2date does not handle apt-mirror's ["don't do that"] 152823 ? up2date fails on legacy FC1 [can anyone reproduce?] 154486 ? Gftp can't download via SFTP with certain permissions ["oh well"] 152531 ? mysql doesn't restart after update [see comments: NOTABUG?] anyone think otherwise? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Apr 12 17:22:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 13:22:31 -0400 Subject: so, we've got FC2 now... In-Reply-To: <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050412172231.GB26576@jadzia.bu.edu> On Tue, Apr 12, 2005 at 10:18:41AM -0700, Jesse Keating wrote: > > "Fedora Core 2 is now maintained for security updates only by the Fedora > > Legacy project. If this problem is a security issue, please reopen and > > reassign to the Fedora Legacy product. If it is not a security issue and > > hasn't been resolved in the current FC4 test release, reopen and change > > the version to match." > Matt, I agree 100% with the above text. Please use this. Excellent. Will do this this evening unless someone stops me before then. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Tue Apr 12 17:24:01 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 12 Apr 2005 10:24:01 -0700 Subject: a little bug triage... In-Reply-To: <20050412172043.GA26576@jadzia.bu.edu> References: <20050412172043.GA26576@jadzia.bu.edu> Message-ID: <1113326641.13504.42.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-04-12 at 13:20 -0400, Matthew Miller wrote: > 152924 ? sk98lin driver drops udp packets [low priority, maybe > wontfix] Agreed, wontfix. Refile if a problem in FC3/4. > 152887 - wiki was spammed [should this be tracked in bugzilla, > really?] Close it, comment that looking to move to Fedoraproject.org wiki space. > 152858 ? up2date does not handle apt-mirror's ["don't do that"] Closed->NOTABUG > 152823 ? up2date fails on legacy FC1 [can anyone reproduce?] Closed->NEEDINFO > 154486 ? Gftp can't download via SFTP with certain permissions ["oh > well"] Closed->WONTFIX > 152531 ? mysql doesn't restart after update [see comments: NOTABUG?] Closed-NEEDINFO. Basically we need somebody to repro mysql dying after upgrading the package. The service isn't restarted by design, but if the old service dies because of the upgrade, that is bad. -- 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 dom at earth.li Tue Apr 12 17:31:10 2005 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 12 Apr 2005 18:31:10 +0100 Subject: New bugzilla status whiteboard / issues.txt Message-ID: <20050412173110.GJ24240@urchin.earth.li> Hi, I've transferred all the information from issues.txt into the status whiteboard at bugzilla.redhat.com. The tags I've used are as follows, they should all be self-explanatory: NEEDSWORK (retain from bugzilla.fedora.us) discussion publish-rhl73 publish-rhl9 publish-core1 publish-fc2 verify-rhl73 verify-rhl9 verify-core1 verify-fc2 needsbuild needsrelease Below is the current issues.txt with some useful links into bugzilla queries. If you have a bugzilla account you can store these within bugzilla and have them appear at the bottom of each page (look for "Remember Search"). If I get a spare moment I may get round to screescraping the site to continue to provide the email a summaries - has anyone done this sort of thing with bugzilla already? Cheers, $Id: issues.txt,v 1.211 2005/04/12 17:30:25 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- http://tinyurl.com/3jyy7 Packages waiting to be built for updates-testing ------------------------------------------------ http://tinyurl.com/6xorm Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ All verifies: http://tinyurl.com/7xjen RH73 verifies: http://tinyurl.com/626tk RH9 verifies: http://tinyurl.com/6tzjn FC1 verifies: http://tinyurl.com/4s2uv FC2 verifies: http://tinyurl.com/5u3ru Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- Discussion needed: http://tinyurl.com/4er3v Needs work: http://tinyurl.com/5lxlg New package: http://tinyurl.com/4wjss All publish: http://tinyurl.com/5hbjb RH73 publish: http://tinyurl.com/42fse RH9 publish: http://tinyurl.com/47gbp FC1 publish: http://tinyurl.com/5rcjx FC2 publish: http://tinyurl.com/4rzb3 Changes ------- I've removed the changelog as it contains little of interest. The full history of this file is available as an RCS file at: http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt,v -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From rostetter at mail.utexas.edu Tue Apr 12 17:45:21 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 12 Apr 2005 12:45:21 -0500 Subject: a little bug triage... In-Reply-To: <20050412172043.GA26576@jadzia.bu.edu> References: <20050412172043.GA26576@jadzia.bu.edu> Message-ID: <1113327921.da1a7f2c329ab@mail.ph.utexas.edu> Quoting Matthew Miller : > A few bugs currently belonging to Fedora Legacy which I'm intending to close > WONTFIX/NOTABUG: > > 152924 b From notting at redhat.com Tue Apr 12 17:47:26 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Apr 2005 13:47:26 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412172231.GB26576@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> Message-ID: <20050412174726.GB15617@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Excellent. Will do this this evening unless someone stops me before then. Wait, you're planning to close all the open FC2 bugs across all packages? Bill From rostetter at mail.utexas.edu Tue Apr 12 17:49:02 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 12 Apr 2005 12:49:02 -0500 Subject: a little bug triage... In-Reply-To: <1113326641.13504.42.camel@jkeating2.hq.pogolinux.com> References: <20050412172043.GA26576@jadzia.bu.edu> <1113326641.13504.42.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113328142.1395bc4434122@mail.ph.utexas.edu> Quoting Jesse Keating : > > 152531 ? mysql doesn't restart after update [see comments: NOTABUG?] > > Closed-NEEDINFO. Basically we need somebody to repro mysql dying after > upgrading the package. There were several accounts of this on the mailing list, no? > The service isn't restarted by design, but if My memory from all the mailing list traffic is that it is restarted by default, but fails to restart. Are you sure it isn't restarted by design? > the old service dies because of the upgrade, that is bad. Unless this is a different bug than I'm thinking of, the issue is that the upgrade causes mysql to stop functioning completely on many systems, and a manual start is needed to regain service. > -- > 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 > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From pekkas at netcore.fi Tue Apr 12 17:55:32 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 12 Apr 2005 20:55:32 +0300 (EEST) Subject: so, we've got FC2 now... In-Reply-To: <20050412150250.GA21684@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> Message-ID: On Tue, 12 Apr 2005, Matthew Miller wrote: > On Tue, Apr 12, 2005 at 05:14:26PM +0300, Pekka Savola wrote: >> So.. Why do we want these bugs? If Fedora didn't fix them while they >> had the responsibility, they surely shouldn't be shorned in our >> direction either ? > > Um, because some of them are security bugs that they never got around to > fixing. That's kind of annoying (Fedora security process definitely seems to > be disturbingly low priority -- see the perl-suid buffer overflow trivial > root exploit, for example) but I don't really care whose responsibility it > ought to be, since there are people who are depending on us to make > available patches to secure their systems. If Fedora didn't bother fixing security problems while they had the responsibility, I don't see why we should feel responsible either. Sure .. if we're producing an update in any case for RHL or FC1, we could add FC2, but if the problem is specific to FC2, IMHO it would be fine to just ignore the security bug. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Tue Apr 12 18:04:09 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 12 Apr 2005 11:04:09 -0700 Subject: a little bug triage... In-Reply-To: <1113328142.1395bc4434122@mail.ph.utexas.edu> References: <20050412172043.GA26576@jadzia.bu.edu> <1113326641.13504.42.camel@jkeating2.hq.pogolinux.com> <1113328142.1395bc4434122@mail.ph.utexas.edu> Message-ID: <1113329049.13504.50.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-04-12 at 12:49 -0500, Eric Rostetter wrote: > There were several accounts of this on the mailing list, no? I heard people SAYING it could, I didn't get anybody to repro the problem. > > The service isn't restarted by design, but if > > My memory from all the mailing list traffic is that it is restarted by > default, but fails to restart. Are you sure it isn't restarted by > design? Red Hat has stated that no services are restarted when upgrading. Thats just bad juju. > > the old service dies because of the upgrade, that is bad. > > Unless this is a different bug than I'm thinking of, the issue is that > the upgrade causes mysql to stop functioning completely on many > systems, > and a manual start is needed to regain service. Can any of you that possibly had this problem chime in? -- 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 mattdm at mattdm.org Tue Apr 12 18:08:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 14:08:39 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412174726.GB15617@nostromo.devel.redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> Message-ID: <20050412180839.GA27283@jadzia.bu.edu> On Tue, Apr 12, 2005 at 01:47:26PM -0400, Bill Nottingham wrote: > > Excellent. Will do this this evening unless someone stops me before then. > Wait, you're planning to close all the open FC2 bugs across all packages? Was planning, yeah, but I thought maybe someone would want to stop me so I didn't just go do it. :) I'll certainly wait if there should be more talking about this first. I think it's a good idea because otherwise bugzilla ends up a wasteland. I was intending to start with the low priority / low severity bugs first and then scrutinize the higher priority / severity ones more closely. (I already went through the ones marked as "security" by hand.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Apr 12 18:40:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 14:40:19 -0400 Subject: so, we've got FC2 now... In-Reply-To: References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> Message-ID: <20050412184019.GA29207@jadzia.bu.edu> On Tue, Apr 12, 2005 at 08:55:32PM +0300, Pekka Savola wrote: > >root exploit, for example) but I don't really care whose responsibility it > >ought to be, since there are people who are depending on us to make > >available patches to secure their systems. > If Fedora didn't bother fixing security problems while they had the > responsibility, I don't see why we should feel responsible either. I don't really care whose responsibility it ought to be, since there are people who are depending on us to make available patches to secure their systems. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Tue Apr 12 18:43:06 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Apr 2005 14:43:06 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412180839.GA27283@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> <20050412180839.GA27283@jadzia.bu.edu> Message-ID: <20050412184305.GI28569@redhat.com> On Tue, Apr 12, 2005 at 02:08:39PM -0400, Matthew Miller wrote: > On Tue, Apr 12, 2005 at 01:47:26PM -0400, Bill Nottingham wrote: > > > Excellent. Will do this this evening unless someone stops me before then. > > Wait, you're planning to close all the open FC2 bugs across all packages? > > Was planning, yeah, but I thought maybe someone would want to stop me so I > didn't just go do it. :) > > I'll certainly wait if there should be more talking about this first. I > think it's a good idea because otherwise bugzilla ends up a wasteland. > > I was intending to start with the low priority / low severity bugs first and > then scrutinize the higher priority / severity ones more closely. (I already > went through the ones marked as "security" by hand.) The biggest problem with the severity field is that its user-visible. This means we get way too many users filing bugs as 'high' or even 'security' hoping that it means the bug gets fixed faster. Some package owners go through and reset the priority to 'low' as they go through these bugs. I gave up doing that for kernel bugs after users started setting them back to high for no reason again. As it stands the field is pretty useless. Dave From mattdm at mattdm.org Tue Apr 12 20:21:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 16:21:09 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412184305.GI28569@redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> <20050412180839.GA27283@jadzia.bu.edu> <20050412184305.GI28569@redhat.com> Message-ID: <20050412202109.GA31982@jadzia.bu.edu> On Tue, Apr 12, 2005 at 02:43:06PM -0400, Dave Jones wrote: > The biggest problem with the severity field is that its user-visible. I think user-visible is fine. It'd be nice if it weren't user-*changable*. Also, it's hard for people to understand the distinction between priority (that is, urgency) and severity (importance). Sometimes important things end up needing to be lower priority, and that's not a slight against the bug request. Anyway, in this particular case, I figured it'd make triage a bit quicker, since one can generally trust that "low" really means it. [...] > As it stands the field is pretty useless. Making them settable only by the bug assignee or other privileged bugzilla users is probably worthwhile. I think upstream bugzilla 2.18 actually has this as an option already. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Tue Apr 12 21:24:31 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 12 Apr 2005 16:24:31 -0500 Subject: mysql-server In-Reply-To: <1112303958.c220b493ddc97@mail.ph.utexas.edu> References: <009701c53545$137b7240$7202a8c0@ccb2vpjza> <1112303958.c220b493ddc97@mail.ph.utexas.edu> Message-ID: <1113341071.5badb90e06606@mail.ph.utexas.edu> Quoting Eric Rostetter : > Quoting "Pettit, Paul" : > > > The documentation however will need to be changed. I'm working on that > > and will try and edit it once I figure out wiki (never used it before). > > Since the wiki is down, I created a doc at > > http://www.fedoralegacy.org/docs/autoupdates.php > > as a starting point to addressing these issues. Comments, feedback, better > docs, changes, etc. all welcome. Since not a soul has said a word about the doc above in 2 weeks, and because no one else has posted any other docs, comments, suggestions, or wiki pages, I've gone ahead and modified the yum docs to refer to the above autoupdates.php page. Have to love the participation here; people are happy to join in a flame war, but no one participates when asked for input or contributions... Yeah, that's supposed to be sarcasm... -- Eric Rostetter From mattdm at mattdm.org Tue Apr 12 21:35:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 17:35:13 -0400 Subject: mysql-server In-Reply-To: <1113341071.5badb90e06606@mail.ph.utexas.edu> References: <009701c53545$137b7240$7202a8c0@ccb2vpjza> <1112303958.c220b493ddc97@mail.ph.utexas.edu> <1113341071.5badb90e06606@mail.ph.utexas.edu> Message-ID: <20050412213513.GA2772@jadzia.bu.edu> On Tue, Apr 12, 2005 at 04:24:31PM -0500, Eric Rostetter wrote: > > http://www.fedoralegacy.org/docs/autoupdates.php > Since not a soul has said a word about the doc above in 2 weeks, and > because no one else has posted any other docs, comments, suggestions, or > wiki pages, I've gone ahead and modified the yum docs to refer to the > above autoupdates.php page. Seems basically good. > Have to love the participation here; people are happy to join in a > flame war, but no one participates when asked for input or contributions... > Yeah, that's supposed to be sarcasm... Lack of time; flamewars are good procrastination fodder, but doing actual work isn't. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Apr 12 22:11:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 18:11:58 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412174726.GB15617@nostromo.devel.redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> Message-ID: <20050412221158.GA4710@jadzia.bu.edu> On Tue, Apr 12, 2005 at 01:47:26PM -0400, Bill Nottingham wrote: > > Excellent. Will do this this evening unless someone stops me before then. > Wait, you're planning to close all the open FC2 bugs across all packages? Okay, so I'm not going to do this until I can get clarification on why this might not be a good idea. I guess partly it depends on what exactly it means for a release to be transferred to Fedora Legacy. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ismanager at ccbnpts.com Tue Apr 12 22:35:25 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Tue, 12 Apr 2005 17:35:25 -0500 Subject: mysql-server In-Reply-To: <1113341071.5badb90e06606@mail.ph.utexas.edu> Message-ID: <003901c53faf$ebe139c0$7202a8c0@ccb2vpjza> > Eric Rostetter > > Quoting Eric Rostetter : > > > Quoting "Pettit, Paul" : > > > > > The documentation however will need to be changed. I'm > working on that > > > and will try and edit it once I figure out wiki (never > used it before). > > > > Since the wiki is down, I created a doc at > > > > http://www.fedoralegacy.org/docs/autoupdates.php > > > > as a starting point to addressing these issues. Comments, > feedback, better > > docs, changes, etc. all welcome. > > Since not a soul has said a word about the doc above in 2 weeks, and > because no one else has posted any other docs, comments, > suggestions, or > wiki pages, I've gone ahead and modified the yum docs to refer to the > above autoupdates.php page. > Sorry, I had no comments to make. The document looked fine to me. Though I disagree with the "don't use auto-update" as a general policy at least the document gave examples of when you should consider not using the auto-update function (almost never in a production environment from your guide). Hope you weren't waiting on just me to comment but it seems you were, my bad. > Have to love the participation here; people are happy to join in a > flame war, but no one participates when asked for input or > contributions... > Yeah, that's supposed to be sarcasm... > > -- > Eric Rostetter > -- I had been waiting for the wiki to become available again, guess it's not going to happen. Too bad as I really want to help but find that there is no way to do that currently. As for posting comments, corrections, documentation edits here ... well ... we've seen how well that has worked in the past. Yeah, that's sarcasm too ... Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From ismanager at ccbnpts.com Tue Apr 12 22:48:19 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Tue, 12 Apr 2005 17:48:19 -0500 Subject: mysql-server In-Reply-To: <20050412213513.GA2772@jadzia.bu.edu> Message-ID: <003a01c53fb1$b904ada0$7202a8c0@ccb2vpjza> > Matthew Miller > > On Tue, Apr 12, 2005 at 04:24:31PM -0500, Eric Rostetter wrote: > > Have to love the participation here; people are happy to join in a > > flame war, but no one participates when asked for input or > contributions... > > Yeah, that's supposed to be sarcasm... > > Lack of time; flamewars are good procrastination fodder, but > doing actual > work isn't. :) > > -- > Matthew Miller mattdm at mattdm.org Or actual work and the fact that there was no good way to make a contribution to the documents might have been factor. Nah. Or maybe one got tired of being called stupid and let the ball pass to others. Since I was a sole minority in this discussion, I just didn't feel my input would be viewed with any merit or that I would be taken seriously. You call it "procrastination", I call it a tactical withdrawl ... To each their own. Can we just call it now and move on? Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From ismanager at ccbnpts.com Tue Apr 12 23:00:54 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Tue, 12 Apr 2005 18:00:54 -0500 Subject: a little bug triage... In-Reply-To: <1113329049.13504.50.camel@jkeating2.hq.pogolinux.com> Message-ID: <003d01c53fb3$7ae96860$7202a8c0@ccb2vpjza> > Jesse Keating > > On Tue, 2005-04-12 at 12:49 -0500, Eric Rostetter wrote: > > > > the old service dies because of the upgrade, that is bad. > > > > Unless this is a different bug than I'm thinking of, the > issue is that > > the upgrade causes mysql to stop functioning completely on many > > systems, > > and a manual start is needed to regain service. > > Can any of you that possibly had this problem chime in? > I had this problem. A few others did too. It seems to me that if RH's stand that an upgrade doesn't (or shouldn't?) restart a service then the mySQL upgrade is stoping a service improperly. I've done many a upgrade to mySQL via RPM and when 'manually' done the service remains running until it's restarted via 'service mysqld restart'. So maybe the bug in the mysql update is that it stops the service, not that it fails to restart it. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From mattdm at mattdm.org Tue Apr 12 23:09:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 19:09:57 -0400 Subject: mysql-server In-Reply-To: <003a01c53fb1$b904ada0$7202a8c0@ccb2vpjza> References: <20050412213513.GA2772@jadzia.bu.edu> <003a01c53fb1$b904ada0$7202a8c0@ccb2vpjza> Message-ID: <20050412230957.GA8529@jadzia.bu.edu> On Tue, Apr 12, 2005 at 05:48:19PM -0500, Pettit, Paul wrote: > Or maybe one got tired of being called stupid and let the ball pass to > others. Since I was a sole minority in this discussion, I just didn't feel Err, maybe. Sorry, I was just jumping in and didn't know there was a sore spot. Sorry if I landed on something I didn't mean to. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Tue Apr 12 23:27:21 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 12 Apr 2005 16:27:21 -0700 Subject: a little bug triage... In-Reply-To: <003d01c53fb3$7ae96860$7202a8c0@ccb2vpjza> References: <003d01c53fb3$7ae96860$7202a8c0@ccb2vpjza> Message-ID: <1113348441.13504.74.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-04-12 at 18:00 -0500, Pettit, Paul wrote: > I had this problem. A few others did too. > > It seems to me that if RH's stand that an upgrade doesn't (or > shouldn't?) > restart a service then the mySQL upgrade is stoping a service > improperly. > I've done many a upgrade to mySQL via RPM and when 'manually' done the > service remains running until it's restarted via 'service mysqld > restart'. > > So maybe the bug in the mysql update is that it stops the service, not > that > it fails to restart it. Do you have the capability of reproducing this in a closed environment? Install up to a certain point, then -Uvh our update package and see what happens to the service? Quite honestly we don't touch any part of that in the spec, we just make sure the new source goes in OK. -- 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 mattdm at mattdm.org Tue Apr 12 23:52:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 19:52:59 -0400 Subject: bugs per distro version? Message-ID: <20050412235259.GA11672@jadzia.bu.edu> We talked about this a little while ago ("state of bugzilla" thread), but since I'm all inspired, I thought I'd bring it up again. I find the status whiteboard thing useful for some things, but difficult for keeping straight what vulnerabilities apply to and are in what state for different distribution versions. In the future, I think it'd be nice if issues which affect multiple supported releases each got their own bug. This'd make it easier to track the various states of each without having the potential of a problem with a RHL7.3 update holding up a known-good FC2 one (or vice versa). How do other people feel about this? (I'm willing to tackle some of the bugzilla-tending overhead which this might add.) If everyone hates it, though, I can learn to live with the whiteboard. I don't suggest messing with the existing version=unspecified bugs -- I think that'd just create extra work. But if people *are* okay with this idea, I would like to create FC2 "clone" bugs for existing unspecifed or rhl9/rhl73 bugs which also affect FC2. Thoughts? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Wed Apr 13 00:59:26 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Apr 2005 20:59:26 -0400 Subject: bugs per distro version? In-Reply-To: <20050412235259.GA11672@jadzia.bu.edu> References: <20050412235259.GA11672@jadzia.bu.edu> Message-ID: <20050413005926.GC18611@redhat.com> On Tue, Apr 12, 2005 at 07:52:59PM -0400, Matthew Miller wrote: > We talked about this a little while ago ("state of bugzilla" thread), but > since I'm all inspired, I thought I'd bring it up again. > > I find the status whiteboard thing useful for some things, but difficult for > keeping straight what vulnerabilities apply to and are in what state for > different distribution versions. > > In the future, I think it'd be nice if issues which affect multiple > supported releases each got their own bug. This'd make it easier to track > the various states of each without having the potential of a problem with a > RHL7.3 update holding up a known-good FC2 one (or vice versa). FWIW, our security team does that too. It drove me nuts at first (given that FC2/FC3 were the same codebase for the longest part) but it definitly made sense from a tracking point of view. With bugzillas 'clone as bug' feature, its now a lot less painful than it used to be to enter bugs across multiple releases. Dave From notting at redhat.com Wed Apr 13 02:54:04 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Apr 2005 22:54:04 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050412221158.GA4710@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> <20050412221158.GA4710@jadzia.bu.edu> Message-ID: <20050413025404.GA18709@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Tue, Apr 12, 2005 at 01:47:26PM -0400, Bill Nottingham wrote: > > > Excellent. Will do this this evening unless someone stops me before then. > > Wait, you're planning to close all the open FC2 bugs across all packages? > > Okay, so I'm not going to do this until I can get clarification on why this > might not be a good idea. > > I guess partly it depends on what exactly it means for a release to be > transferred to Fedora Legacy. Well, it's just that for some of the stuff I maintain, bugzilla.redhat.com is effectively the *upstream* bugzilla. Hence, I'm not sure blanket closing of them is the right thing to do in this case. Bill From mattdm at mattdm.org Wed Apr 13 03:38:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 23:38:15 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050413025404.GA18709@nostromo.devel.redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> <20050412221158.GA4710@jadzia.bu.edu> <20050413025404.GA18709@nostromo.devel.redhat.com> Message-ID: <20050413033815.GA19512@jadzia.bu.edu> On Tue, Apr 12, 2005 at 10:54:04PM -0400, Bill Nottingham wrote: > > I guess partly it depends on what exactly it means for a release to be > > transferred to Fedora Legacy. > Well, it's just that for some of the stuff I maintain, bugzilla.redhat.com > is effectively the *upstream* bugzilla. Hence, I'm not sure blanket > closing of them is the right thing to do in this case. That's understandable, and I imagine it's also the case with some other RH developers. For what it's worth, you've got 46 FC2 bugs assigned to you in state NEW, mostly in initscripts and kudzu. How about blanket NEEDINFOing them for a while? The idea is that things which are legitimate issues would get moved to their proper place. It seems like it might not be so bad to have all of these reviewed -- but I understand not dumping it on you when it's not the best time. But then, when *is* the best time? I would have preferred you guys to keep up FC2 support for another year. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Wed Apr 13 15:53:48 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 10:53:48 -0500 Subject: mysql-server In-Reply-To: <003901c53faf$ebe139c0$7202a8c0@ccb2vpjza> References: <003901c53faf$ebe139c0$7202a8c0@ccb2vpjza> Message-ID: <1113407628.87eb0c967b0ef@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > > Since not a soul has said a word about the doc above in 2 weeks, and > > because no one else has posted any other docs, comments, > > suggestions, or > > wiki pages, I've gone ahead and modified the yum docs to refer to the > > above autoupdates.php page. > > > > Sorry, I had no comments to make. The document looked fine to me. Though I Good to hear. > disagree with the "don't use auto-update" as a general policy at least the > document gave examples of when you should consider not using the auto-update > function (almost never in a production environment from your guide). Yes, this is standard best practices. See the links to Microsoft's Best Practices and the other site link I gave in an e-mail two weeks ago about this. They all agree: Best Practices dictate you don't use auto-updates from vendors on your production machines. > Hope you weren't waiting on just me to comment but it seems you were, my > bad. No, I was hoping multiple people would comment. I was not just waiting for you as far as comments go. I was waiting to see if you wrote up something like you said you would in an email. Never heard back on that either. But certainly in any case it was not just you I was waiting for. I was hoping to get feedback from at least several people. > I had been waiting for the wiki to become available again, guess it's not > going to happen. Too bad as I really want to help but find that there is no > way to do that currently. Yes. The wiki is sometimes available, sometimes not. Amazingly it was up enough for the spammers to get in again and deface it with links (I fixed that yesterday). But I know it is frustrating; more than once I've had it go south on me while I was using it. Since it isn't stable, I'm hoping Jesse will get it migrated to a new (more stable, secure) location asap. But not sure what if any progress is going on with that. > As for posting comments, corrections, documentation edits here ... well ... > we've seen how well that has worked in the past. Very well actually. At least 75% of the docs on the web site came from people posting them to the mailing list. > Yeah, that's sarcasm too ... Yes, but I feel you have a negative view of the list for no valid reason. It does work, if you let it. [Rest of what I would say here deleted to avoid another flame war] > Paul Pettit > CTO and IS Manager > Consistent Computer Bargains Inc. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 13 16:16:01 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 11:16:01 -0500 Subject: mysql-server In-Reply-To: <003a01c53fb1$b904ada0$7202a8c0@ccb2vpjza> References: <003a01c53fb1$b904ada0$7202a8c0@ccb2vpjza> Message-ID: <1113408961.9595bce9e9b11@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > Or actual work and the fact that there was no good way to make a > contribution to the documents might have been factor. There are good ways to contribute. I admit the wiki was a problem, but there are other ways. > Or maybe one got tired of being called stupid and let the ball pass to > others. Since I was a sole minority in this discussion, I just didn't feel > my input would be viewed with any merit or that I would be taken seriously. Problem was you were taken seriously, but you didn't take the discussions you started, or the replies you received, seriously. > Can we just call it now and move on? If you are happy with what I did to the documentation, don't want any further changes, and have found a solution that works for you, then there is no reason to pursue this further. > Paul Pettit -- Eric Rostetter From ismanager at ccbnpts.com Wed Apr 13 16:23:09 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Wed, 13 Apr 2005 11:23:09 -0500 Subject: a little bug triage... In-Reply-To: <1113348441.13504.74.camel@jkeating2.hq.pogolinux.com> Message-ID: <005a01c54045$15107b90$7202a8c0@ccb2vpjza> > Jesse Keating > > On Tue, 2005-04-12 at 18:00 -0500, Pettit, Paul wrote: > > I had this problem. A few others did too. > > > > It seems to me that if RH's stand that an upgrade doesn't (or > > shouldn't?) > > restart a service then the mySQL upgrade is stoping a service > > improperly. > > I've done many a upgrade to mySQL via RPM and when > 'manually' done the > > service remains running until it's restarted via 'service mysqld > > restart'. > > > > So maybe the bug in the mysql update is that it stops the > service, not > > that > > it fails to restart it. > > Do you have the capability of reproducing this in a closed > environment? > Install up to a certain point, then -Uvh our update package > and see what > happens to the service? Quite honestly we don't touch any > part of that > in the spec, we just make sure the new source goes in OK. > > -- > Jesse Keating RHCE (geek.j2solutions.net) I think I should be able to. I have a few spare boxes around here that would fit the bill for a quick install + update test. Just have to dig them out. :P Give me some time, I'll see what I can do. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From jkeating at j2solutions.net Wed Apr 13 17:22:41 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 13 Apr 2005 10:22:41 -0700 Subject: a little bug triage... In-Reply-To: <005a01c54045$15107b90$7202a8c0@ccb2vpjza> References: <005a01c54045$15107b90$7202a8c0@ccb2vpjza> Message-ID: <1113412961.13504.112.camel@jkeating2.hq.pogolinux.com> On Wed, 2005-04-13 at 11:23 -0500, Pettit, Paul wrote: > > I think I should be able to. I have a few spare boxes around here that > would > fit the bill for a quick install + update test. Just have to dig them > out. > :P > > Give me some time, I'll see what I can do. Thanks, I really appreciate it. -- 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 jkeating at j2solutions.net Wed Apr 13 17:25:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 13 Apr 2005 10:25:51 -0700 Subject: mysql-server In-Reply-To: <1113407628.87eb0c967b0ef@mail.ph.utexas.edu> References: <003901c53faf$ebe139c0$7202a8c0@ccb2vpjza> <1113407628.87eb0c967b0ef@mail.ph.utexas.edu> Message-ID: <1113413151.13504.115.camel@jkeating2.hq.pogolinux.com> On Wed, 2005-04-13 at 10:53 -0500, Eric Rostetter wrote: > Yes. The wiki is sometimes available, sometimes not. Amazingly it > was > up enough for the spammers to get in again and deface it with links (I > fixed > that yesterday). But I know it is frustrating; more than once I've > had it > go south on me while I was using it. > > Since it isn't stable, I'm hoping Jesse will get it migrated to a new > (more stable, secure) location asap. But not sure what if any > progress > is going on with that. A lot of this problem was that another service was using the mysql daemon on that system, and that service went haywire over the last couple weeks, driving the box load average up to the 90s. Yes that is 9 0, 90. I've since killed that service and our loads are quite saner, and the mysql daemon won't be restarted so violently anymore. This still doesn't disrupt my desire to move to the Fedora wiki space. -- 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 walrus at bellsouth.net Wed Apr 13 17:29:57 2005 From: walrus at bellsouth.net (William M. Quarles) Date: Wed, 13 Apr 2005 13:29:57 -0400 Subject: Preventing spammers from infiltrating the Red Hat mailing lists Message-ID: Hi all, I sent what I thought was a very important request to one of the Fedora lists which was quickly beaten down, and I did not receive anything back on subsequent replies. I would appreciate your help in making sure that the lists are safe for all of us. I'm actually going to the trouble of subscribing to nearly all of the Red Hat mailing lists just to get the word out. One thing that I have done recently was to search for my e-mail addresses on the Internet web pages to find all of the places that list them. Why bother doing this? Just like how Google has spiders that crawl the Internet to gather general information, spammers have spiders that crawl the Internet to gather e-mail addresses to spam people. I have contacted all of the websites who did not modify my e-mail addresses (mostly on mailing lists) in such that they cannot be collected. Red Hat has done at least one thing right in that they have modified everyone's e-mail address in their web archive, such that it reads something like for mine. However Red Hat has left one big gaping whole that the spam spiders can still crawl into. There is a complete active mirror of these lists as postable newsgroups kept on a service called Gmane . I'm using Gmane to write this message to you now. It's a pretty sophisticated setup, has safeguards to prevent spam getting posted, and they use Spam Assassin to clean up stuff that still ends up on the list (except you have to filter it yourself on the newsgroup interface). The only problem is that spam spiders crawl the newsgroups to collect e-mail addresses. Gmane has a safeguard to prevent this, but it has to be turned on by the list administrator. Gmane can encrypt the e-mail addresses on the list such that any mail sent to them is routed through Gmane first, and then the sender must under go a challenge-response before the message gets routed to the actual recipient. Of all of the Red Hat lists I've only found two newsgroup mirrors that use address encryption: gmane.linux.redhat.fedora.java , and gmane.redhat.taroon . If you would like to see the Red Hat newsgroup mirrors have encrypted e-mail addresses, please reply to this topic and discuss. If you are even more brave (important since some of these lists are high-volume and not everything gets read), please contact your list administrator directly at . If someone knows how to get the word out on the international lists or to their administrators (since I don't speak multiple tongues), please do so. If someone knows who to contact who can make all of the newsgroups have encrypted e-mail addresses going above all of the list administrators (maybe the person who decided to obfuscate them all on the web archive?) please contact him or her and let us know how to contact that person. Thanks so much, William From ismanager at ccbnpts.com Wed Apr 13 18:26:26 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Wed, 13 Apr 2005 13:26:26 -0500 Subject: mysql-server In-Reply-To: <1113408961.9595bce9e9b11@mail.ph.utexas.edu> Message-ID: <008301c54056$4e279830$7202a8c0@ccb2vpjza> > Eric Rostetter wrote: > > Quoting "Pettit, Paul" : > > > Or actual work and the fact that there was no good way to make a > > contribution to the documents might have been factor. > > There are good ways to contribute. I admit the wiki was a > problem, but > there are other ways. > The "other ways" is this list AFAIK and since I had already been reamed for voicing my opinion on scheduled vs. un-scheduled (/ asap) updates that left ... Ummm ... No other outlet. Feel free to correct me if I've missed something. > > Or maybe one got tired of being called stupid and let the > ball pass to > > others. Since I was a sole minority in this discussion, I > just didn't feel > > my input would be viewed with any merit or that I would be > taken seriously. > > Problem was you were taken seriously, but you didn't take the > discussions > you started, or the replies you received, seriously. > Maybe in your opinion I didn't. Later in the discussion I conceeded that I had not taken the global part of FL into account. I also noted that because of the global issue that a local solution to the problem was probably best. This also was based on other's input in the discussion. So it would seem I was taking other's input seriously but maybe I just wasn't giving your input the same weight. > > Can we just call it now and move on? > > If you are happy with what I did to the documentation, don't > want any further > changes, and have found a solution that works for you, then > there is no > reason to pursue this further. > > -- > Eric Rostetter > The future is is not a set thing (IMHO) so if your looking for a "you said" card to prevent me from coming back to this then I can't help you. I will say that the page is well done and covers all that was discussed here in regards to auto-updating and it's danger in regards to FL updates when used on production machines. There are two best practice issues 1) that you should patch critical bugs (i.e. security issues) asap and 2) that you should not rely in auto-updating because update packages need to be evaluated regardless of what testing was done prior to release. Those points were not covered prior to your additions but now are. Well done. My original opinion, however, on the subject of FL update release timing has not changed. Even though now I know and accept that there is nothing FL management can do, because of the nature of the community, I still wish there was. I feel that updates should be released on a more scheduled basis but with the mydrid of TZ and holidays through out the world it's too complex an issue for FL to deal with. I can live with that as there are work arounds based on local coding / cron editing (some detailed in your document) as discussed by myself and others. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From ismanager at ccbnpts.com Wed Apr 13 19:10:07 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Wed, 13 Apr 2005 14:10:07 -0500 Subject: mysql-server In-Reply-To: <1113407628.87eb0c967b0ef@mail.ph.utexas.edu> Message-ID: <008c01c5405c$67fadd70$7202a8c0@ccb2vpjza> > Eric Rostetter wrote: > > Quoting "Pettit, Paul" : > > > disagree with the "don't use auto-update" as a general > policy at least the > > document gave examples of when you should consider not > using the auto-update > > function (almost never in a production environment from your guide). > > Yes, this is standard best practices. See the links to Microsoft's > Best Practices and the other site link I gave in an e-mail two weeks > ago about this. They all agree: Best Practices dictate you don't use > auto-updates from vendors on your production machines. > I've read (and now re-read) the MS document, the other one I couldn't open for some reason. I disagree that is what the MS document says on security updates but YMMV. I was going to go into another discourse on best practices and how the real world works but it's not worth it. > > Hope you weren't waiting on just me to comment but it seems > you were, my > > bad. > > No, I was hoping multiple people would comment. I was not > just waiting for > you as far as comments go. > > I was waiting to see if you wrote up something like you said > you would in > an email. Never heard back on that either. But certainly in > any case it > was not just you I was waiting for. I was hoping to get feedback from > at least several people. > I decided that writing up anything at the time would have been a) circular filed by you or whoever got it, b) would not have been very objective and c) your page covered all the important parts of auto-updating and the risks involved. So I moved on. > > I had been waiting for the wiki to become available again, > guess it's not > > going to happen. Too bad as I really want to help but find > that there is no > > way to do that currently. > > Yes. The wiki is sometimes available, sometimes not. > Amazingly it was > up enough for the spammers to get in again and deface it with > links (I fixed > that yesterday). But I know it is frustrating; more than > once I've had it > go south on me while I was using it. > > Since it isn't stable, I'm hoping Jesse will get it migrated to a new > (more stable, secure) location asap. But not sure what if > any progress > is going on with that. > I'll look forward to that day then. > > As for posting comments, corrections, documentation edits > here ... well ... > > we've seen how well that has worked in the past. > > Very well actually. At least 75% of the docs on the web site > came from > people posting them to the mailing list. > > > Yeah, that's sarcasm too ... > > Yes, but I feel you have a negative view of the list for no > valid reason. > It does work, if you let it. > > [Rest of what I would say here deleted to avoid another flame war] > > -- > Eric Rostetter > > -- Right now I'm just going to go back to lurking (save that test I need to do) as it's the safest thing to do right now. You have the keys to the car (or at least one set) and if I or anyone should say "it might be best to turn left" and you turn right we all are just along for the ride. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From rostetter at mail.utexas.edu Wed Apr 13 19:20:45 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 14:20:45 -0500 Subject: mysql-server In-Reply-To: <008301c54056$4e279830$7202a8c0@ccb2vpjza> References: <008301c54056$4e279830$7202a8c0@ccb2vpjza> Message-ID: <1113420045.a013dde23d9d4@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > The "other ways" is this list AFAIK and since I had already been reamed for > voicing my opinion on scheduled vs. un-scheduled (/ asap) updates that left > ... Ummm ... No other outlet. Other ways could be communication on the list, posting completed documentation to the list, e-mailing completed documentation to someone in the project with power to install it on the web server, asking for a position in the group in which you could directly work on the web site, posting to another wiki somewhere instead of the FL wiki, etc. The limit is your imagination and willingness to put forth the effort. > Feel free to correct me if I've missed something. Well, I don't think posting to the list is such a bad thing, but your opinion differs. > > > Can we just call it now and move on? > > > > If you are happy with what I did to the documentation, don't > > want any further > > changes, and have found a solution that works for you, then > > there is no > > reason to pursue this further. > > > > -- > > Eric Rostetter > > > > The future is is not a set thing (IMHO) so if your looking for a "you said" > card to prevent me from coming back to this then I can't help you. I'm looking for no such card. I'm just saying, if no one has an issue with this anymore, then it can be dropped. If someone still has an issue with it (and makes that known) then it shouldn't be dropped. If it is dropped now, it can always be raised again in the future should the need or desire arise. Anyway, unless someone re-opens the topic I'll consider it dead. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 13 19:46:08 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 14:46:08 -0500 Subject: mysql-server In-Reply-To: <008c01c5405c$67fadd70$7202a8c0@ccb2vpjza> References: <008c01c5405c$67fadd70$7202a8c0@ccb2vpjza> Message-ID: <1113421568.324c7198efa09@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > I've read (and now re-read) the MS document, the other one I couldn't open > for some reason. I disagree that is what the MS document says on security > updates but YMMV. How can you disagree with it. Some excepts are: "The majority of security updates released are for client side (often browser) issues. They may or may not be relevant to a server installation. Evaluate the update, if it's needed, then apply it. If not, assess the risk of applying or not." "You should never be worse off by implementing a service pack, hotfix and security patch. If you are unsure, then take steps to ensure that there is no doubt when moving them to production systems." "Before applying any service pack, hotfix or security patch, all relevant documentation should be read and peer reviewed. The peer review process is critical as it mitigates the risk of a single person missing critical and relevant points when evaluating the update." "All updates, regardless of their type (whether they are service packs, hotfixes or security patches), are to be applied on an "as-needed" basis. They need to be evaluated individually and treated as important optional updates." "Service packs and hotfixes must be tested on a representative non-production environment prior to being deployed to production. This will help to gauge the impact of such changes." "If all tests in the lab environment are successful, start deploying on non-critical servers first, if possible, and then move to the primary servers once the service pack has been in production for 10-14 days." I fail to see how you can comply with any of the above if you do un-attended automatic updates on your production machines. The above dictate that you can not do unattended, automatic updates on production machines. And they are just a small sampling of the paper, which contains many other statements against automated installation of updates. > I was going to go into another discourse on best practices and how the real > world works but it's not worth it. It is up to you to decide if it is worth your time or not to participate. But I don't see how you can possibly make an argument for unattended, automatic updates on a production machine for which you don't want unplanned downtime. This goes against everything I've ever heard or been taught about IT Best Practices from any source. > I decided that writing up anything at the time would have been a) circular > filed by you or whoever got it, I have never done that to a single thing you've wrote. In fact, I've responded to most of your postings (unless I knew someone else had replied to it before I could). > b) would not have been very objective That is something only you can comment on. > and c) > your page covered all the important parts of auto-updating and the risks > involved. So I moved on. Okay. > Right now I'm just going to go back to lurking (save that test I need to do) > as it's the safest thing to do right now. Which is also the surest way to make sure FL doesn't improve. If everyone lurks, nothing will get done, and FL will fail. But you do have the right to do so; if you want to be a lurker, you have that right. > You have the keys to the car (or at least one set) and if I or anyone should > say "it might be best to turn left" and you turn right we all are just along > for the ride. Exactly, for both you and me. > Paul Pettit -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 13 20:42:57 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 15:42:57 -0500 Subject: [RFC] Legacy documentation In-Reply-To: <1112748548.14163.5.camel@erato.phig.org> References: <1112748548.14163.5.camel@erato.phig.org> Message-ID: <1113424977.befe6578be314@mail.ph.utexas.edu> Quoting Karsten Wade : > I'm hoping you are interested in taking over some documentation. Not much response yet, so I'll join in. > We have a few documents that are FC2 specific and are going to be > orphaned when FC2 moves over to the Legacy Project. The Docs Project > (FDP) follows the Fedora Core release and maintenance schedule, meaning > when a version of Core goes to the Legacy Project, the docs should go > with it. Okay. Didn't have anyone formally say this until now. Good to know. > Keeping Up to Date (FC2) > http://fedora.redhat.com/docs/updates/ > We're likely to update this for FC4, if a writer pops up wanting it. Fedora Legacy (FL) has its own docs for this topic, so I'd rather not move this to FL really. But it would be worth us giving this a glance, and seeing if we should include any of it in our documentation... So, I'd say this is a Fedora doc, and doesn't need to be moved to FL. > Fedora Jargon Buster > > http://fedora.redhat.com/docs/jargon-buster/ > > This was written originally under FC1. It may not be out of date, > but it hasn't been updated in six months. This seems to be mostly version independent, and could be made version independent without much work. I'd say this should stay at Fedora docs, and FL should probably link to it for reference. So, again, I'd say this is a Fedora doc, and doesn't need to be moved to FL. > Package List for Fedora Core 2 > http://fedora.redhat.com/docs/package-list/fc2/ > > I don't know anything about this or its value. We could archive these at FL if Fedora Project wanted us to. We've discussed but not done anything about setting up an "archive area" for such things as this and release notes, etc. If you want us to take this over, just say so, and we will. > Release notes for FC2 > > http://fedora.redhat.com/docs/release-notes/fc2/x86/ > http://fedora.redhat.com/docs/release-notes/fc2/x86_64/ > > Not sure that you'd ever want to update them, and we can certainly > leave them in place. For relnotes in particular it's a good thing to > keep old ones around. Same as above. We can archive them if you want. Just let us know. > Fedora Core 2 SELinux FAQ > > http://fedora.redhat.com/docs/selinux-faq-fc2/ > > SELinux had a breakdown in updates to FC2, and this FAQ says at the > top to upgrade to FC3. However, if anyone is trying to work with > SELinux in FC2, this FAQ might be valuable. Same as above. We can archive this if you want, but I don't think we would update it. So if you want us to make it a static archived copy, we can do that. > ## What to Do? > > I'm just throwing out a few ideas, which may even be somewhat exclusive > of each other. > > 1. Legacy Docs could be a sub-project of the Docs Project. What is involved for this to happen? I'd be interested, if it can be done in such as fashion as to not be overwealming. > Currently, we don't have enough writers to work on new documents that > are needed for FC. I don't know of anyone interested in the Legacy > docs. Legacy docs could be done by our legacy staff, in theory, though FL also doesn't have enough writers at this time to do even its own docs properly. > IMO, maintenance of a set of Legacy docs is likely to be easier than a > doc that tracks something with an active update schedule in FC. I had > this with the SELinux FAQ. It was very active during the early parts of > the release, and tapered off as rawhide become more of the next version. Yes, FL would mostly be archiving static files, and only occasionally updating docs. So it should be minimal work. > This means that one or two people could maintain quite a large set of > docs. This could be great experience for someone interested in > technical writing, open source projects, or need to support a legacy > app. I'll volunteer, as long as what ever is required of me doesn't overwhelm me. By that I mean, if you say sign up to our low volume mailing list, I'm okay with that; but if you say sign up to our very high volume mailing list, I've got a problem (too much mail already). > By integrating the efforts, current docs could be written with Legacy > needs in mind. Whatever those turn out to be. Sounds good, in theory at least. If nothing else, we could at least plan a transition for them from Fedora to Fedora Legacy. This alone would be a Good Thing. > 2. Legacy Project can form the Legacy Docs as a sub-project. At this time, we've not enough people interested to support such a project. It would be an option if people do become interested in such a project though. > 3. Legacy Project could cherry-pick from the versioned docs. The FDP > would likely keep the outdated docs available, but mark them clearly as > not current. The FDP will help get Legacy writers up to speed, mainly > through our standard docs and procedures, then mailing list support > where needed. This was our original idea I think, but it is difficult as we don't track Fedora docs, so we don't know what is there, when it becomes EOL, how to transition them, etc. Joining as a sub-group would probably give us the info we need to track and transition the docs properly. > For an overview of the docs process: > > http://fedora.redhat.com/participate/documentation-quick-start/ I'll check this out when I get time (sorry). > Our Wiki page is still being added to, we'll be adding process > documentation through this medium: > > http://fedoraproject.org/wiki/DocsProject I'll try to check that out when I get time. > Thanks - Karsten The above is just my current thoughts. I'll probably write back in a couple of days with some more thought-out ideas. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 13 21:01:00 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 13 Apr 2005 16:01:00 -0500 Subject: if anyone wants credit, let me know... Message-ID: <1113426060.982227ce8f16d@mail.ph.utexas.edu> BTW, when I created the autoupdates.php web page, I went through the mysql thread's e-mails and pulled code from the messages which was submitted by various people to include such code in the page (slightly modified of course). If any of those people who submitted the code want credit given to them in the web page, let me know and I'll add such a credit to the page. I should have put the credits in there in the first place, but was rushing it, and forgot to. Then I was just too lazy to go back and find all the authors and modify the page, etc. But if you do want credit, let me know and I'll make sure it gets done. -- Eric Rostetter From ismanager at ccbnpts.com Wed Apr 13 21:52:56 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Wed, 13 Apr 2005 16:52:56 -0500 Subject: mysql-server In-Reply-To: <1113421568.324c7198efa09@mail.ph.utexas.edu> Message-ID: <00a601c54073$26cf6570$7202a8c0@ccb2vpjza> > Eric Rostetter wrote: > > Quoting "Pettit, Paul" : > > > I've read (and now re-read) the MS document, the other one > I couldn't open > > for some reason. I disagree that is what the MS document > says on security > > updates but YMMV. > > How can you disagree with it. Some excepts are: > [snip] > > I fail to see how you can comply with any of the above if you > do un-attended > automatic updates on your production machines. The above > dictate that you > can not do unattended, automatic updates on production > machines. And they > are just a small sampling of the paper, which contains many > other statements > against automated installation of updates. > In a perfect world those are great ... It's not a perfect world. It's my right to feel that what companies say and what they actually do and practice are counter to their statements. Tell me, did you ever see the word "optional" in a security alert? Re-read the "Apply updates on a needs only basis." section and let me know if you agree or disagree. > > I was going to go into another discourse on best practices > and how the real > > world works but it's not worth it. > > It is up to you to decide if it is worth your time or not to > participate. > But I don't see how you can possibly make an argument for unattended, > automatic updates on a production machine for which you don't want > unplanned downtime. This goes against everything I've ever heard or > been taught about IT Best Practices from any source. > Well on this particular issue (since it's not what I originally posted about anyway) I'll pass. I had a nice long response but then I decided that it's not really relavent to my original point. None of this really is and I refuse to be dragged into it further. > > I decided that writing up anything at the time would have > been a) circular > > filed by you or whoever got it, > > I have never done that to a single thing you've wrote. In fact, I've > responded to most of your postings (unless I knew someone > else had replied > to it before I could). > No you haven't because it's out here on the list. Oh I guess you could have moderated me but why when I was solo on my side of the discussion. Now private emails would be different, I don't know how you would deal with disagreable opinions but from my experience here it was (and is) a perfectly reasonable expectation. > > b) would not have been very objective > > That is something only you can comment on. > And I did. I know when I've lost objectivity. At least I hope I do. :) > > and c) > > your page covered all the important parts of auto-updating > and the risks > > involved. So I moved on. > > Okay. > > > Right now I'm just going to go back to lurking (save that > test I need to do) > > as it's the safest thing to do right now. > > Which is also the surest way to make sure FL doesn't improve. > If everyone > lurks, nothing will get done, and FL will fail. But you do > have the right > to do so; if you want to be a lurker, you have that right. > Doesn't that say something to you? Anything? By your own statement you point out that driving members underground will hurt FL. So when will you take heed of your own words and let people truly speak their minds? Just because 1 person disagrees doesn't mean it's an attack. Lighten up. > > You have the keys to the car (or at least one set) and if I > or anyone should > > say "it might be best to turn left" and you turn right we > all are just along > > for the ride. > > Exactly, for both you and me. > > -- > Eric Rostetter > I'm glad you agree that it's time to listen to others. Let's hope you mean it. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From mattdm at mattdm.org Wed Apr 13 22:01:00 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Apr 2005 18:01:00 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050413025404.GA18709@nostromo.devel.redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050412150250.GA21684@jadzia.bu.edu> <1113326321.13504.37.camel@jkeating2.hq.pogolinux.com> <20050412172231.GB26576@jadzia.bu.edu> <20050412174726.GB15617@nostromo.devel.redhat.com> <20050412221158.GA4710@jadzia.bu.edu> <20050413025404.GA18709@nostromo.devel.redhat.com> Message-ID: <20050413220100.GA19484@jadzia.bu.edu> On Tue, Apr 12, 2005 at 10:54:04PM -0400, Bill Nottingham wrote: > Well, it's just that for some of the stuff I maintain, bugzilla.redhat.com > is effectively the *upstream* bugzilla. Hence, I'm not sure blanket > closing of them is the right thing to do in this case. I'm going to post something to fedora-maintainers to get a sense of what other people think. And maybe to provide some warning. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dom at earth.li Wed Apr 13 23:54:26 2005 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 14 Apr 2005 00:54:26 +0100 Subject: bugs per distro version? In-Reply-To: <20050412235259.GA11672@jadzia.bu.edu> References: <20050412235259.GA11672@jadzia.bu.edu> Message-ID: <20050413235426.GT24240@urchin.earth.li> On Tue, Apr 12, 2005 at 07:52:59PM -0400, Matthew Miller wrote: > In the future, I think it'd be nice if issues which affect multiple > supported releases each got their own bug. This'd make it easier to track > the various states of each without having the potential of a problem with a > RHL7.3 update holding up a known-good FC2 one (or vice versa). I've been thinking about this too. It would also mean we could sensibly move to per-release advisories, which at the erratic QA rate would be a good thing (no more being held up by the less popular release, etc etc). Maybe it is best for the bug to not get split up/cloned until someone's rolled some packages - so that the prep work of untangling patches and so on can go on in a single place. So a tentative nod from here. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From mattdm at mattdm.org Thu Apr 14 03:53:08 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Apr 2005 23:53:08 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050411225220.GC1337@redhat.com> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> <20050411224221.GA1337@redhat.com> <20050411224737.GA27992@jadzia.bu.edu> <20050411225220.GC1337@redhat.com> Message-ID: <20050414035308.GA29872@jadzia.bu.edu> On Mon, Apr 11, 2005 at 06:52:20PM -0400, Dave Jones wrote: > I'm 99.99999999999999% sure theres no security implications of any of them. > If you spot any that are I'd like to know about it, because as I mentioned > lots of these are FC3 bugs too. Dave, how do you feel specifically about the FC2 kernel bugs? Should they all be moved to FC3 (since it's basically the same kernel)? Or should I do the bulk NEEDINFO of all of them, with the Fedora Legacy message I posted earlier? This is about 40% of *all* open FC2 bugs, so it might be the right place to start. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Thu Apr 14 04:09:30 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 14 Apr 2005 00:09:30 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050414035308.GA29872@jadzia.bu.edu> References: <20050411173856.GA17107@jadzia.bu.edu> <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> <20050411224221.GA1337@redhat.com> <20050411224737.GA27992@jadzia.bu.edu> <20050411225220.GC1337@redhat.com> <20050414035308.GA29872@jadzia.bu.edu> Message-ID: <20050414040930.GA16276@redhat.com> On Wed, Apr 13, 2005 at 11:53:08PM -0400, Matthew Miller wrote: > On Mon, Apr 11, 2005 at 06:52:20PM -0400, Dave Jones wrote: > > I'm 99.99999999999999% sure theres no security implications of any of them. > > If you spot any that are I'd like to know about it, because as I mentioned > > lots of these are FC3 bugs too. > > Dave, how do you feel specifically about the FC2 kernel bugs? Should they > all be moved to FC3 (since it's basically the same kernel)? Or should I do > the bulk NEEDINFO of all of them, with the Fedora Legacy message I posted > earlier? > > This is about 40% of *all* open FC2 bugs, so it might be the right place to > start. I've no objection to moving them to FC3 bugs, but a lot of them are just 'stuck', and when we end of life FC3, we'll be having this conversation again. I'd recommend closing them with a 'reopen if it affects FC3 and no bug against that product exists' comment. The problem with NEEDINFO'ing them is that this doesn't solve the 'stuck' bugs. You might also want to add a note explaining why it won't be fixed in FC2. Dave From patrickmailing at narmida.com Thu Apr 14 10:36:52 2005 From: patrickmailing at narmida.com ((Mailings) Patrick Lambooy) Date: Thu, 14 Apr 2005 12:36:52 +0200 Subject: Preventing spammers from infiltrating the Red Hat mailing lists In-Reply-To: References: Message-ID: <425E47C4.8060105@narmida.com> i think its a great step for mankind. William M. Quarles wrote: > Hi all, > > I sent what I thought was a very important request to one of the Fedora > lists which was quickly beaten down, and I did not receive anything back > on subsequent replies. I would appreciate your help in making sure that > the lists are safe for all of us. I'm actually going to the trouble of > subscribing to nearly all of the Red Hat mailing lists just to get the > word out. > > One thing that I have done recently was to search for my e-mail > addresses on the Internet web pages to find all of the places that list > them. Why bother doing this? Just like how Google has spiders that > crawl the Internet to gather general information, spammers have spiders > that crawl the Internet to gather e-mail addresses to spam people. I > have contacted all of the websites who did not modify my e-mail > addresses (mostly on mailing lists) in such that they cannot be > collected. Red Hat has done at least one thing right in that they have > modified everyone's e-mail address in their web archive, such that it > reads something like for mine. > > However Red Hat has left one big gaping whole that the spam spiders can > still crawl into. There is a complete active mirror of these lists as > postable newsgroups kept on a service called Gmane . > I'm using Gmane to write this message to you now. It's a pretty > sophisticated setup, has safeguards to prevent spam getting posted, and > they use Spam Assassin to clean up stuff that still ends up on the list > (except you have to filter it yourself on the newsgroup interface). The > only problem is that spam spiders crawl the newsgroups to collect e-mail > addresses. > > Gmane has a safeguard to prevent this, but it has to be turned on by the > list administrator. Gmane can encrypt the e-mail addresses on the list > such that any mail sent to them is routed through Gmane first, and then > the sender must under go a challenge-response before the message gets > routed to the actual recipient. Of all of the Red Hat lists I've only > found two newsgroup mirrors that use address encryption: > gmane.linux.redhat.fedora.java , and > gmane.redhat.taroon . > > If you would like to see the Red Hat newsgroup mirrors have encrypted > e-mail addresses, please reply to this topic and discuss. If you are > even more brave (important since some of these lists are high-volume and > not everything gets read), please contact your list administrator > directly at . If someone knows how to get > the word out on the international lists or to their administrators > (since I don't speak multiple tongues), please do so. If someone knows > who to contact who can make all of the newsgroups have encrypted e-mail > addresses going above all of the list administrators (maybe the person > who decided to obfuscate them all on the web archive?) please contact > him or her and let us know how to contact that person. > > Thanks so much, > William > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From patrickmailing at narmida.com Thu Apr 14 10:36:52 2005 From: patrickmailing at narmida.com ((Mailings) Patrick Lambooy) Date: Thu, 14 Apr 2005 12:36:52 +0200 Subject: Preventing spammers from infiltrating the Red Hat mailing lists In-Reply-To: References: Message-ID: <425E47C4.8060105@narmida.com> i think its a great step for mankind. William M. Quarles wrote: > Hi all, > > I sent what I thought was a very important request to one of the Fedora > lists which was quickly beaten down, and I did not receive anything back > on subsequent replies. I would appreciate your help in making sure that > the lists are safe for all of us. I'm actually going to the trouble of > subscribing to nearly all of the Red Hat mailing lists just to get the > word out. > > One thing that I have done recently was to search for my e-mail > addresses on the Internet web pages to find all of the places that list > them. Why bother doing this? Just like how Google has spiders that > crawl the Internet to gather general information, spammers have spiders > that crawl the Internet to gather e-mail addresses to spam people. I > have contacted all of the websites who did not modify my e-mail > addresses (mostly on mailing lists) in such that they cannot be > collected. Red Hat has done at least one thing right in that they have > modified everyone's e-mail address in their web archive, such that it > reads something like for mine. > > However Red Hat has left one big gaping whole that the spam spiders can > still crawl into. There is a complete active mirror of these lists as > postable newsgroups kept on a service called Gmane . > I'm using Gmane to write this message to you now. It's a pretty > sophisticated setup, has safeguards to prevent spam getting posted, and > they use Spam Assassin to clean up stuff that still ends up on the list > (except you have to filter it yourself on the newsgroup interface). The > only problem is that spam spiders crawl the newsgroups to collect e-mail > addresses. > > Gmane has a safeguard to prevent this, but it has to be turned on by the > list administrator. Gmane can encrypt the e-mail addresses on the list > such that any mail sent to them is routed through Gmane first, and then > the sender must under go a challenge-response before the message gets > routed to the actual recipient. Of all of the Red Hat lists I've only > found two newsgroup mirrors that use address encryption: > gmane.linux.redhat.fedora.java , and > gmane.redhat.taroon . > > If you would like to see the Red Hat newsgroup mirrors have encrypted > e-mail addresses, please reply to this topic and discuss. If you are > even more brave (important since some of these lists are high-volume and > not everything gets read), please contact your list administrator > directly at . If someone knows how to get > the word out on the international lists or to their administrators > (since I don't speak multiple tongues), please do so. If someone knows > who to contact who can make all of the newsgroups have encrypted e-mail > addresses going above all of the list administrators (maybe the person > who decided to obfuscate them all on the web archive?) please contact > him or her and let us know how to contact that person. > > Thanks so much, > William > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From mattdm at mattdm.org Thu Apr 14 13:13:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 09:13:09 -0400 Subject: so, we've got FC2 now... In-Reply-To: <20050414040930.GA16276@redhat.com> References: <1113243556.11363.17.camel@jkeating2.hq.pogolinux.com> <20050411215804.GA25859@jadzia.bu.edu> <20050411220830.GC17345@nostromo.devel.redhat.com> <20050411221401.GA26936@jadzia.bu.edu> <20050411223427.GA27476@jadzia.bu.edu> <20050411224221.GA1337@redhat.com> <20050411224737.GA27992@jadzia.bu.edu> <20050411225220.GC1337@redhat.com> <20050414035308.GA29872@jadzia.bu.edu> <20050414040930.GA16276@redhat.com> Message-ID: <20050414131309.GA9771@jadzia.bu.edu> On Thu, Apr 14, 2005 at 12:09:30AM -0400, Dave Jones wrote: > I'd recommend closing them with a 'reopen if it affects FC3 and > no bug against that product exists' comment. The problem with > NEEDINFO'ing them is that this doesn't solve the 'stuck' bugs. The idea with NEEDINFO would be to go back in a month and WONTFIX them, again with a note that this was done in bulk and that if someone attached to the particular bug knows better, it should be reopened. But I'm also open to going straight to WONTFIX. > You might also want to add a note explaining why it won't > be fixed in FC2. Yeah, that was my intention. See the text at -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ismanager at ccbnpts.com Thu Apr 14 21:04:23 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Thu, 14 Apr 2005 16:04:23 -0500 Subject: a little bug triage... In-Reply-To: <1113412961.13504.112.camel@jkeating2.hq.pogolinux.com> Message-ID: <006501c54135$8916eba0$7202a8c0@ccb2vpjza> > Jesse Keating wrote: > > On Wed, 2005-04-13 at 11:23 -0500, Pettit, Paul wrote: > > > > I think I should be able to. I have a few spare boxes > around here that > > would > > fit the bill for a quick install + update test. Just have > to dig them > > out. > > :P > > > > Give me some time, I'll see what I can do. > > Thanks, I really appreciate it. > > -- > Jesse Keating RHCE (geek.j2solutions.net) I'm having a problem finding the install disks for 7.3 (the version that bombed). Anyone know a good mirror that has the ISO files on it (something else I'm having a problem finding). Thanks. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From ismanager at ccbnpts.com Thu Apr 14 21:11:31 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Thu, 14 Apr 2005 16:11:31 -0500 Subject: a little bug triage... In-Reply-To: <006501c54135$8916eba0$7202a8c0@ccb2vpjza> Message-ID: <006601c54136$880ba0b0$7202a8c0@ccb2vpjza> > -----Original Message----- > > I'm having a problem finding the install disks for 7.3 (the > version that > bombed). Anyone know a good mirror that has the ISO files on > it (something > else I'm having a problem finding). > n/m, I found one. Sorry for the extra noise. :P Paul P. From jedgecombe at carolina.rr.com Thu Apr 14 22:40:49 2005 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Thu, 14 Apr 2005 18:40:49 -0400 Subject: Tying FC2 into Fedora Legacy Message-ID: <425EF171.1000707@carolina.rr.com> Hi all, What do I need to do in order to have my FC2 box grab updates from Fedora Legacy? There aren't any instructions for FC2 on the web site. Sincerely, Jason Edgecombe From mattdm at mattdm.org Fri Apr 15 01:44:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 21:44:18 -0400 Subject: Tying FC2 into Fedora Legacy In-Reply-To: <425EF171.1000707@carolina.rr.com> References: <425EF171.1000707@carolina.rr.com> Message-ID: <20050415014418.GA10536@jadzia.bu.edu> On Thu, Apr 14, 2005 at 06:40:49PM -0400, Jason Edgecombe wrote: > What do I need to do in order to have my FC2 box grab updates from > Fedora Legacy? There aren't any instructions for FC2 on the web site. The infrastructure isn't all in place yet, but I think you can basically assume that it'll be like FC1, except with a 2. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Fedora at TQMcube.com Wed Apr 13 17:40:52 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Wed, 13 Apr 2005 13:40:52 -0400 Subject: Preventing spammers from infiltrating the Red Hat mailing lists In-Reply-To: References: Message-ID: <1113414052.20552.5.camel@dch.tqmcube.com> On Wed, 2005-04-13 at 12:36 -0400, William M. Quarles wrote: > If you would like to see the Red Hat newsgroup mirrors have encrypted > e-mail addresses, please reply to this topic and discuss. If you are > even more brave (important since some of these lists are high-volume and > not everything gets read), please contact your list administrator > directly at . If someone knows how to get > the word out on the international lists or to their administrators > (since I don't speak multiple tongues), please do so. If someone knows > who to contact who can make all of the newsgroups have encrypted e-mail > addresses going above all of the list administrators (maybe the person > who decided to obfuscate them all on the web archive?) please contact > him or her and let us know how to contact that person. > The problem is spam not the lists nor list management. -- ________________________________________________________________________ Kill Spam at the Source: http://www.TQMcube.com/spam_trap.htm Today's Spam Trap Adds: http://www.TQMcube.com/BlockedToday RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From Axel.Thimm at ATrpms.net Fri Apr 15 20:55:34 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Apr 2005 22:55:34 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050401120905.GI12606@neu.nirvana> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> Message-ID: <20050415205534.GD4672@neu.nirvana> On Fri, Apr 01, 2005 at 02:09:05PM +0200, Axel Thimm wrote: > On Thu, Mar 31, 2005 at 10:27:18AM -0700, Greg Bailey wrote: > > Jesse Keating wrote: > > >On Sat, 2005-03-26 at 23:31 +0100, Axel Thimm wrote: > > >>Could the parts that are mirrored from Red Hat be timestamped back to > > >>their original values? For instance: > > >> > > >>58217 Oct 29 2003 > > >>download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ncompress-4.2.4-34.src.rpm > > >>58217 Feb 27 2004 > > >>download.fedoralegacy.org/fedora/1/os/SRPMS/ncompress-4.2.4-34.src.rpm > > >> > > >>This would allow mirrors of both RH and FL to run hardlink over the > > >>folders and rescue some bits. > > >Got a good suggestion on how to do that w/out re-downloading every file > > >from RH mirrors? > > Wouldn't running rsync over the mirrored parts go fairly quickly if you > > already have the full fileset? I recall doing this sort of thing when I > > was a RedHat mirror admin in a former life. It didn't take long at all > > with the speedup rsync provides. > > Yes, that would be the easiest. And if one wants to tune this, one can > use the -B switch to rsync to use larger blocks for the checksums, but > that's probably not neccessary. why can't this be fixed? It affects > 1000 files wasting 3.2GB. And if I fix it locally I'll be resyncing the bad timestamped packages again. Here is the breakdown: 866 download.fedoralegacy.org/fedora/1/os/SRPMS/ 149 download.fedoralegacy.org/fedora/1/updates/i386/ 39 download.fedoralegacy.org/fedora/1/updates/SRPMS/ Please fix this, it's a simple rsync command. :( Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Fri Apr 15 21:19:38 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 15 Apr 2005 14:19:38 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050415205534.GD4672@neu.nirvana> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> Message-ID: <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> On Fri, 2005-04-15 at 22:55 +0200, Axel Thimm wrote: > why can't this be fixed? It affects > 1000 files wasting 3.2GB. And if > I fix it locally I'll be resyncing the bad timestamped packages again. > > Here is the breakdown: > 866 download.fedoralegacy.org/fedora/1/os/SRPMS/ > 149 download.fedoralegacy.org/fedora/1/updates/i386/ > 39 download.fedoralegacy.org/fedora/1/updates/SRPMS/ > > Please fix this, it's a simple rsync command. :( Running this command in dry-run mode indicates that it will have to re- download every file. If I do this, all other mirrors will get hit with the re-download. So then I ask again, do you have an rsync switch (other than a, I'm using a) that will only alter the timestamps rather than redownloading all the content? -- 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 jessefrgsmith at yahoo.ca Fri Apr 15 22:06:17 2005 From: jessefrgsmith at yahoo.ca (Jesse Smith) Date: Fri, 15 Apr 2005 18:06:17 -0400 (EDT) Subject: Self-Introduction: Your Name Here Message-ID: <20050415220617.57690.qmail@web21208.mail.yahoo.com> Dear Fedora Legacy Community, As my current distro of choice (Fedora Core 2) is being transfered to Fedora Legacy, I would like to take an active role in maintaining this fine distro. So, here is my self-introduction. I hope no one minds I'm deviating from the point form shown on the FL Self Introduction page. My name is Jesse Smith and I am currently a resident of Annapolis Royal (a _very_ small town) in Nova Scotia, Canada. I'm currently leading a new company, called Creative Computer Solutions, which deals with computer repair, web page design and custom software solutions. At this time I would like to offer my services in working on the QA portion of package management for Fedora Core 2. I have a desktop PC which I can use for the testing of new source/rpm packages and would like to give back to this community as I feel I shall be using your expertise while FC2 is being maintained. At this time, I suppose I should give a little background on my previous work. I have, in no particular order, coded for, submitted patches and performed tech support for the PhatLinux distro (http://phatlinux.com). I've also spent over a year coding for the Age of Legacy MUD (telnet://ageoflegacy.com:3000). In the past, I have taught workshops for high school students on the basics of computer hardware and software. A number of years ago I worked for Nova Data Systems (now Compu Quote) which writes home & auto insurance software. At this time I consider myself very familiar with Linux system administration, shell scripting and the following programming languages: C/C++, Pascal, Java (and Java Script) and BASIC. For more information about myself, please see my web site: http://slicer69.tripod.com/ which contains some of my musings, programming examples and some insights to myself. I think that's about it, so I'll finish with my GPG KeyID: pub 1024D/52B3F320 2005-04-14 Jesse Smith Key fingerprint = CEE5 3DE5 D8CB 90C5 F662 7B4B 8BD7 C5B1 52B3 F320 sub 1024g/75F8EF01 2005-04-14 Sincerely, Jesse Smith jessefrgsmith at yahoo.ca ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From wstockal at compusmart.ab.ca Fri Apr 15 22:14:22 2005 From: wstockal at compusmart.ab.ca (William Stockall) Date: Fri, 15 Apr 2005 16:14:22 -0600 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> Message-ID: <42603CBE.8030402@compusmart.ab.ca> Jesse Keating wrote: > On Fri, 2005-04-15 at 22:55 +0200, Axel Thimm wrote: > > > Running this command in dry-run mode indicates that it will have to re- > download every file. If I do this, all other mirrors will get hit with > the re-download. So then I ask again, do you have an rsync switch > (other than a, I'm using a) that will only alter the timestamps rather > than redownloading all the content? > Re-download or re-calculate check sums? If the files are actually the same except for the timestamp, all that should be downloaded by rsync is the check sum. Is that a problem by itself? Plus, changing the timestamp is likely to trigger a sync with the mirrors just the same as actually changing the files. Will. From jkeating at j2solutions.net Fri Apr 15 22:26:09 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 15 Apr 2005 15:26:09 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <42603CBE.8030402@compusmart.ab.ca> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> <42603CBE.8030402@compusmart.ab.ca> Message-ID: <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> On Fri, 2005-04-15 at 16:14 -0600, William Stockall wrote: > Re-download or re-calculate check sums? If the files are actually > the > same except for the timestamp, all that should be downloaded by rsync > is > the check sum. Is that a problem by itself? Plus, changing the > timestamp is likely to trigger a sync with the mirrors just the same > as > actually changing the files. > Yes, but if it only does the checksums as you say than it won't be bad. I'll try a couple packages and see what it actually downloads. -- 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 jkeating at j2solutions.net Fri Apr 15 23:10:10 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 15 Apr 2005 16:10:10 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> <42603CBE.8030402@compusmart.ab.ca> <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113606610.13504.265.camel@jkeating2.hq.pogolinux.com> On Fri, 2005-04-15 at 15:26 -0700, Jesse Keating wrote: > Yes, but if it only does the checksums as you say than it won't be > bad. > I'll try a couple packages and see what it actually downloads. So I just tried a small subset of packages, and it seems that the time stamps aren't all that off in either OS or Updates. What files are you seeing that the timestamps are different in? -- 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 Axel.Thimm at ATrpms.net Fri Apr 15 22:34:51 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Apr 2005 00:34:51 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> <42603CBE.8030402@compusmart.ab.ca> <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050415223451.GA5108@neu.nirvana> On Fri, Apr 15, 2005 at 03:26:09PM -0700, Jesse Keating wrote: > On Fri, 2005-04-15 at 16:14 -0600, William Stockall wrote: > > Re-download or re-calculate check sums? If the files are actually > > the > > same except for the timestamp, all that should be downloaded by rsync > > is > > the check sum. Is that a problem by itself? Plus, changing the > > timestamp is likely to trigger a sync with the mirrors just the same > > as > > actually changing the files. > > > > Yes, but if it only does the checksums as you say than it won't be bad. > I'll try a couple packages and see what it actually downloads. That is quaranteed, rsync will generate checksums on varying blocksizes (check the rsync thesis). If rsync would indeed download any payload, then the destination file was damaged. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Fri Apr 15 23:25:54 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 15 Apr 2005 16:25:54 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113606610.13504.265.camel@jkeating2.hq.pogolinux.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> <42603CBE.8030402@compusmart.ab.ca> <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> <1113606610.13504.265.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113607555.13504.267.camel@jkeating2.hq.pogolinux.com> On Fri, 2005-04-15 at 16:10 -0700, Jesse Keating wrote: > > So I just tried a small subset of packages, and it seems that the time > stamps aren't all that off in either OS or Updates. > > What files are you seeing that the timestamps are different in? Looks like it was just the srpms. Time stamps fixed, uploading to master server. -- 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 Axel.Thimm at ATrpms.net Sat Apr 16 12:07:46 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Apr 2005 14:07:46 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113607555.13504.267.camel@jkeating2.hq.pogolinux.com> References: <20050326223150.GB5752@neu.nirvana> <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com> <424C32F6.20409@lxpro.com> <20050401120905.GI12606@neu.nirvana> <20050415205534.GD4672@neu.nirvana> <1113599979.13504.248.camel@jkeating2.hq.pogolinux.com> <42603CBE.8030402@compusmart.ab.ca> <1113603969.13504.254.camel@jkeating2.hq.pogolinux.com> <1113606610.13504.265.camel@jkeating2.hq.pogolinux.com> <1113607555.13504.267.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050416120746.GA11484@neu.nirvana> On Fri, Apr 15, 2005 at 04:25:54PM -0700, Jesse Keating wrote: > On Fri, 2005-04-15 at 16:10 -0700, Jesse Keating wrote: > > > > So I just tried a small subset of packages, and it seems that the time > > stamps aren't all that off in either OS or Updates. > > > > What files are you seeing that the timestamps are different in? > > Looks like it was just the srpms. You are correct, the other mentioned 181 files (1.5GB) are due to deleted packages on RH's behalf (whether the timestamp is also not the original one or not cannot be checked anymore). I think these should be removed altogether, too. > Time stamps fixed, uploading to master server. Thanks Jesse, that already gave back 1.7GB. There are now 1.5GB lurking in 149 download.fedoralegacy.org/fedora/1/updates/i386/ 39 download.fedoralegacy.org/fedora/1/updates/SRPMS/ 2 download.fedoralegacy.org/fedora/2/updates/i386/ 1 download.fedoralegacy.org/fedora/2/updates/SRPMS/ Below the sig is the list of affected files, could you please remove/timestamp them? I guess the easiest thing to do is to take a virgin RH copy and copy all *legacy*rpm packages over. That will both fix all remaining timestamp issues (if any), and also remove the non-existing files. Or you could use rsync -n --delete src dst | grep -v "deleting .*\.legacy\." to see which files need to be removed. -- Axel.Thimm at ATrpms.net download.fedoralegacy.org/fedora/1/updates/i386/neon-0.24.5-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-1.0.15-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/hpijs-1.5-4.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/rsync-2.5.7-5.fc1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-gnome-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.75-1.3.0.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/hpijs-1.5-4.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2174.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2140.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/arpwatch-2.1a11-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-workstation-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2140.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-1.2.2-20.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-devel-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2174.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/glibc-2.3.2-101.1.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/strace-4.5.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/lha-1.14i-12.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-3.1.4-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.81-0.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-devel-1.2.5-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-devel-1.2.2-20.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kdelibs-devel-3.1.4-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-libs-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/subversion-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-devel-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mc-4.6.0-14.10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/squid-2.5.STABLE3-1.fc1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-1.0.13-11.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/rsync-2.5.7-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/perl-suidperl-5.8.3-10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2179.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.76-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_dav_svn-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.48-1.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2174.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.81-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.77-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.79-0.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2179.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-devel-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2197.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/perl-5.8.3-10.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-gtk-7.07-15.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-gnome-0.10.3-0.1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gdk-pixbuf-0.22.0-11.2.2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2188.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2194.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-devel-1.0.15-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-0.10.0a-0.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-swat-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.80-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-client-3.0.6-2.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kudzu-devel-1.1.36.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2197.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/tcpdump-3.7.2-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/gaim-0.78-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-3.0.2-7.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mailman-2.1.4-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpcap-0.7.2-8.fc1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2179.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/cvs-1.11.15-5.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2140.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/ghostscript-7.07-15.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/samba-common-3.0.4-1.FC1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/neon-devel-0.24.5-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/subversion-devel-0.32.1-2.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2194.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2188.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.4-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-server-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mc-4.6.0-8.4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.athlon.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.i686.rpm download.fedoralegacy.org/fedora/1/updates/i386/cvs-1.11.15-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-gnome-0.10.0a-0.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/krb5-libs-1.3.3-6.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng10-devel-1.0.13-11.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.i586.rpm download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-i18n-1.1.0-15.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/libpng-1.2.5-4.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kudzu-1.1.36.1-1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.6-1.3.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2188.nptl.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/ethereal-0.10.3-0.1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.49-1.1.i386.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.80-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ghostscript-7.07-15.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.75-1.3.0.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/httpd-2.0.48-1.2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kudzu-1.1.36.1-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kdelibs-3.1.4-5.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/cvs-1.11.15-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2179.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mailman-2.1.4-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/cvs-1.11.15-5.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/squid-2.5.STABLE3-1.fc1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/tcpdump-3.7.2-8.fc1.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/libpng-1.2.2-20.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.77-2.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.4-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.6-2.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.76-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/subversion-0.32.1-2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2197.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ghostscript-7.07-15.3.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/lha-1.14i-12.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.78-1.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/libpng10-1.0.13-11.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.79-0.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mc-4.6.0-8.4.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gdk-pixbuf-0.22.0-11.2.2.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/mc-4.6.0-14.10.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2188.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2174.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/samba-3.0.2-7.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/neon-0.24.5-1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/krb5-1.3.3-6.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/perl-5.8.3-10.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/openoffice.org-1.1.0-15.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/gaim-0.81-0.FC1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/ethereal-0.10.0a-0.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/php-4.3.4-1.1.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2194.nptl.src.rpm download.fedoralegacy.org/fedora/1/updates/SRPMS/rsync-2.5.7-2.src.rpm download.fedoralegacy.org/fedora/2/updates/i386/ethereal-0.10.9-1.FC2.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/i386/ethereal-gnome-0.10.9-1.FC2.1.i386.rpm download.fedoralegacy.org/fedora/2/updates/SRPMS/ethereal-0.10.9-1.FC2.1.src.rpm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jasdel49 at comcast.net Sat Apr 16 16:33:10 2005 From: jasdel49 at comcast.net (James R. DeLoach) Date: Sat, 16 Apr 2005 11:33:10 -0500 Subject: Dual Boot System Message-ID: <6.2.1.2.2.20050416113111.02614290@mail.comcast.net> Right now I have my system set to dual boot Fedora and windows with the default being Fedora. I want to change the default to boot into windows. Can I do this and if so, how? Thanks, James From ad+lists at uni-x.org Sat Apr 16 16:40:09 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Sat, 16 Apr 2005 18:40:09 +0200 Subject: Dual Boot System In-Reply-To: <6.2.1.2.2.20050416113111.02614290@mail.comcast.net> References: <6.2.1.2.2.20050416113111.02614290@mail.comcast.net> Message-ID: <1113669609.913.233.camel@serendipity.dogma.lan> Am Sa, den 16.04.2005 schrieb James R. DeLoach um 18:33: > Right now I have my system set to dual boot Fedora and windows with the > default being Fedora. I want to change the default to boot into > windows. Can I do this and if so, how? > James Edit /etc/grub.conf and change the "default=" value. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.14_FC2smp Serendipity 18:39:39 up 4 days, 15:20, load average: 0.09, 0.19, 0.25 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jkeating at j2solutions.net Sat Apr 16 17:21:26 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 16 Apr 2005 10:21:26 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050416120746.GA11484@neu.nirvana> References: <20050326223150.GB5752@neu.nirvana> <1113607555.13504.267.camel@jkeating2.hq.pogolinux.com> <20050416120746.GA11484@neu.nirvana> Message-ID: <200504161021.32695.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 16 April 2005 05:07, Axel Thimm wrote: > You are correct, the other mentioned 181 files (1.5GB) are due to > deleted packages on RH's behalf (whether the timestamp is also not the > original one or not cannot be checked anymore). I think these should > be removed altogether, too. > > > Time stamps fixed, uploading to master server. > > Thanks Jesse, that already gave back 1.7GB. There are now 1.5GB > lurking in > > ? ? 149 download.fedoralegacy.org/fedora/1/updates/i386/ > ? ? ?39 download.fedoralegacy.org/fedora/1/updates/SRPMS/ > ? ? ? 2 download.fedoralegacy.org/fedora/2/updates/i386/ > ? ? ? 1 download.fedoralegacy.org/fedora/2/updates/SRPMS/ > > Below the sig is the list of affected files, could you please > remove/timestamp them? I guess the easiest thing to do is to take a > virgin RH copy and copy all *legacy*rpm packages over. That will both > fix all remaining timestamp issues (if any), and also remove the > non-existing files. > > Or you could use > > rsync -n --delete src dst | grep -v > "deleting .*\.legacy\." > > to see which files need to be removed. Actually I don't want to remove the dupes. I've had to look at older updates too often to remove them. Sorry. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCYUmc4v2HLvE71NURAkOmAKDAzfEctCjejcS1N5cBG67Hq2zbWQCfclG1 5PDViuJXYSN0gU36ggvwdhk= =hqUx -----END PGP SIGNATURE----- From robark at gmail.com Sat Apr 16 17:42:44 2005 From: robark at gmail.com (Robert Arkiletian) Date: Sat, 16 Apr 2005 10:42:44 -0700 Subject: Upgrade RH9 kernel -> RHEL 3 kernel Message-ID: Hi, I am a high school teacher who runs RH9 as a Terminal Server. Is it possible to upgrade RH9 kernel 2.4.20 to WBEL, Centos or RHEL 2.4.21 kernel? Or even getting the SRPM and compiling it? I'm asking because redhat backported many enhancements of the 2.6 kernel to the EL 2.4.21 kernel. Here is the list of features backported: http://www.redhat.com/software/rhel/3features/kernel/ -- Robert Arkiletian C++ GUI tutorial http://fltk.org/links.php?V19 From dr at cluenet.de Sat Apr 16 19:21:44 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 16 Apr 2005 21:21:44 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <200504161021.32695.jkeating@j2solutions.net> References: <20050326223150.GB5752@neu.nirvana> <1113607555.13504.267.camel@jkeating2.hq.pogolinux.com> <20050416120746.GA11484@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> Message-ID: <20050416192144.GA28957@srv01.cluenet.de> On Sat, Apr 16, 2005 at 10:21:26AM -0700, Jesse Keating wrote: > Actually I don't want to remove the dupes. I've had to look at older > updates too often to remove them. Could superseeded updates please be moved to another directory, like attic/ or so? So this is available at central sites, but all local mirrors (like I do have for my systems) don't need to carry them "just in case". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jkeating at j2solutions.net Sat Apr 16 19:52:44 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 16 Apr 2005 12:52:44 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050416192144.GA28957@srv01.cluenet.de> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> Message-ID: <200504161252.44540.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 16 April 2005 12:21, Daniel Roesen wrote: > Could superseeded updates please be moved to another directory, like > attic/ or so? So this is available at central sites, but all local > mirrors (like I do have for my systems) don't need to carry them "just > in case". Welp, I'll take community input on it. Is there anybody (besides me) that wants to keep the superseeded updates on the mirror server? - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCYW0M4v2HLvE71NURAvnQAKCBkt+SlQWh8j25KF/SwT8OdRBejgCfRo7m tlsgJkkwt4XHMwhFjk6W3ew= =0q9F -----END PGP SIGNATURE----- From cra at WPI.EDU Sat Apr 16 20:14:16 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 16 Apr 2005 16:14:16 -0400 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <200504161252.44540.jkeating@j2solutions.net> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> Message-ID: <20050416201416.GD5266@angus.ind.WPI.EDU> On Sat, Apr 16, 2005 at 12:52:44PM -0700, Jesse Keating wrote: > Welp, I'll take community input on it. Is there anybody (besides me) that > wants to keep the superseeded updates on the mirror server? I do. Previous updates are valuable for QA. I've brought this up a few times before. Instead of making an attic/ directory to which old updates are moved (causing mirrors to re-download them), how about making a latest/ directory that symlinks or hardlinks to only the newest updates? Then people who only want the newest can sync against latest/. From jkeating at j2solutions.net Sat Apr 16 20:31:03 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 16 Apr 2005 13:31:03 -0700 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050416201416.GD5266@angus.ind.WPI.EDU> References: <20050326223150.GB5752@neu.nirvana> <200504161252.44540.jkeating@j2solutions.net> <20050416201416.GD5266@angus.ind.WPI.EDU> Message-ID: <200504161331.03662.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 16 April 2005 13:14, Chuck R. Anderson wrote: > I do. ?Previous updates are valuable for QA. > > I've brought this up a few times before. ?Instead of making an attic/ > directory to which old updates are moved (causing mirrors to > re-download them), how about making a latest/ directory that symlinks > or hardlinks to only the newest updates? ?Then people who only want > the newest can sync against latest/. I was hoping not to toss a new directory at people, and this is a bit more complicated of a mirror structure... - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCYXYH4v2HLvE71NURAv67AJ9qAL0uSUCUBDcsayxv8Vp9g1yOowCcDL9W 1P+SWGHi3BluYe9g8l9OE08= =CKIh -----END PGP SIGNATURE----- From marcdeslauriers at videotron.ca Sat Apr 16 22:08:14 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 16 Apr 2005 18:08:14 -0400 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <200504161252.44540.jkeating@j2solutions.net> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> Message-ID: <1113689295.25442.4.camel@mdlinux> On Sat, 2005-04-16 at 12:52 -0700, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 16 April 2005 12:21, Daniel Roesen wrote: > > Could superseeded updates please be moved to another directory, like > > attic/ or so? So this is available at central sites, but all local > > mirrors (like I do have for my systems) don't need to carry them "just > > in case". > > Welp, I'll take community input on it. Is there anybody (besides me) that > wants to keep the superseeded updates on the mirror server? I would like the superseeded updates to stay available. They are invaluable in figuring out if it was one of our security updates that broke something or if the original package was broken. I don't mind an "attic" directory, but I don't know how easy that is to setup and maintain... Marc. -------------- 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 dr at cluenet.de Sat Apr 16 22:11:00 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 17 Apr 2005 00:11:00 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <200504161252.44540.jkeating@j2solutions.net> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> Message-ID: <20050416221100.GA30491@srv01.cluenet.de> On Sat, Apr 16, 2005 at 12:52:44PM -0700, Jesse Keating wrote: > On Saturday 16 April 2005 12:21, Daniel Roesen wrote: > > Could superseeded updates please be moved to another directory, like > > attic/ or so? So this is available at central sites, but all local > > mirrors (like I do have for my systems) don't need to carry them "just > > in case". > > Welp, I'll take community input on it. Is there anybody (besides me) > that wants to keep the superseeded updates on the mirror server? I do think that keeping superseeded updates _somewhere_ (a master server and 1-2 mirrors for resilience) is needed, but I don't think those need to be mirrored everywhere. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Axel.Thimm at ATrpms.net Sat Apr 16 23:53:32 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Apr 2005 01:53:32 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <1113689295.25442.4.camel@mdlinux> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> <1113689295.25442.4.camel@mdlinux> Message-ID: <20050416235332.GC19067@neu.nirvana> On Sat, Apr 16, 2005 at 06:08:14PM -0400, Marc Deslauriers wrote: > On Sat, 2005-04-16 at 12:52 -0700, Jesse Keating wrote: > > On Saturday 16 April 2005 12:21, Daniel Roesen wrote: > > > Could superseeded updates please be moved to another directory, > > > like attic/ or so? So this is available at central sites, but > > > all local mirrors (like I do have for my systems) don't need to > > > carry them "just in case". > > > > Welp, I'll take community input on it. Is there anybody (besides > > me) that wants to keep the superseeded updates on the mirror > > server? > > I would like the superseeded updates to stay available. They are > invaluable in figuring out if it was one of our security updates > that broke something or if the original package was broken. I think this is a misunderstanding, noone wants to remove foo-1.2.3-4 when FL releases foo-1.2.3-5.legacy. The "superseeded updates" are superseeded by updates coming from Red Hat. I.e. these packages have vanished from the Red Hat master mirror. As an example: -rw-r--r-- 1 ftp ftp 92161 Apr 14 2004 download.fedoralegacy.org/fedora/1/updates/i386/neon-0.24.5-1.i386.rpm -rw-r--r-- 4 ftp ftp 92305 May 19 2004 download.fedoralegacy.org/fedora/1/updates/i386/neon-0.24.5-2.1.i386.rpm The latter is what Red Hat's (frozen) update folder currently contains, while the former had been deleted by RH before FC2 went EOL. When FL issues neon-0.24.5-3.legacy.i386.rpm the vendor-superseeded package (0.24.5-2.1) should stay, but why keep 0.24.5-1? > I don't mind an "attic" directory, but I don't know how easy that is > to setup and maintain... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Apr 17 00:04:40 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Apr 2005 02:04:40 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <200504161252.44540.jkeating@j2solutions.net> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> Message-ID: <20050417000440.GD19067@neu.nirvana> On Sat, Apr 16, 2005 at 12:52:44PM -0700, Jesse Keating wrote: > Hash: SHA1 > > On Saturday 16 April 2005 12:21, Daniel Roesen wrote: > > Could superseeded updates please be moved to another directory, like > > attic/ or so? So this is available at central sites, but all local > > mirrors (like I do have for my systems) don't need to carry them "just > > in case". > > Welp, I'll take community input on it. Is there anybody (besides me) that > wants to keep the superseeded updates on the mirror server? Note these are superseeded by RH, not FL, e.g. noone wants to remove the last vendor provided package, only the ones that the vendor himself doomed to /dev/null. Keeping old packages in the repos is not helpful, especially for an end user using yum. yum cannot downgrade packages anyway, and hardly an end user will want to go back in package history in FL scope (an FL user relies on the fact that surfing on latest FL updates will give him a secure system). Developers may be interested to be able to track a package back, but IMHO we don't need that structure replicated over all mirrors raising each distros space by a factor of 50%. Just look at the plethora of obsoleted kernel packages, e.g. (i686/up only) -rw-r--r-- 1 ftp ftp 13M Jan 7 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2140.nptl.i686.rpm -rw-r--r-- 1 ftp ftp 13M Feb 19 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2174.nptl.i686.rpm -rw-r--r-- 1 ftp ftp 13M Apr 14 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2179.nptl.i686.rpm -rw-r--r-- 1 ftp ftp 13M Apr 22 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2188.nptl.i686.rpm -rw-r--r-- 1 ftp ftp 13M Jun 21 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2194.nptl.i686.rpm -rw-r--r-- 1 ftp ftp 13M Jul 1 2004 download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2197.nptl.i686.rpm My vote is to remove them from the repo structure, and if there is interest to place them outside the mirroring area. Keeping the mirror space low makes it more attractive to mirrors. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dr at cluenet.de Sun Apr 17 00:25:23 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 17 Apr 2005 02:25:23 +0200 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050417000440.GD19067@neu.nirvana> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> <20050417000440.GD19067@neu.nirvana> Message-ID: <20050417002523.GA32387@srv01.cluenet.de> On Sun, Apr 17, 2005 at 02:04:40AM +0200, Axel Thimm wrote: > Note these are superseeded by RH, not FL, e.g. noone wants to remove > the last vendor provided package, only the ones that the vendor > himself doomed to /dev/null. I was talking about _all_ superseeded updates. There is no sense to mirror deprecated updates around the world. > Developers may be interested to be able to track a package back, but > IMHO we don't need that structure replicated over all mirrors raising > each distros space by a factor of 50%. Just look at the plethora of > obsoleted kernel packages, e.g. (i686/up only) Exactly my point. They should be archived, but not replicated everywhere. Total waste of resources. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mattdm at mattdm.org Sun Apr 17 03:40:47 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 16 Apr 2005 23:40:47 -0400 Subject: Mirroring: Bad datestamps prevent hardlinking In-Reply-To: <20050417002523.GA32387@srv01.cluenet.de> References: <20050326223150.GB5752@neu.nirvana> <200504161021.32695.jkeating@j2solutions.net> <20050416192144.GA28957@srv01.cluenet.de> <200504161252.44540.jkeating@j2solutions.net> <20050417000440.GD19067@neu.nirvana> <20050417002523.GA32387@srv01.cluenet.de> Message-ID: <20050417034047.GA24509@jadzia.bu.edu> On Sun, Apr 17, 2005 at 02:25:23AM +0200, Daniel Roesen wrote: > Exactly my point. They should be archived, but not replicated > everywhere. Total waste of resources. But of course it doesn't hurt to replicate them a little bit, so they're accessible even if the primary site has a problem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wfm692 at netscape.net Sun Apr 17 21:58:32 2005 From: wfm692 at netscape.net (William Makowski) Date: Sun, 17 Apr 2005 17:58:32 -0400 Subject: Error When Viewing Documentation with Nautilus RHL7.3 Message-ID: <04712122.7D0F1164.0006E177@netscape.net> After a recent yum update I now receive errors when using the standard launcher to view documentation with nautilus. The error reads, "The Web Page view encountered an error while starting up." The launcher properties are as follows... Name: Help Comment: Documentation Command: nautilus --no-default-window --no-desktop ghelp:toc Type: Application Using google I found that this error has been reported before. It appears to be an incompatibility issue between versions of nautilus, nautilus-mozilla, mozilla. I have the following packages installed. nautilus 1.0.6-16 nautilus-mozilla 1.0.6-16 mozilla 1.4.3-0.7.1.legacy I'm thinking I need to downgrade mozilla to get things working again, but am not sure what other changes are required. Has anyone else run into this problem and found a solution? Also, does this qualify as an entry for bugzilla? Bill __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp From marcdeslauriers at videotron.ca Mon Apr 18 03:38:49 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 17 Apr 2005 23:38:49 -0400 Subject: Error When Viewing Documentation with Nautilus RHL7.3 In-Reply-To: <04712122.7D0F1164.0006E177@netscape.net> References: <04712122.7D0F1164.0006E177@netscape.net> Message-ID: <1113795529.1130.1.camel@mdlinux> On Sun, 2005-04-17 at 17:58 -0400, William Makowski wrote: > I'm thinking I need to downgrade mozilla to get things working again, > but am not sure what other changes are required. Has anyone else run > into this problem and found a solution? Also, does this qualify as > an entry for bugzilla? Please file a bug report at bugzilla.redhat.com and I will build updated nautilus packages to fix the problem. Thanks. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Mon Apr 18 12:22:41 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Apr 2005 07:22:41 -0500 Subject: Upgrade RH9 kernel -> RHEL 3 kernel In-Reply-To: References: Message-ID: Robert Arkiletian wrote: > Hi, I am a high school teacher who runs RH9 as a Terminal Server. > Is it possible to upgrade RH9 kernel 2.4.20 to WBEL, Centos or RHEL > 2.4.21 kernel? Or even getting the SRPM and compiling it? I wouldn't recommend it, but that doesn't mean you couldn't try. -- Rex From rostetter at mail.utexas.edu Mon Apr 18 19:22:03 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 18 Apr 2005 14:22:03 -0500 Subject: Upgrade RH9 kernel -> RHEL 3 kernel In-Reply-To: References: Message-ID: <1113852123.934cdaca12409@mail.ph.utexas.edu> Quoting Robert Arkiletian : > Hi, I am a high school teacher who runs RH9 as a Terminal Server. > Is it possible to upgrade RH9 kernel 2.4.20 to WBEL, Centos or RHEL > 2.4.21 kernel? Or even getting the SRPM and compiling it? You should be able to rebuild the SRPM, but it depends on various factors. You would really be on your own if you did it. You would want to stay with RHEL 3.x and clones, as RHEL 4.x and clones use the 2.6 kernel. > I'm asking because redhat backported many enhancements of the 2.6 > kernel to the EL 2.4.21 kernel. Many of the same features are in the RHL 9 kernel. > Here is the list of features backported: > http://www.redhat.com/software/rhel/3features/kernel/ A lot of those are in RHL 9, some are not. Which ones are you interested in? > -- > Robert Arkiletian > C++ GUI tutorial http://fltk.org/links.php?V19 -- Eric Rostetter From adhoc_dev at yahoo.com Mon Apr 18 19:47:44 2005 From: adhoc_dev at yahoo.com (adhoc dev) Date: Mon, 18 Apr 2005 12:47:44 -0700 (PDT) Subject: starting a process or executing a command while the system boots Message-ID: <20050418194744.55905.qmail@web61309.mail.yahoo.com> Hi if i need to start a process during boot, in which file should i specify it. I need to execute the command /sbin/ifconfig eth1:1 add 2001:100:1::1/64 during the boot up process so that eth1:1 is configured whilst the system. It tried specifying this command in /etc/rc.local but its not getting configured while the system boot. Can anyone please specify, in which file should i specify this, so that it /sbin/ifconfig gets executed while the system boots Regards Dev --------------------------------- Do you Yahoo!? Make Yahoo! your home page -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad+lists at uni-x.org Mon Apr 18 20:01:13 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Mon, 18 Apr 2005 22:01:13 +0200 Subject: starting a process or executing a command while the system boots In-Reply-To: <20050418194744.55905.qmail@web61309.mail.yahoo.com> References: <20050418194744.55905.qmail@web61309.mail.yahoo.com> Message-ID: <1113854472.913.467.camel@serendipity.dogma.lan> Am Mo, den 18.04.2005 schrieb adhoc dev um 21:47: > if i need to start a process during boot, in which file should i specify it. > > I need to execute the command /sbin/ifconfig eth1:1 add 2001:100:1::1/64 during the boot up process so that > eth1:1 is configured whilst the system. It tried specifying this command in /etc/rc.local but its not getting > configured while the system boot. Can anyone please specify, in which file should i specify this, so that it > /sbin/ifconfig gets executed while the system boots > Dev /etc/sysconfig/network-scripts/icfg-eth1:1 Please read the documentation below /usr/share/doc/initscripts*/ Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.14_FC2smp Serendipity 21:59:34 up 6 days, 18:39, load average: 0.69, 0.55, 0.36 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rostetter at mail.utexas.edu Mon Apr 18 20:11:52 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 18 Apr 2005 15:11:52 -0500 Subject: FC2 transition progress Message-ID: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> Can anyone give me an update on the FC2 transition/migration progress? I can see slow progress, but have no real info on how things are going. Anything I can do to help? -- Eric Rostetter From jkeating at j2solutions.net Mon Apr 18 20:28:50 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 18 Apr 2005 13:28:50 -0700 Subject: FC2 transition progress In-Reply-To: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> Message-ID: <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-18 at 15:11 -0500, Eric Rostetter wrote: > > Can anyone give me an update on the FC2 transition/migration progress? > I can see slow progress, but have no real info on how things are > going. > Anything I can do to help? Text that was submitted by me to Fedora News... So FC2 was handed over to Legacy. Due to a small lack of planning on my part, and a larger issue of being completely busy the weekend before FC4 Test2 released, I was not able to get the infrastructure ready for FC2 in time for the hand off. Because of this, I've had to contend with bandwith hungry testers that are pulling down FC4Test2 like there is no tomorrow. Thankfully I've been able to sync up all the original FC2 packages and current updates. As of this afternoon, they were uploading from our build and master server box over to the master mirror server which should then spread to all the mirrors out there. Of course no packages have been built yet, nor has a yumconf been made specifically for it. We're working on a quick 'Getting Started with FC2 Legacy' doc that will cover what needs to be changed to start using our services. Also, Red Hat Bugzilla now has a Fedora Legacy product with a release for FC2 (as well as the others we're supporting). Bugs can now be filed, and we are reviewing current FC2 bugs for security concerns. All in all, the handoff is happening, but we have a lot of work to do in order to make it more smooth next time. Look for more FC2 happenings within Fedora Legacy over the next week or so. Cheers! -- 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 rostetter at mail.utexas.edu Mon Apr 18 20:41:11 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 18 Apr 2005 15:41:11 -0500 Subject: FC2 transition progress In-Reply-To: <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113856871.a9c56f40230d8@mail.ph.utexas.edu> Quoting Jesse Keating : > Thankfully I've been able to sync up all the original FC2 packages and > current updates. As of this afternoon, they were uploading from our > build and master server box over to the master mirror server which > should then spread to all the mirrors out there. Of course no packages > have been built yet, nor has a yumconf been made specifically for it. Sounds good. I'll see if I can get that into the web page. > We're working on a quick 'Getting Started with FC2 Legacy' doc that will > cover what needs to be changed to start using our services. I already created one in CVS, but never pushed it to the web site. Not sure how far along you are, or who is doing it. Anyway, in CVS you'll find my hack, which was just to make some small changes to the FC1 yum guide. We need better co-ordination here. > Also, Red Hat Bugzilla now has a Fedora Legacy product with a release > for FC2 (as well as the others we're supporting). Bugs can now be > filed, and we are reviewing current FC2 bugs for security concerns. All > in all, the handoff is happening, but we have a lot of work to do in > order to make it more smooth next time. Okay, I'll put some of that on the web page also. > Look for more FC2 happenings within Fedora Legacy over the next week or > so. Sounds good... Can you keep me, or the list, informed of important milestones as they happen (like this message you sent to Fedora News)? > Cheers! -- Eric Rostetter From pyz at brama.com Mon Apr 18 21:59:30 2005 From: pyz at brama.com (Max Pyziur) Date: Mon, 18 Apr 2005 17:59:30 -0400 (EDT) Subject: FC2 transition progress In-Reply-To: <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> Message-ID: <22150.156.77.108.72.1113861570.squirrel@webmail.brama.com> > On Mon, 2005-04-18 at 15:11 -0500, Eric Rostetter wrote: >> >> Can anyone give me an update on the FC2 transition/migration progress? >> I can see slow progress, but have no real info on how things are >> going. >> Anything I can do to help? > > Text that was submitted by me to Fedora News... > > So FC2 was handed over to Legacy. Due to a small lack of planning on my I realize that project management of transitioning FC2 to Fedora Legacy has many challenges. However, with all of this I would like to make what I hope is a small request - would it be possible for the listmaster using Mailman's web functionality to insert the name of this list into the subject line? Given the general volume of email (and spam) it makes it easier to scan subject headings. [...] > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > Much thanks for your consideration. Max Pyziur pyz at brama.com From jkeating at j2solutions.net Mon Apr 18 22:03:34 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 18 Apr 2005 15:03:34 -0700 Subject: FC2 transition progress In-Reply-To: <1113856871.a9c56f40230d8@mail.ph.utexas.edu> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> <1113856871.a9c56f40230d8@mail.ph.utexas.edu> Message-ID: <1113861814.13504.313.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-18 at 15:41 -0500, Eric Rostetter wrote: > I already created one in CVS, but never pushed it to the web site. > Not sure how far along you are, or who is doing it. Anyway, in CVS > you'll find my hack, which was just to make some small changes to the > FC1 yum guide. We need better co-ordination here. Can you post the text of it here to the list so that we can all look at it? > > Also, Red Hat Bugzilla now has a Fedora Legacy product with a > release > > for FC2 (as well as the others we're supporting). Bugs can now be > > filed, and we are reviewing current FC2 bugs for security concerns. > All > > in all, the handoff is happening, but we have a lot of work to do in > > order to make it more smooth next time. > > Okay, I'll put some of that on the web page also. > > > Look for more FC2 happenings within Fedora Legacy over the next week > or > > so. > > Sounds good... Can you keep me, or the list, informed of important > milestones as they happen (like this message you sent to Fedora News)? Will do. I got hit up for this late last week and hadn't had a chance to forward it to this list yet, but your message prompted me to do so (: FWIW I haven't seen it it FedoraNews yet. -- 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 jkeating at j2solutions.net Mon Apr 18 22:06:07 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 18 Apr 2005 15:06:07 -0700 Subject: FC2 transition progress In-Reply-To: <22150.156.77.108.72.1113861570.squirrel@webmail.brama.com> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> <22150.156.77.108.72.1113861570.squirrel@webmail.brama.com> Message-ID: <1113861967.13504.315.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-18 at 17:59 -0400, Max Pyziur wrote: > > However, with all of this I would like to make what I hope is a small > request - would it be possible for the listmaster using Mailman's web > functionality to insert the name of this list into the subject line? > Given the general volume of email (and spam) it makes it easier to > scan > subject headings. The majority of all Red Hat mailing lists lack this, and I wouldn't want to add it here. Adds unnecessary noise to the subject lines. There is a header for List-Post, perhaps you should configure your client(s) to filter these messages into their own folders. -- 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 cave.dnb at tiscali.fr Mon Apr 18 22:28:00 2005 From: cave.dnb at tiscali.fr (nigel henry) Date: Mon, 18 Apr 2005 23:28:00 +0100 Subject: Will FC1 updates still be available when EOL'd by Fedora Legacy Message-ID: <200504182328.00675.cave.dnb@tiscali.fr> Hi folks. I've been using FC1 and more recently FC2 as a home user for some time. I'm very happy with both, and would just like to know if the depository will still be available when FC1 is eventually dropped. For instance. I reinstall FC1. Will I be able to get all the security updates up to to time when Fedora Legacy has discontinued support for FC1. Nigel. From robark at gmail.com Mon Apr 18 22:32:51 2005 From: robark at gmail.com (Robert Arkiletian) Date: Mon, 18 Apr 2005 15:32:51 -0700 Subject: Upgrade RH9 kernel -> RHEL 3 kernel In-Reply-To: <1113852123.934cdaca12409@mail.ph.utexas.edu> References: <1113852123.934cdaca12409@mail.ph.utexas.edu> Message-ID: On 4/18/05, Eric Rostetter wrote: > You would really be on your own if you did it. You would want to stay > with RHEL 3.x and clones, as RHEL 4.x and clones use the 2.6 kernel. I know. I am a little scared to do it. But the other option is I start from scratch with FC2 if I want all the 2.6 enhancements. > Many of the same features are in the RHL 9 kernel. The only one I am aware of is the Native Posix Thread Library (NPTL). Do you know which other features were backported to RHL9? > A lot of those are in RHL 9, some are not. Which ones are you interested in? The one which I was hoping to get was the Scheduler support for hyperthreaded CPUs. I know that the new scheduler is able to discern between virtual and real cpus and therefore schedules processes optimally on Hyperthreaded CPU's. I have a dual Xeon at my school so this feature would be welcome. -- Robert Arkiletian C++ GUI tutorial http://fltk.org/links.php?V19 From rostetter at mail.utexas.edu Mon Apr 18 22:35:15 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 18 Apr 2005 17:35:15 -0500 Subject: FC2 transition progress In-Reply-To: <1113861814.13504.313.camel@jkeating2.hq.pogolinux.com> References: <1113855112.5e35ae89a0259@mail.ph.utexas.edu> <1113856130.13504.304.camel@jkeating2.hq.pogolinux.com> <1113856871.a9c56f40230d8@mail.ph.utexas.edu> <1113861814.13504.313.camel@jkeating2.hq.pogolinux.com> Message-ID: <1113863715.c87aaee59a297@mail.ph.utexas.edu> Quoting Jesse Keating : > On Mon, 2005-04-18 at 15:41 -0500, Eric Rostetter wrote: > > I already created one in CVS, but never pushed it to the web site. > > Not sure how far along you are, or who is doing it. Anyway, in CVS > > you'll find my hack, which was just to make some small changes to the > > FC1 yum guide. We need better co-ordination here. > > Can you post the text of it here to the list so that we can all look at > it? For now, simply see http://www.fedoralegacy.org/docs/yum-fc2.php We should develop one for up2date and apt also (could also be based on the current FC1 versions also). For some reason, I only did yum, and not apt/up2date... Not sure why, probably lack of time... I can whip up a apt/up2date based on the FC1 real fast, if desired. I wasn't pushing much FC2 stuff to the web site yet though, since we've not got FC2 up and running yet. The CVS has lots of updates for FC2 in it though... -- Eric Rostetter From jkeating at j2solutions.net Mon Apr 18 22:35:44 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 18 Apr 2005 15:35:44 -0700 Subject: Will FC1 updates still be available when EOL'd by Fedora Legacy In-Reply-To: <200504182328.00675.cave.dnb@tiscali.fr> References: <200504182328.00675.cave.dnb@tiscali.fr> Message-ID: <1113863744.13504.323.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-18 at 23:28 +0100, nigel henry wrote: > Hi folks. I've been using FC1 and more recently FC2 as a home user for > some > time. I'm very happy with both, and would just like to know if the > depository > will still be available when FC1 is eventually dropped. For instance. > I > reinstall FC1. Will I be able to get all the security updates up to to > time > when Fedora Legacy has discontinued support for FC1. Nigel. Yes, I currently plan to continue hosting the outdated content for at least a couple releases. -- 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 rostetter at mail.utexas.edu Mon Apr 18 22:43:01 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 18 Apr 2005 17:43:01 -0500 Subject: Upgrade RH9 kernel -> RHEL 3 kernel In-Reply-To: References: <1113852123.934cdaca12409@mail.ph.utexas.edu> Message-ID: <1113864181.2a9cfaf462433@mail.ph.utexas.edu> Quoting Robert Arkiletian : > > Many of the same features are in the RHL 9 kernel. > > The only one I am aware of is the Native Posix Thread Library (NPTL). > Do you know which other features were backported to RHL9? No, just that some like NPTL and ACL support are there. > > A lot of those are in RHL 9, some are not. Which ones are you interested > in? > > The one which I was hoping to get was the Scheduler support for > hyperthreaded CPUs. No, sorry, none of the scheduling stuff is in RHL 9. For that, you would need the RHEL kernel, or a real 2.6 kernel. > I know that the new scheduler is able to discern > between virtual and real cpus and therefore schedules processes > optimally on Hyperthreaded CPU's. I have a dual Xeon at my school so > this feature would be welcome. Yes, I'm also awaiting being able to use hyperthreading in a sane way, so I feel your pain. But no go with RHL 9. You'll need to upgrade either the OS or the kernel, as you previously noted. > -- > Robert Arkiletian > C++ GUI tutorial http://fltk.org/links.php?V19 -- Eric Rostetter From cave.dnb at tiscali.fr Tue Apr 19 00:21:36 2005 From: cave.dnb at tiscali.fr (nigel henry) Date: Tue, 19 Apr 2005 01:21:36 +0100 Subject: Will FC1 updates still be available when EOL'd by Fedora Legacy In-Reply-To: <1113863744.13504.323.camel@jkeating2.hq.pogolinux.com> References: <200504182328.00675.cave.dnb@tiscali.fr> <1113863744.13504.323.camel@jkeating2.hq.pogolinux.com> Message-ID: <200504190121.36207.cave.dnb@tiscali.fr> On Monday 18 Apr 2005 11:35 pm, Jesse Keating wrote: > On Mon, 2005-04-18 at 23:28 +0100, nigel henry wrote: > > Hi folks. I've been using FC1 and more recently FC2 as a home user for > > some > > time. I'm very happy with both, and would just like to know if the > > depository > > will still be available when FC1 is eventually dropped. For instance. > > I > > reinstall FC1. Will I be able to get all the security updates up to to > > time > > when Fedora Legacy has discontinued support for FC1. Nigel. > > Yes, I currently plan to continue hosting the outdated content for at > least a couple releases. Thanks Jesse for the prompt reply. I'm very happy to hear that the repository will still be available for some time. You're all doing very much appreciated work, thanks a lot. Nigel. From wfm692 at netscape.net Tue Apr 19 01:57:03 2005 From: wfm692 at netscape.net (William Makowski) Date: Mon, 18 Apr 2005 21:57:03 -0400 Subject: Error When Viewing Documentation with Nautilus RHL7.3 Message-ID: <33F8268F.7E5EC204.0006E177@netscape.net> Marc Deslauriers wrote: >On Sun, 2005-04-17 at 17:58 -0400, William Makowski wrote: >> I'm thinking I need to downgrade mozilla to get things working again, >> but am not sure what other changes are required. Has anyone else run >> into this problem and found a solution? Also, does this qualify as >> an entry for bugzilla? > >Please file a bug report at bugzilla.redhat.com and I will build updated >nautilus packages to fix the problem. Thank you for your quick reply. I've filed a bug report, it reads very similar to my previous message. See Bugzilla Bug 155246. Bill __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp From madlists at teaparty.net Tue Apr 19 09:52:01 2005 From: madlists at teaparty.net (Tom Yates) Date: Tue, 19 Apr 2005 10:52:01 +0100 (BST) Subject: documentation error: http://www.fedoralegacy.org/docs/yum-rh9.php In-Reply-To: <33F8268F.7E5EC204.0006E177@netscape.net> References: <33F8268F.7E5EC204.0006E177@netscape.net> Message-ID: there seems to be an error in http://www.fedoralegacy.org/docs/yum-rh9.php, in step 2 (install yum), it gives the command as: rpm -ivh http://download.fedoralegacy.org/redhat/9/i386/yum-2.0.5-0.9.2.legacy.noarch.rpm which gives (for me, at least) a 404. i find there should be a /legacy-utils/ between /redhat/9/ and /i386/. sorry if this is wrong. if it's not, does anyone fancy correcting the doco? -- Tom Yates - madhatter at teaparty.net - http://www.teaparty.net From rostetter at mail.utexas.edu Tue Apr 19 17:34:37 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 19 Apr 2005 12:34:37 -0500 Subject: documentation error: http://www.fedoralegacy.org/docs/yum-rh9.php In-Reply-To: References: <33F8268F.7E5EC204.0006E177@netscape.net> Message-ID: <1113932077.3d87f040fab09@mail.ph.utexas.edu> Quoting Tom Yates : > which gives (for me, at least) a 404. i find there should be a > /legacy-utils/ between /redhat/9/ and /i386/. Should be fixed now. Thanks! -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 20 19:20:10 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 20 Apr 2005 14:20:10 -0500 Subject: doc question for FC1/FC2 users Message-ID: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> I've just updated the yum docs, and have a question about FC1 yum (probably FC2 also). In the docs, we have an example yum.conf which contains the line: distroverpkg=redhat-release Is this correct, or should it be instead: distroverpkg=fedora-release Or will either one work? -- Eric Rostetter From cra at WPI.EDU Wed Apr 20 19:26:57 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 20 Apr 2005 15:26:57 -0400 Subject: doc question for FC1/FC2 users In-Reply-To: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> Message-ID: <20050420192657.GH4369@angus.ind.WPI.EDU> On Wed, Apr 20, 2005 at 02:20:10PM -0500, Eric Rostetter wrote: > > I've just updated the yum docs, and have a question about FC1 yum (probably > FC2 also). In the docs, we have an example yum.conf which contains the line: > > distroverpkg=redhat-release > > Is this correct, or should it be instead: > > distroverpkg=fedora-release > > Or will either one work? FC3 also has the same thing. The answer I got was that you should use redhat-release, because that always works on any release. fedora-release Provides: redhat-release, so I'd imagine yum does something similar to this: >rpm -q --whatprovides redhat-release fedora-release-3-8 From rob.myers at gtri.gatech.edu Wed Apr 20 19:48:12 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Wed, 20 Apr 2005 15:48:12 -0400 Subject: doc question for FC1/FC2 users In-Reply-To: <20050420192657.GH4369@angus.ind.WPI.EDU> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> Message-ID: <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> On Wed, 2005-04-20 at 15:26 -0400, Chuck R. Anderson wrote: > On Wed, Apr 20, 2005 at 02:20:10PM -0500, Eric Rostetter wrote: > > > > I've just updated the yum docs, and have a question about FC1 yum (probably > > FC2 also). In the docs, we have an example yum.conf which contains the line: this may be a good time for you to revisit this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152801 rob. From jkeating at j2solutions.net Thu Apr 21 15:54:28 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 21 Apr 2005 08:54:28 -0700 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> Message-ID: <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> On Thu, 2005-04-21 at 11:31 -0400, Joe Harrington wrote: > Hi, I'm an x86_64 user. I notice that the Legacy x86_64 repo for FC2 > still isn't up: > > /etc/cron.daily/yum.cron: > > Error getting file > http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info > [Errno 4] IOError: HTTP Error 404: Not Found > Error getting file > http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info > [Errno 4] IOError: HTTP Error 404: Not Found > > Assuming this is in the works, it would be useful if you could at > least put up an empty, placeholder repo so that the nightly updates > wouldn't produce errors. Unfortunately at this time we don't support x86_64. I don't have enough infrastructure for a 64bit build system to produce the 64bit packages. Also, I'm not confident that there are enough x86_64 users willing to test and QA x86_64 packages. That said, the SRPMS can be rebuilt if you're inclined to do so. > Also, please mention on > http://www.fedoralegacy.org/ what the status of the transition is. > That way, users could know whether this is in the works or if it has > fallen through the cracks. > > Also, when the Fedora Project announced the EOL of FC2, I switched > immediately over to the Legacy repo, which it turned out was not yet > ready. I saw your posting on the 18th, and I understand the > difficulties of wearing many hats, but I hope next time you can put > the empty infrastructure in place well in advance just so that nightly > updates don't fail. > > I'm not taking you to task, just making a suggestion. > > Thanks for all your hard work! Yep, next transition will be much better planned. I swear. -- 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 jh at oobleck.astro.cornell.edu Thu Apr 21 19:30:44 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 21 Apr 2005 15:30:44 -0400 Subject: separate emails to fedora-legacy-announce for each OS Message-ID: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> It would be good if the fedora-legacy-announce emails had the same format as the fedora-announce-list emails. Specifically, each message should state the distro it's for in the subject. I don't like having to dig (deeply) through each email to determine if the update applies to one of my systems. I'd rather be able to look at the summary at the top of the daily archive message and see it in the list there. I have a script that I cut-n-paste the archive index to (below), that checks whether I got the updates automatically. It greps out the current version in the list and then does and rpm -q on the full package name. Any "not installeds" and I know that for some reasons my updates are failing. That can happen for many reasons: my laptop battery ran down and that turns off crond to save power my local mirror stopped getting updates yum.conf got messed up there was a package conflict with an external package etc. At least the first two of these happen quietly. I can't use a script like that on Legacy messages, because the info on what OS version it's for isn't in the message subjects, because all the OS updates are reported in a single email. In pre-post discussions, it was suggested that my suggestion would proliferate the number of emails. While true, the solution already exists: get the list in archive form on a daily basis (when there is mail at all). The announcements are not of a down-to-the-minute, time-critical nature. An alternative would be to have a list per release. But, I think following the Fedora Project would be the way to go. So, following the pre-post discussions, I'll ask: How do others feel about following Fedora's one-post-per-OS scheme? --jh-- From jh at oobleck.astro.cornell.edu Thu Apr 21 19:46:14 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 21 Apr 2005 15:46:14 -0400 Subject: x86_64 FC2 repo not up yet? Message-ID: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> Ok, I now see in the FAQ that Legacy doesn't support x86_64. But regardless of the item buried deep in the FAQ, the general population thinks Legacy will maintain whatever Red Hat produces, and since that's not the case, it should be made prominently clear. The Fedora Project makes statements like "the Fedora Steering Committee would like to announce the transfer of Fedora Core 2 to the Fedora Legacy Project" on its web page. There's an implication here that Legacy will then do something with the release, and that implication makes people who are deciding what distro to use feel that they won't be stranded if they use Fedora. I shouldn't have to read a FAQ on another website to find critical info when I choose whether to run a distro (but I think I did, in fact, read the Legacy FAQ when I made that decision last summer). Right now the only hint that not everything recent is maintained is the little word "select" on the front page. I think an appropriate (and fairly minimal) notice would be to add a statement to the "What is..." section of the main web page like "Note that we do not maintain updates for all architectures or all releases; please refer to the maintenance grid for more information" and link that to a grid listing all of the RH releases down the left, all of the architectures across the top, and giving a letter in each cell: Y maintained N not maintained n/a combination never existed F future maintenance planned D maintenance being dropped within the next 2 months Of course, I hope for x86_64 maintenance soon. The architecture is widely used in HPC environments, particularly in academia, and it is particularly difficult to upgrade the OS on an HPC cluster. I'd be willing to bet that, if approached, AMD or even Red Hat would provide the necessary hardware. Getting QA testers is key, of course. Users will be growing in number, though I don't know what the numbers are for FC2. Thanks, --jh-- From deisenst at gtw.net Thu Apr 21 20:47:35 2005 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 21 Apr 2005 15:47:35 -0500 (CDT) Subject: wording question In-Reply-To: <1113246272.77cf62f2252c5@mail.ph.utexas.edu> Message-ID: On Mon, 11 Apr 2005, Eric Rostetter wrote: > > In the Fedora Legacy docs, we use the terms "Consensus" and "Veto" which > maybe are not the best way to do things. > > Consensus seeks that all or the vast majority of the participants be "for" > a position. Veto means that something can be rejected without cause or > reason. > > Instead, it might be suggested we switch to a system of "Consent" in which > we don't need everyone to agree on something, but rather just that no one > is against it. In order for it not to pass, anyone who is against it must > be supported by a valid argument for their position. > > In other words, instead of requiring mass support, we just need to lack of > opposition. And in order to oppose it, the opposition must provide a > valid argument against it. > > Thoughts? This sounds pretty good, Eric, though I am only finding the use of the word "consensus" in our online docs a few places, and those mainly in the wiki (nodes "UpdatedOverview" and "QaTesting"). Are there other places I am not seeing it that you are concerned about? I guess it all depends upon what kinds of activities you feel we need to use a "consent" model for. The various activities of our Project seem to require different levels of control. Publishing things to the wiki, for example, seems to be a consent thing, in that things get put there until someone else objects, or just goes in and changes it. Though "acquiesce" may be another way to talk about the wiki, considering the spam we get there. ;-) Basically, it seems like consent, the way you define it, is the way we're doing things now anyway. It is kinda the concept of "Do it now, and apologize later," which gets results; a philosophy of "Don't do it until you get permission," seems to cause things to languish, because nobody remembers to give permission. And we're all really pretty good at catching when someone else makes a mistake. You know, the old addage that "Nobody ever listens until you make a mistake." ;-) HOWEVER -- in QA testing in the bugzilla, we must keep a permission (or formal consent) model -- things mustn't be verified to updates-testing or published to updates until there is (at least one, probably better two) positive, PGP signed, votes from people doing QA work. QA cannot happen without this kind of permission given. It seems that, generally, if there is a negative comment given in bugzilla, items do not move forward. Instead of veto, maybe the idea of "valid blocking issue," (or "Marc or Dominic veto" which is the same thing 99% of the time ;-) ) or something like that, could be used. By the way, Eric, I like what you have done with "How to use Bugzilla" on the fedoralegacy.org website . It looks pretty up-to-date in sync with our new bugzilla at Red Hat. :-) -David From rostetter at mail.utexas.edu Thu Apr 21 21:14:01 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 21 Apr 2005 16:14:01 -0500 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114118041.b16200d05d0fb@mail.ph.utexas.edu> Quoting Jesse Keating : > On Thu, 2005-04-21 at 11:31 -0400, Joe Harrington wrote: > > Hi, I'm an x86_64 user. I notice that the Legacy x86_64 repo for FC2 > > still isn't up: We have not yet completed the FC2 transition from the Fedora Project, so you will find problems with anything FC2 related. > > Assuming this is in the works, it would be useful if you could at > > least put up an empty, placeholder repo so that the nightly updates > > wouldn't produce errors. > > Unfortunately at this time we don't support x86_64. I don't have enough > infrastructure for a 64bit build system to produce the 64bit packages. > Also, I'm not confident that there are enough x86_64 users willing to > test and QA x86_64 packages. That said, the SRPMS can be rebuilt if > you're inclined to do so. Please note his use of "at this time" and "enough x86_64 users". This is not a certainty that we will not support x86_64 for FC2, only that we're not yet doing it. If people step forward with the needed support, then I'm sure FLP will try to support it as soon as possible. > > Also, please mention on > > http://www.fedoralegacy.org/ what the status of the transition is. It does mention the status of the transition to the best of my knowledge. As soon as anyone tells me where we are in the transition, I update the web page to include that info. Unfortunately, I'm not updated often. > > That way, users could know whether this is in the works or if it has > > fallen through the cracks. What I know is there. > > Also, when the Fedora Project announced the EOL of FC2, I switched > > immediately over to the Legacy repo, which it turned out was not yet > > ready. Correct. -- Eric Rostetter From jh at oobleck.astro.cornell.edu Thu Apr 21 15:31:44 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 21 Apr 2005 11:31:44 -0400 Subject: x86_64 FC2 repo not up yet? Message-ID: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> Hi, I'm an x86_64 user. I notice that the Legacy x86_64 repo for FC2 still isn't up: /etc/cron.daily/yum.cron: Error getting file http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info [Errno 4] IOError: HTTP Error 404: Not Found Error getting file http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info [Errno 4] IOError: HTTP Error 404: Not Found Assuming this is in the works, it would be useful if you could at least put up an empty, placeholder repo so that the nightly updates wouldn't produce errors. Also, please mention on http://www.fedoralegacy.org/ what the status of the transition is. That way, users could know whether this is in the works or if it has fallen through the cracks. Also, when the Fedora Project announced the EOL of FC2, I switched immediately over to the Legacy repo, which it turned out was not yet ready. I saw your posting on the 18th, and I understand the difficulties of wearing many hats, but I hope next time you can put the empty infrastructure in place well in advance just so that nightly updates don't fail. I'm not taking you to task, just making a suggestion. Thanks for all your hard work! --jh-- From eric.rostetter at physics.utexas.edu Thu Apr 21 22:20:56 2005 From: eric.rostetter at physics.utexas.edu (Eric Rostetter) Date: Thu, 21 Apr 2005 17:20:56 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> Message-ID: <1114122056.8db0f21295a2e@mail.ph.utexas.edu> Quoting Joe Harrington : > It would be good if the fedora-legacy-announce emails had the same > format as the fedora-announce-list emails. They have the same format as the Red Hat Linux and Red Hat Enterprise Linux announcements instead, no? > Specifically, each message > should state the distro it's for in the subject. I don't like having > to dig (deeply) through each email to determine if the update applies > to one of my systems. I'd rather be able to look at the summary at > the top of the daily archive message and see it in the list there. And I don't really want to get 4-6 copies of each advisory just because it applies to that many releases. It would make my job of updating the web site a lot harder also. And make the job of those releasing the advisories at least a bit harder... I'm not saying this can't be changed, but I am saying that other people have different needs, and that we are following a well established Red Hat method of doing things (even if Fedora Project differs). > In pre-post discussions, it was suggested that my suggestion would > proliferate the number of emails. While true, the solution already > exists: get the list in archive form on a daily basis (when there is > mail at all). This may not be practical for many people/applications. > The announcements are not of a down-to-the-minute, > time-critical nature. I think some people would disagree with that. > An alternative would be to have a list per > release. But, I think following the Fedora Project would be the way > to go. You haven't convinced me. While you've provided reasons both for and against your argument, you've not managed to make me see why either way is really better. > So, following the pre-post discussions, I'll ask: > > How do others feel about following Fedora's one-post-per-OS scheme? I don't like it, for the following reasons: * More work for the people cutting updates (unless they can automate this more for the future) * More work for me (I update the advisories on the web site from the e-mails sent to the announce list) * Too many e-mails (and sometimes digest formats just aren't desirable). * Most other distros do it our way (only Fedora Project differs that I know of, though there are probably others). > --jh-- -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From skvidal at phy.duke.edu Thu Apr 21 17:35:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Apr 2005 13:35:57 -0400 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114104957.23497.38.camel@cutter> On Thu, 2005-04-21 at 08:54 -0700, Jesse Keating wrote: > On Thu, 2005-04-21 at 11:31 -0400, Joe Harrington wrote: > > Hi, I'm an x86_64 user. I notice that the Legacy x86_64 repo for FC2 > > still isn't up: > > > > /etc/cron.daily/yum.cron: > > > > Error getting file > > http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info > > [Errno 4] IOError: HTTP Error 404: Not Found > > Error getting file > > http://download.fedoralegacy.org/fedora/2/os/x86_64/headers/header.info > > [Errno 4] IOError: HTTP Error 404: Not Found > > > > Assuming this is in the works, it would be useful if you could at > > least put up an empty, placeholder repo so that the nightly updates > > wouldn't produce errors. > > Unfortunately at this time we don't support x86_64. I don't have enough > infrastructure for a 64bit build system to produce the 64bit packages. > Also, I'm not confident that there are enough x86_64 users willing to > test and QA x86_64 packages. That said, the SRPMS can be rebuilt if > you're inclined to do so. > The box would need ram but that machine you sent to me a long while back is still sitting in my office. It's not fancy but we might be able to make it happy. -sv From rostetter at mail.utexas.edu Thu Apr 21 22:32:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 21 Apr 2005 17:32:33 -0500 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> References: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> Message-ID: <1114122753.73a4ba3f19726@mail.ph.utexas.edu> Quoting Joe Harrington : > Ok, I now see in the FAQ that Legacy doesn't support x86_64. But Then you read it wrong. It says: --- Initially we will only be supporting x86 architectures. With the Fedora Core releases, x86_64 (amd64) architectures will become supported as well. With Fedora Core, we will attempt to provide support for all architectures for which Fedora Core has official support. However, our support will depend on the availability of those architectures for QA testing. We always provide source RPM packages so that people using other architectures can rebuild them for use on their architecture. --- So, it isn't that we are not supporting it, it is that until recently there was no need to support it, and now that there is, we've not yet set up any infrastructor for it, and we don't yet have enough people wanting it and willing to support it. > regardless of the item buried deep in the FAQ, the general population > thinks Legacy will maintain whatever Red Hat produces, and since > that's not the case, it should be made prominently clear. Well, it is the case, but only if we have sufficient community interest/support/involvement. And, we may not be able to support everything on day one, sometimes there may be a delay in getting support for something. > The Fedora Project makes statements like "the Fedora Steering > Committee would like to announce the transfer of Fedora Core 2 to the > Fedora Legacy Project" on its web page. There's an implication here > that Legacy will then do something with the release, and that > implication makes people who are deciding what distro to use feel that > they won't be stranded if they use Fedora. First, we have no control over what FP puts on their web page or when they put it there. And secondly, the implication you cite is just the implication we want, though at times we may drop the ball and be unprepared or get to things in a less than timely fashion. > I shouldn't have to read a > FAQ on another website to find critical info when I choose whether to > run a distro (but I think I did, in fact, read the Legacy FAQ when I > made that decision last summer). You only need read the main web page where it says the transition of FC is underway but not yet complete. > Right now the only hint that not everything recent is maintained is > the little word "select" on the front page. No, the statement that we've not yet transitioned FC2 to FLP clearly states that not everything is maintained yet for FC2. And many places we discuss that support for anything requires community support/involvment/etc. > I think an appropriate > (and fairly minimal) notice would be to add a statement to the "What > is..." section of the main web page like "Note that we do not maintain > updates for all architectures or all releases; please refer to the > maintenance grid for more information" and link that to a grid listing > all of the RH releases down the left, all of the architectures across > the top, and giving a letter in each cell: > > Y maintained > N not maintained > n/a combination never existed > F future maintenance planned > D maintenance being dropped within the next 2 months Sounds like basically a good idea. Notice on the right side of the main page is a list of supported OS versions though, and note that FC2 isn't there yet. Until now, we've not really needed anything like you propose above. But in the future we probably should have such as list. I'll see what I can do, but I may need help (hint hint). > Of course, I hope for x86_64 maintenance soon. The architecture is > widely used in HPC environments, particularly in academia, and it is > particularly difficult to upgrade the OS on an HPC cluster. I'd be > willing to bet that, if approached, AMD or even Red Hat would provide > the necessary hardware. Getting QA testers is key, of course. Users > will be growing in number, though I don't know what the numbers are > for FC2. Sounds about right. Might you be interested in participating? I don't remember seeing a "Self Introduction" or other notice from you... ;) > Thanks, > > --jh-- -- Eric Rostetter From rostetter at mail.utexas.edu Thu Apr 21 22:47:45 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 21 Apr 2005 17:47:45 -0500 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114122753.73a4ba3f19726@mail.ph.utexas.edu> References: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> <1114122753.73a4ba3f19726@mail.ph.utexas.edu> Message-ID: <1114123665.9c1f3e6b04be8@mail.ph.utexas.edu> Quoting Eric Rostetter : > Quoting Joe Harrington : > > regardless of the item buried deep in the FAQ, the general population > thinks Legacy will maintain whatever Red Hat produces, and since > that's not the case, it should be made prominently clear. Don't know if it is prominent, but I've added a note to the right side bar of the main page, where we list supported versions. I had no idea FC1 had x86_64 support, and no idea we were ignoring that. Shouldn't we at least be mirroring the old FP packages for x86_64, even though we're not providing updates for them at this time? If we do start supporting x86_64 for FC2 at a later time, wouldn't this make it easier if we already had all the x86_64 stuff from FP in place? -- Eric Rostetter From jkeating at j2solutions.net Thu Apr 21 22:50:26 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 21 Apr 2005 15:50:26 -0700 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114104957.23497.38.camel@cutter> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> <1114104957.23497.38.camel@cutter> Message-ID: <1114123826.7333.25.camel@localhost.localdomain> On Thu, 2005-04-21 at 13:35 -0400, seth vidal wrote: > > The box would need ram but that machine you sent to me a long while > back > is still sitting in my office. It's not fancy but we might be able to > make it happy. I've been trying to get you to ship that back to me..... (: -- 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 skvidal at phy.duke.edu Thu Apr 21 22:58:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Apr 2005 18:58:36 -0400 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114123826.7333.25.camel@localhost.localdomain> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> <1114104957.23497.38.camel@cutter> <1114123826.7333.25.camel@localhost.localdomain> Message-ID: <1114124316.23497.47.camel@cutter> On Thu, 2005-04-21 at 15:50 -0700, Jesse Keating wrote: > On Thu, 2005-04-21 at 13:35 -0400, seth vidal wrote: > > > > The box would need ram but that machine you sent to me a long while > > back > > is still sitting in my office. It's not fancy but we might be able to > > make it happy. > > I've been trying to get you to ship that back to me..... (: > You have? I never saw an address. send me a mailing address and I can get it packed up and sent off next week. Sorry if I dropped the ball on that. -sv From jkeating at j2solutions.net Thu Apr 21 23:04:22 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 21 Apr 2005 16:04:22 -0700 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114124316.23497.47.camel@cutter> References: <200504211531.j3LFVie9031735@oobleck.astro.cornell.edu> <1114098868.19088.103.camel@jkeating2.hq.pogolinux.com> <1114104957.23497.38.camel@cutter> <1114123826.7333.25.camel@localhost.localdomain> <1114124316.23497.47.camel@cutter> Message-ID: <1114124662.7333.27.camel@localhost.localdomain> On Thu, 2005-04-21 at 18:58 -0400, seth vidal wrote: > You have? I never saw an address. > > send me a mailing address and I can get it packed up and sent off next > week. > > Sorry if I dropped the ball on that. Maybe I kept telling myself to have you send it back, and then I'd forget by the time I saw you on IRC. No worries, (: Address coming privately. -- 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 jh at oobleck.astro.cornell.edu Fri Apr 22 00:38:16 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 21 Apr 2005 20:38:16 -0400 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <1114122753.73a4ba3f19726@mail.ph.utexas.edu> (message from Eric Rostetter on Thu, 21 Apr 2005 17:32:33 -0500) References: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> <1114122753.73a4ba3f19726@mail.ph.utexas.edu> Message-ID: <200504220038.j3M0cGN5002443@oobleck.astro.cornell.edu> [In rereading the text below, it's rather long, for which I apologize. The main point is that there's a mismatch between impression and reality on the Legacy web site, and I don't think it's in anyone's long-term interest to perpetuate it. It certainly isn't in the user's. I think part of why it's so long is that I'm trying to be kind and make a strong point at the same time. Please understand that I do hold the project and its volunteers in high regard, and that I'm not looking for huge changes. But, to get the changes right may require folks to develop an outsider's point of view on the project, which is what I'm trying to give.] > So, it isn't that we are not supporting it, it is that until recently there > was no need to support it, and now that there is, we've not yet set up any > infrastructor for it, and we don't yet have enough people wanting it and > willing to support it. Well, we're getting mixed up in semantics. All I said was that you do not support x86_64, not that you won't ever. It is true that you do not currently support it, regardless of the intentions, and you also reserve the right not to support it ever if the resources are not there. My offline conversation with Jesse Keating earlier today indicated some doubt as to whether the resources were there. And, we're not talking about a trivial interval of non-support, given that a security bug was reported March 28 (CAN-2005-0468 and CAN-2005-0469, thanks to David Eisner for pointing this one out to me in offline email). The reason I'm pointing out what might otherwise be a nitpick is that, regardless of the lack of a formal financial/contractual commitment to users, a lot of people look to this project to see whether they can use Fedora Core in real-world environments. Many people ask me, is Fedora stable if you pick it up two releases behind and run all the way through Legacy? You are looked to as an avenue to a stable Fedora, and strong statements that are backed by plans rather than reality can lead people to make bad decisions. > Well, it is the case, but only if we have sufficient community > interest/support/involvement. And, we may not be able to support > everything on day one, sometimes there may be a delay in getting > support for something. You're making my point beautifully. Since things are not necessarily supported right off, and not everything is going to be supported, you should make this clear in plain language (think Warren Buffett) right on the front page, and give people something like a chart or a list or a per-release status page so that they can see 1) what is currently supported, 2) what you're actively working on getting supported, and 3) by extrapolation (and at their own risk), what they might expect for a future distro. In my case, had there been prior releases with x86_64 versions, and had I seen Legacy not support them, I would have decided to go with something other than Fedora for my cluster, and it would have been a good decision: My cluster has been subject to a known security hole for almost a month now, due to the lack of updates. That scares me, and while I see good intention here I think it will be at least a few more weeks more, and possibly much longer, before support arrives. > And secondly, the implication you cite is just the > implication we want, though at times we may drop the ball and be > unprepared or get to things in a less than timely fashion. Careful here, you're saying you want people to believe something that you admit may not always be true. I'm not sure where that sits in your moral framework. It doesn't sit, in mine. This isn't some toy you're dealing with, it's something depended on by thousands of people, and real damage measured in real dollars and real hours occurs when someone gets broken into. People decide whether to depend on Fedora based on your statements and those on the Fedora site. To be credible in the long term, you need to make up for your lack of formal liability by being brutally honest and transparent at all times. > You only need read the main web page where it says the transition of > FC is underway but not yet complete. > No, the statement that we've not yet transitioned FC2 to FLP clearly > states that not everything is maintained yet for FC2. And many places > we discuss that support for anything requires community support/involvment/etc. You misunderstand me here. I'm talking about someone who has a new box and is deciding what to put on it. This person presumably starts with a current version of FC, and checks Legacy to see whether they will in the future have support, even after Fedora EOLs it. For me that was last July, and of course there was nothing about the current transition. I was looking for statements relevant to whether x86_64 would be supported. I don't recall whether the x86_64 item was on the FAQ then, but I do recall coming away satisfied that your commitment to all the releases was high enough that I'd see a relatively seamless transition. That is the impression you gave, quite effectively. Someone doing that today, who might start with FC3 or wait for FC4, would have little to indicate that taking their release into Legacy would be anything other than a change of repo in yum.conf. It would be more honest and transparent if you wrote (and kept up after the current transition was complete) that the most recent conversion to Legacy took a month (or whatever it ends up being), in which time users of those systems had an open security vulnerability, and that you hope, but do not guarrantee, that the next transition will be quicker (and sure, give a plug for more volunteers). I'm not trying to rain on your parade here, though I think my words will have that effect. I'm pointing out that there is a big gap between the overall impression given about Legacy support and the reality. I'm also not laying blame or even saying that you have not done the best you can with the resources you have. I'm saying that the users can only care about the end result, and you serve them, Fedora, and yourselves best if you are quite clear and open about what you can in practice actually provide. It's not the place for marketing-like glossovers of weaknesses. It is better to make an honest impression than a good one. > Sounds about right. Might you be interested in participating? I don't > remember seeing a "Self Introduction" or other notice from you... ;) Well, it will be intro and conclusion. I joined the list today after both Jesse Keating and Matthew Miller suggested it, just to ask the two questions I have asked. I'm currently coordinating part of the development of scipy (the "let's write some real docs and make a real web site and make some binary packages now that the software is coming together" part), and I'm afraid that other than filing bugs, I can only do volunteer time on one project. I'm also searching for a faculty job in astronomy (I study extrasolar planets), and I'm the dad of a toddler. Given the latter, there's also a lot of "I used to"s I could add, but won't, mainly because life-with-a-life is a fading memory. For background, I cut my computational teeth as a systems developer for MIT Project Athena (think X and Kerberos, though I didn't work on those projects except as a "friendly tester") in 1986-1988, turning the first workstations into things more useful than a Vax 750. --jh-- From jh at oobleck.astro.cornell.edu Fri Apr 22 01:14:15 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 21 Apr 2005 21:14:15 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114122056.8db0f21295a2e@mail.ph.utexas.edu> (message from Eric Rostetter on Thu, 21 Apr 2005 17:20:56 -0500) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> Message-ID: <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> > They have the same format as the Red Hat Linux and Red Hat Enterprise > Linux announcements instead, no? > * Most other distros do it our way (only Fedora Project differs that I know > of, though there are probably others). Perhaps. My point is one of utility, not compatibility. I was pointing out that FP does it this way to show what I like, not to raise a compatibility point. However, there is a compatibility point, now that you mention it. People using this service are coming off of FP, not off some other distro. It would be good to keep the same form of communication, particularly where some people use automated means to process the information. Matthew Miller mentioned to me that he also processes those messages with scripts. > > The announcements are not of a down-to-the-minute, > > time-critical nature. > I think some people would disagree with that. If you are referring to people working on the project, I can see the need for response/attention in under a day. For people using the service in its recommended form (i.e., nightly yum updates), the advisories are not so urgent, assuming their update systems are working. > I don't like it, for the following reasons: > * More work for the people cutting updates (unless they can automate this > more for the future) > * More work for me (I update the advisories on the web site from the e-mails > sent to the announce list) These show a developer's point of view, not a user's (though on a volunteer project with limited resources, it may be defensible to put developers' needs over users'). > * Too many e-mails (and sometimes digest formats just aren't desirable). As a user, you'd like to be able to filter out the ones that are for you, and preferably also check that you got the updates in an automated way (by the way, I said in my post that I'd attach the script and didn't, so see below). Jesse Keating said that the emails are sent automatically, written by Python scripts. It wouldn't be too outrageous to grab the scripts from FP and have them post to a second list (or even a list per release). People would be able to subscribe to either and everyone would be happy. My impression is that these scripts should not be hard to maintain, particularly if you're grabbing one set from FP rather than writing them yourselves. --jh-- cd ~/bin cat > updchk << EOF #! /bin/sh # run this, cut-n-paste the announce-list's daily archive summary # to it, hit return for good measure, and type ^D once rel=`awk '{print $4}' /etc/fedora-release` rpm -q `grep "Fedora Core $rel Update:" | sed -e 's/.*Update: //' -e 's/ .*//'` EOF chmod 755 updchk From mattdm at mattdm.org Fri Apr 22 04:09:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 22 Apr 2005 00:09:24 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114122056.8db0f21295a2e@mail.ph.utexas.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> Message-ID: <20050422040924.GA19424@jadzia.bu.edu> On Thu, Apr 21, 2005 at 05:20:56PM -0500, Eric Rostetter wrote: > You haven't convinced me. While you've provided reasons both for and > against your argument, you've not managed to make me see why either way > is really better. I think separating them is better for tracking purposes, and because it will enable us to not hold up an advisory when one version is problematic but another is fine. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From rostetter at mail.utexas.edu Fri Apr 22 17:51:30 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 22 Apr 2005 12:51:30 -0500 Subject: x86_64 FC2 repo not up yet? In-Reply-To: <200504220038.j3M0cGN5002443@oobleck.astro.cornell.edu> References: <200504211946.j3LJkEdn000625@oobleck.astro.cornell.edu> <1114122753.73a4ba3f19726@mail.ph.utexas.edu> <200504220038.j3M0cGN5002443@oobleck.astro.cornell.edu> Message-ID: <1114192290.59083a69f79d5@mail.ph.utexas.edu> Quoting Joe Harrington : > > So, it isn't that we are not supporting it, it is that until recently there > > was no need to support it, and now that there is, we've not yet set up any > > infrastructor for it, and we don't yet have enough people wanting it and > > willing to support it. > > Well, we're getting mixed up in semantics. All I said was that you do Well, we're also getting mixed up in lack of facts. I don't use FC, so I had no idea that FC1 had x86_64 support. I assumed FC2 was the first to have x86_64 support. After you raised this issue, I went and checked and found FC1 did also have x84_64 support. So I've updated the web page to mention the issue that we're not supporting x86_64. I'll soon try to rewrite the FAQ entry dealing with architectures also, to make it more accurate, now that I know the facts. > The reason I'm pointing out what might otherwise be a nitpick is that, > regardless of the lack of a formal financial/contractual commitment to > users, a lot of people look to this project to see whether they can > use Fedora Core in real-world environments. Many people ask me, is > Fedora stable if you pick it up two releases behind and run all the > way through Legacy? You are looked to as an avenue to a stable > Fedora, and strong statements that are backed by plans rather than > reality can lead people to make bad decisions. In this case, the web site was wrong, and it was wrong only because I lacked sufficient information, and no one (until you) had either pointed out the problem or even raised the issue recently. I apologize for my ignorance of the issue, and hence the misinformation on the web site which resulted from it. > > And secondly, the implication you cite is just the > > implication we want, though at times we may drop the ball and be > > unprepared or get to things in a less than timely fashion. > > Careful here, you're saying you want people to believe something that > you admit may not always be true. Yes, because the implication was our intent. But in this case, we've obviously dropped the ball, and we need to change the implication now because of that. But I really believed what we implied was true, or I wouldn't have allowed it. Now that I know it isn't true, I will change it. > I'm not sure where that sits in > your moral framework. It doesn't sit, in mine. Moral framework unfortunately doesn't take into account ignorance of a situation. I wasn't being immoral, I just didn't know any better. > People decide whether to depend on > Fedora based on your statements and those on the Fedora site. To be > credible in the long term, you need to make up for your lack of formal > liability by being brutally honest and transparent at all times. I did not believe there was a problem, and no one had brought any problems to my attention, so I put on the web site what I did in good faith, and I said what I said on the mailing list in good faith. However, I now see that it was all wrong, and I was completely unaware of the reality. All I can do now is apologize and try to fix what is incorrect in the web site asap. > You misunderstand me here. I'm talking about someone who has a new > box and is deciding what to put on it. This person presumably starts > with a current version of FC, and checks Legacy to see whether they > will in the future have support, even after Fedora EOLs it. For me > that was last July, and of course there was nothing about the current > transition. I was looking for statements relevant to whether x86_64 > would be supported. I don't recall whether the x86_64 item was on the > FAQ then, but I do recall coming away satisfied that your commitment > to all the releases was high enough that I'd see a relatively seamless > transition. That is the impression you gave, quite effectively. Yes, it was, and we meant to give that impression. Somewhere along the line the FLP as a whole dropped the ball, and the web site was no longer accurate. But unfortunately, I did not know we'd dropped the ball, no one made me aware the project dropped the ball, and so the web site was never changed (since I'm the only one maintaining it). All I can do at this point is apologize, change the web site now (after the fact), and try to get the FLP to act one way or the other on the issue now that I am aware of the situation. Trust me that I will do those things now. > Someone doing that today, who might start with FC3 or wait for FC4, > would have little to indicate that taking their release into Legacy > would be anything other than a change of repo in yum.conf. It would > be more honest and transparent if you wrote (and kept up after the > current transition was complete) that the most recent conversion to > Legacy took a month (or whatever it ends up being), in which time > users of those systems had an open security vulnerability, and that > you hope, but do not guarrantee, that the next transition will be > quicker (and sure, give a plug for more volunteers). I'll try to at least work something short to that effect into the FAQ, but I'm not sure I want that kind of info on the main page. But I do see your point and understand your point of view. > I'm not trying to rain on your parade here, though I think my words > will have that effect. I'm pointing out that there is a big gap > between the overall impression given about Legacy support and the > reality. And I appreciate your pointing it out, so that it does not continue. Unfortunately, I don't know everything about every part of the project. And communication within the project hasn't been great. Since no one else has taken an active role in the web site, it reflects my understanding of the project, right or wrong. > I'm also not laying blame or even saying that you have not > done the best you can with the resources you have. I'm saying that No, we have not done the best we could; we had yet another communication failure within the project. > the users can only care about the end result, and you serve them, > Fedora, and yourselves best if you are quite clear and open about what > you can in practice actually provide. It's not the place for > marketing-like glossovers of weaknesses. It is better to make an > honest impression than a good one. We strive to do this, really. We're not trying to lie, or exagerate. Any mistakes on the web site are honest mistakes. > --jh-- -- Eric Rostetter From rostetter at mail.utexas.edu Fri Apr 22 18:15:05 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 22 Apr 2005 13:15:05 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> Message-ID: <1114193705.32091648bf1d4@mail.ph.utexas.edu> Quoting Joe Harrington : > > They have the same format as the Red Hat Linux and Red Hat Enterprise > > Linux announcements instead, no? > > > * Most other distros do it our way (only Fedora Project differs that I know > > of, though there are probably others). > > Perhaps. My point is one of utility, not compatibility. I was > pointing out that FP does it this way to show what I like, not to > raise a compatibility point. Understood, but you asked for other's opinions, so you got it. > However, there is a compatibility point, now that you mention it. > People using this service are coming off of FP, not off some other > distro. At this time, subject to change in the future, most people in FLP are still using RHL versions, and hence they are used to this format from Red Hat, and not the Fedora Project format. So your point isn't technically correct yet, for the current community. This will change over time as RHL machines drop, and more FC users join the FLP. > It would be good to keep the same form of communication, > particularly where some people use automated means to process the > information. Matthew Miller mentioned to me that he also processes > those messages with scripts. As do I. But I use scripts which process the Red Hat version, not the Fedora Project version. This is probably because I run about 100 RHL machines, and 0 FC machines. ;) > If you are referring to people working on the project, I can see the > need for response/attention in under a day. For people using the > service in its recommended form (i.e., nightly yum updates), the > advisories are not so urgent, assuming their update systems are > working. The FLP does not recommend night yum updates via cron, which is what I think you are recommending here. Is this the recommendation of the Fedora Project? Red Hat and FLP both recommend you read the advisory notice *before* you install the update, as the advisory notice might have critical information in it about the update (installation order, problems with the installation you can expect, additional steps needed to complete the updates, etc). > > I don't like it, for the following reasons: > > > * More work for the people cutting updates (unless they can automate this > > more for the future) > > * More work for me (I update the advisories on the web site from the > e-mails > > sent to the announce list) > > These show a developer's point of view, not a user's (though on a > volunteer project with limited resources, it may be defensible to put > developers' needs over users'). It depends on the user. If the user assumes that he wants the updates out as soon as possible (since they are security updates), then he would not want to make more work for the people cutting the updates as that would slow them down. Okay, I conceed my second one is only more work for me, and the user probably doesn't care squat about the web page in most cases. You have me there. > > * Too many e-mails (and sometimes digest formats just aren't desirable). > > As a user, you'd like to be able to filter out the ones that are for > you, and preferably also check that you got the updates in an > automated way (by the way, I said in my post that I'd attach the > script and didn't, so see below). As a user, I very often want to know: 1) Whether an update *doesn't* apply to me. So I want to get all the updates, read them, and *know* that it doesn't apply to me. So if my boss, wife, who ever asks me "did you install the latest XYZ update?" or "should I install the latest XYZ update?" or "Why didn't you install the latest XYZ update?" or what ever, I can say with confidence "I researched the issue and that vulnerability doesn't apply in our case." > Jesse Keating said that the emails are sent automatically, written by > Python scripts. Yes, but the people who write them have, just recently, counterdicted him and said they all produce them by hand. Unless this has changed, then Jesse is wrong. So I'm not 100% sure of the story right now, but I think they are still done by hand. > It wouldn't be too outrageous to grab the scripts > from FP and have them post to a second list (or even a list per > release). I'm not against a separate list for individual notices. I just don't want to change the current list. I'm not sure Red Hat would let us set up a (more or less) infinite number of mailing lists though (one for each new release). And I'm not sure having two announce lists (one with individual and one with combined) wouldn't be more confusing than helpful. But I'm open to further discussion. > People would be able to subscribe to either and everyone > would be happy. My impression is that these scripts should not be > hard to maintain, particularly if you're grabbing one set from FP > rather than writing them yourselves. We can discuss this further, preferably with the input from those who create/maintain the scripts, and those who cut the updates/releases. > --jh-- -- Eric Rostetter From rostetter at mail.utexas.edu Fri Apr 22 18:23:32 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 22 Apr 2005 13:23:32 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050422040924.GA19424@jadzia.bu.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> Message-ID: <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> Quoting Matthew Miller : > On Thu, Apr 21, 2005 at 05:20:56PM -0500, Eric Rostetter wrote: > > You haven't convinced me. While you've provided reasons both for and > > against your argument, you've not managed to make me see why either way > > is really better. > > I think separating them is better for tracking purposes Please provide an argument to support that position. > and because it will > enable us to not hold up an advisory when one version is problematic but > another is fine. Since our current QA process will hold up the updates if any given version is help up, the advisory is of no concern here. So changing the advisory will not speed up releases. We'd need to change the QA process to do that. -- Eric Rostetter From ismanager at ccbnpts.com Fri Apr 22 19:00:55 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Fri, 22 Apr 2005 14:00:55 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114193705.32091648bf1d4@mail.ph.utexas.edu> Message-ID: <000c01c5476d$9cf35fd0$7202a8c0@ccb2vpjza> > Eric Rostetter wrote: > > Quoting Joe Harrington : [snip] > > It wouldn't be too outrageous to grab the scripts > > from FP and have them post to a second list (or even a list per > > release). > > I'm not against a separate list for individual notices. I just don't > want to change the current list. I'm not sure Red Hat would let us > set up a (more or less) infinite number of mailing lists though (one > for each new release). And I'm not sure having two announce lists > (one with individual and one with combined) wouldn't be more confusing > than helpful. But I'm open to further discussion. > Almost afraid to speak up but ... Why not use the existing, original, distro lists? They are still up and have people subscribed to them (I'm on the Valhalla and Shrike lists). RH seems to not be interested in closing them and they are archived automatically. Sounds like they'd be useful for the above but, meh, just me thinking out loud. Peace. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From rostetter at mail.utexas.edu Fri Apr 22 19:28:00 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 22 Apr 2005 14:28:00 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <000c01c5476d$9cf35fd0$7202a8c0@ccb2vpjza> References: <000c01c5476d$9cf35fd0$7202a8c0@ccb2vpjza> Message-ID: <1114198080.1c06c49b17275@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > Why not use the existing, original, distro lists? They are still up and have > people subscribed to them (I'm on the Valhalla and Shrike lists). RH seems > to not be interested in closing them and they are archived automatically. > Sounds like they'd be useful for the above but, meh, just me thinking out > loud. Sounds like an interesting idea actually. If we automatted the process of creating/sending the advisories, then this would be pretty trivial to do. If we adopted this, then that would help solve the issue. But i'm not sure if the other lists would object to this or not though, so we would have to ask permission on those lists before trying to do anything like this. Probably not so much of an issue for the old RHL lists, but probably more of an issue for the FC list (I think there is only one, not one for each release, but I'm not 100% sure). Something to consider at least. Not sure where I stand on it, or if we'd be "allowed" to, but I'll mull it over for a while... > Peace. -- Eric Rostetter From jh at oobleck.astro.cornell.edu Fri Apr 22 20:27:19 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 22 Apr 2005 16:27:19 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114193705.32091648bf1d4@mail.ph.utexas.edu> (message from Eric Rostetter on Fri, 22 Apr 2005 13:15:05 -0500) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> Message-ID: <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> > The FLP does not recommend night yum updates via cron, which is what I > think you are recommending here. Is this the recommendation of the > Fedora Project? If you type 'chkconfig yum on', you get nightly updates in FC. It's designed to do it, and since FC1 there have been no updates that required any special handling. Even the kernel gets updated this way, without problems. I don't see that there is any expectation that the notices will be read. I believe that RHEL operates this way, too, as do many/most distros nowadays (e.g., Debian Ubuntu, cAos). I don't know about official policy, but I also don't know anyone who would risk operating any other way. The net has become an increasingly dangerous place to compute. > As a user, I very often want to know: > 1) Whether an update *doesn't* apply to me. So I want to get all the > updates, read them, and *know* that it doesn't apply to me. So if my > boss, wife, who ever asks me "did you install the latest XYZ update?" > or "should I install the latest XYZ update?" or "Why didn't you install > the latest XYZ update?" or what ever, I can say with confidence "I researched > the issue and that vulnerability doesn't apply in our case." Sounds labor-intense to me. Why not just take them all when they come out? yum will figure out whether you have the package, and will update it if so. This seems to be what's done by the vast majority of users nowadays. Then you can just say "yes", "yes", and "it got it automatically the night after it hit the net" to the person asking the questions, without needing to look up from the novel you'll now have time to read. :-) If it's not the recommendation of FLP to do automatic nightly yum updates off your repos, it should be, as it will be the practice of most FC users regardless of what you recommend. If you make a point of advising otherwise, it will be a strong enough incentive for many people to switch away from Fedora completely, and go with a distro that does support it for the long term. FWIW, my FC1 machines have been doing fine operating in this mode off your repos, so it doesn't appear you need to do much, other than avoid making packages that require manual installation. --jh-- From jeremy at rosengren.org Fri Apr 22 20:54:38 2005 From: jeremy at rosengren.org (Jeremy Rosengren) Date: Fri, 22 Apr 2005 15:54:38 -0500 Subject: automatic nightly updates In-Reply-To: <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> Message-ID: <4269648E.2080104@rosengren.org> An HTML attachment was scrubbed... URL: From rostetter at mail.utexas.edu Fri Apr 22 21:13:34 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 22 Apr 2005 16:13:34 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> Message-ID: <1114204414.dd67f3cc152be@mail.ph.utexas.edu> Quoting Joe Harrington : > > The FLP does not recommend night yum updates via cron, which is what I > > think you are recommending here. Is this the recommendation of the > > Fedora Project? > > If you type 'chkconfig yum on', you get nightly updates in FC. It's Of course, but it is recommend, and if so, for what uses? > designed to do it, and since FC1 there have been no updates that > required any special handling. That's quite amazing... We've no end of things that need special handling here with the RHL releases (restarting daemons, upgrading versus updating, rebooting after a kernel update, etc). Even had some bugs (lilo update not working during a kernel update, etc). > Even the kernel gets updated this way, > without problems. As an example, it doesn't reboot to the new kernel. So that is an extra step that is needed. If I just do auto updates without checking what was done, how do I know I need to reboot to the new kernel? If I don't, then I'm not protected by the new security update to the kernel. Similar for restarting daemons, etc. > I don't see that there is any expectation that the > notices will be read. I believe that RHEL operates this way, too, as > do many/most distros nowadays (e.g., Debian Ubuntu, cAos). I can accept if Fedora Project does this, but I know of no other that does. If there was no need to read the advisory we simply wouldn't issue any advisories with the updates. > I don't > know about official policy, but I also don't know anyone who would > risk operating any other way. The net has become an increasingly > dangerous place to compute. See the archives recently about this, and/or refer to http://www.fedoralegacy.org/docs/autoupdates.php > > 1) Whether an update *doesn't* apply to me. So I want to get all the > > updates, read them, and *know* that it doesn't apply to me. So if my > > boss, wife, who ever asks me "did you install the latest XYZ update?" > > or "should I install the latest XYZ update?" or "Why didn't you install > > the latest XYZ update?" or what ever, I can say with confidence "I > researched > > the issue and that vulnerability doesn't apply in our case." > > Sounds labor-intense to me. That's why they call having a job "labor" because it is labor intensive. > Why not just take them all when they come > out? Because my boss will not accept the answer "I don't know if we need/have the update or not, but I turned on auto updates so it should be installing them if their needed, but I don't know for sure if there is an update yet or if I need to take other action to protect us in case there isn't an update yet, and I can't tell you for certain the repository I use is up and current so that it was really installed or not if there is an update, and..." By then he would stop me and fire me. > yum will figure out whether you have the package, and will > update it if so. This seems to be what's done by the vast majority of > users nowadays. Then you can just say "yes", "yes", and "it got it > automatically the night after it hit the net" to the person asking the > questions, without needing to look up from the novel you'll now have > time to read. :-) Well, how do I know this? At a minimum, I need to know that there is an update (either read the advisory or check the yum log), and I need to check that it was installed at least (check the yum log), and then I need to verify the update fixed the problem (reboot needed, daemon restart needed, etc). All this is something that simply issuing a "chkconfig yum on" won't do. > If it's not the recommendation of FLP to do automatic nightly yum > updates off your repos, it should be, as it will be the practice of > most FC users regardless of what you recommend. Please see above link. > If you make a point > of advising otherwise, it will be a strong enough incentive for many > people to switch away from Fedora completely, and go with a distro > that does support it for the long term. I don't think you will find any such distro. Even Microsoft doesn't recommend doing automated updates. > FWIW, my FC1 machines have > been doing fine operating in this mode off your repos, so it doesn't > appear you need to do much, other than avoid making packages that > require manual installation. See the archives from a couple weeks ago to see otherwise. > --jh-- -- Eric Rostetter From jimpop at yahoo.com Fri Apr 22 21:12:21 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 22 Apr 2005 17:12:21 -0400 Subject: automatic nightly updates In-Reply-To: <4269648E.2080104@rosengren.org> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> Message-ID: <1114204342.9638.16.camel@blue> On Fri, 2005-04-22 at 15:54 -0500, Jeremy Rosengren wrote: > RHEL does not do automatic nightly updates by default. If it did, > you'd have a *lot* of screaming software development companies out > there who rely on base patch levels on their build systems. I don't > recall any Linux distribution that I've tried recently having > automatic updates enabled by default. (Ubuntu, Fedora Core, RHEL) Hmmm, recent RH ES/WS installs that I have done *do* have rhnsd running by default. Of course this doesn't work without running rhn_register first. > Automatically updating packages without any kind of user initiation or > review process is a bad idea, imo, *regardless* of how non-invasive > anybody thinks those updates might be. Isn't that what RH's Management entitlement is all about? Heck, non- user initiation is like the holy grail of systems management, right? -Jim P. From jh at oobleck.astro.cornell.edu Fri Apr 22 21:26:02 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 22 Apr 2005 17:26:02 -0400 Subject: automatic nightly updates In-Reply-To: <4269648E.2080104@rosengren.org> (message from Jeremy Rosengren on Fri, 22 Apr 2005 15:54:38 -0500) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> Message-ID: <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> No, I don't think any distro enables them by default. But Fedora, Ubuntu, and RHEL all document and encourage the practice. Remember that there is a heavy cost to *not* updating, even for a short time, and the vast majority of users don't do manual updates, whether for lack of knowledge, time, or motivation. So it's a matter of choosing the better of two evils, for most people, and hence for the distros. If you consider that the source of your updates is the same as the source of your base OS, you should in principle be happy to get any improvements. Regarding non-invasiveness, anything truly malicious wouldn't advertize itself in the update email. Also, wouldn't someone producing such a thing put it in the base OS, to get a bigger audience? And in either case, it would be found and fixed quickly. You'd want automatic updates then for sure (of course, if the hack were any good, it would turn them off). --jh-- From jimpop at yahoo.com Fri Apr 22 21:40:43 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 22 Apr 2005 17:40:43 -0400 Subject: automatic nightly updates In-Reply-To: <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> Message-ID: <1114206044.9638.24.camel@blue> On Fri, 2005-04-22 at 17:26 -0400, Joe Harrington wrote: > No, I don't think any distro enables them by default. I just checked the timestamps on /etc/rc3.d/S97rhnsd on a few systems and they are all a few hours after all the other startup scripts. This leads me to think that the default install doesn't enable the rhnsd startup scripts but perhaps rhn_register does. -Jim P. From jh at oobleck.astro.cornell.edu Fri Apr 22 23:57:46 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 22 Apr 2005 19:57:46 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114204414.dd67f3cc152be@mail.ph.utexas.edu> (message from Eric Rostetter on Fri, 22 Apr 2005 16:13:34 -0500) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <1114204414.dd67f3cc152be@mail.ph.utexas.edu> Message-ID: <200504222357.j3MNvkee006952@oobleck.astro.cornell.edu> > > If you type 'chkconfig yum on', you get nightly updates in FC. It's > Of course, but it is recommend, and if so, for what uses? If you're not on FC now, you might not be aware that they average several updates a day. That might change your mind about examining each in detail. Most are bugfixes for the latest release (FC bleeds when released). About a third are security. A few are feature enhancements. > That's quite amazing... We've no end of things that need special handling > here with the RHL releases (restarting daemons, upgrading versus updating, > rebooting after a kernel update, etc). Even had some bugs (lilo update not > working during a kernel update, etc). One of the main design changes in the FC series of releases was to get the updates so they didn't have these issues, i.e., to make automatic updates possible and desirable (since RH wanted to sell that as a service under RHEL). Daemons are restarted in postinstall scripts. The kernel-related packages no longer break anything when installed but not booted. It doesn't reboot after a kernel install, obviously, you just get the new one by default next time you boot. Kernels are installed, not updated, so you always have all the kernels you ever had. If you don't like the new kernel, you select your old kernel in the boot menu. FC uses grub, not lilo, so those issues are gone. There's no need to do anything other than edit a text file to change the default kernel. If you're like most users and you don't reboot very often, it makes sense to subscribe to the email notices so you know when a new kernel is available for booting (and generally to track what's going on). I think they ought to email root at the machine in postinstall for a kernel, FWIW, but they don't. Upgrades are still done manually, and for FC I see that as crucial. New FC upgrades are *bleeding* edge, and generally many things break in the first few months. The nightly update script for Ubuntu, on the other hand, also does a distribution upgrade if it exists. That also seems appropriate, though still a bit risky, since they claim to shoot for stability from the get-go. FC people discourage full OS version upgrades with yum, though they're reported to work. Since this is the *Fedora* Legacy Project, why not set up an FC3 test box, turn on nightly updates, and see? :-) If you value stability, start with FC3 and ride it into Legacy. If you like to bleed, do FC4 test1... --jh-- From mattdm at mattdm.org Sat Apr 23 00:33:23 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 22 Apr 2005 20:33:23 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> Message-ID: <20050423003323.GA25451@jadzia.bu.edu> On Fri, Apr 22, 2005 at 01:23:32PM -0500, Eric Rostetter wrote: > Since our current QA process will hold up the updates if any given version > is help up, the advisory is of no concern here. So changing the advisory > will not speed up releases. We'd need to change the QA process to do > that. Right; see my post from a week or so ago. I think that's the way to go. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From mrallen1 at yahoo.com Sat Apr 23 00:19:02 2005 From: mrallen1 at yahoo.com (Mark Allen) Date: Fri, 22 Apr 2005 17:19:02 -0700 (PDT) Subject: New perl tool to parse fedora-legacy-announce archives Message-ID: <20050423001902.99592.qmail@web41205.mail.yahoo.com> With all the discussion over the past few days about wanting to automate a check to see if you have the RPMs in the fedora-legacy-announce bulletins, I wrote a quick perl script to parse through the announce archive files, check if they're installed on the local system, and then optionally, download them into a depot directory on the same local system. I created myself a Wiki page http://www.fedoralegacy.org/wiki/index.php/MarkAllen You can get the script there. Requires perl 5.8 and several CPAN modules (most people will have to install Email::MIME and Email::Folder). Everything else there is fairly standard Perl. YMMV. I'll gladly accept patches and I know this code isn't going to win any code beauty contests. But it seems to work for me. I may or may not gladly accept enhancement requests, but if want one/some/any, edit the Wiki and add it to the TODO. Best regards, --Mark From hjp+fedora-legacy at wsr.ac.at Sat Apr 23 11:16:51 2005 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Sat, 23 Apr 2005 13:16:51 +0200 Subject: automatic nightly updates In-Reply-To: <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> Message-ID: <20050423111651.GA9377@wsr.ac.at> On 2005-04-22 17:26:02 -0400, Joe Harrington wrote: > If you consider that the source of your updates is the same as the > source of your base OS, you should in principle be happy to get any > improvements. Regarding non-invasiveness, anything truly malicious > wouldn't advertize itself in the update email. I don't think we are talking about malicious updates here, just the risk associated with any change. No matter how careful the vendor tests the patches, they may still break something at the customers site. Also, some updates require a daemon to be restarted. So if you have to guarantee a certain service level, you don't want updates to happen at random times on your production servers. You want to test them on your test machines first, and when you are conviced they don't break anything you deploy them on the production servers at a time that is convenient to you. hp -- _ | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in |_|_) | Sysadmin WSR \the source, and you might run into a memory leak if | | | hjp at wsr.ac.at \you enable embedded haskell as a loadable module and __/ | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae at op5.se -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From mattdm at mattdm.org Sat Apr 23 15:07:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 23 Apr 2005 11:07:12 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114204414.dd67f3cc152be@mail.ph.utexas.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <1114204414.dd67f3cc152be@mail.ph.utexas.edu> Message-ID: <20050423150712.GA18215@jadzia.bu.edu> On Fri, Apr 22, 2005 at 04:13:34PM -0500, Eric Rostetter wrote: > As an example, it doesn't reboot to the new kernel. So that is an > extra step that is needed. If I just do auto updates without checking > what was done, how do I know I need to reboot to the new kernel? If > I don't, then I'm not protected by the new security update to the kernel. > Similar for restarting daemons, etc. I have a "kervercheck" script that runs nightly and e-mails root whenever you're running a kernel older than the latest one installed.... I'll try to get that into Fedora Extras.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From jimpop at yahoo.com Sat Apr 23 18:49:59 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 23 Apr 2005 14:49:59 -0400 Subject: automatic nightly updates In-Reply-To: <20050423111651.GA9377@wsr.ac.at> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> Message-ID: <1114282200.5787.12.camel@blue> On Sat, 2005-04-23 at 13:16 +0200, Peter J. Holzer wrote: > I don't think we are talking about malicious updates here, just the risk > associated with any change. No matter how careful the vendor tests the > patches, they may still break something at the customers site. Also, > some updates require a daemon to be restarted. So if you have to > guarantee a certain service level, you don't want updates to happen at > random times on your production servers. You want to test them on your > test machines first, and when you are conviced they don't break anything > you deploy them on the production servers at a time that is convenient > to you. I think you are speaking of one extreme, but there are also others. There are many customers of RedHat who buy hardware from the RH HW compatibility list specifically because they know RH tests on that hardware. This alleviates the customer from having to re-test and gets the fixes into production faster. Who is going to test better RH or the Customer's IT guy? <--- that's not a direct question, that's something to ponder. -Jim P. From lsomike at futzin.com Sat Apr 23 20:28:18 2005 From: lsomike at futzin.com (Mike Klinke) Date: Sat, 23 Apr 2005 15:28:18 -0500 Subject: automatic nightly updates In-Reply-To: <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> Message-ID: <200504231528.18923.lsomike@futzin.com> On Friday 22 April 2005 16:26, Joe Harrington wrote: > No, I don't think any distro enables them by default. ?But > Fedora, Ubuntu, and RHEL all document and encourage the practice. > ?Remember that there is a heavy cost to *not* updating, even for > a short time, and the vast majority of users don't do manual > updates, whether for lack of knowledge, time, or motivation. ?So > it's a matter of choosing the better of two evils, for most > people, and hence for the distros. > > If you consider that the source of your updates is the same as > the source of your base OS, you should in principle be happy to > get any improvements. ?Regarding non-invasiveness, anything truly > malicious wouldn't advertize itself in the update email. ?Also, > wouldn't someone producing such a thing put it in the base OS, to > get a bigger audience? ?And in either case, it would be found and > fixed quickly. You'd want automatic updates then for sure (of > course, if the hack were any good, it would turn them off). > > --jh-- ? For me unattended updates are too much like playing Russian Roulette with the health of my computers. ?I don't like finding something mysteriously broken and having to figure out what happened. When I manually update, yes, it still breaks but it's on my own time table and there's usually an immediate cause/effect relationship unless the problem is very subtle. ?I've lost count of how many times that updates through yum, Window's Update, McAfee's, etc. have broken something. Good case in point from yesterday ... follow the thread. http://archives.neohapsis.com/archives/fulldisclosure/2005-04/0511.html Regards, Mike Klinke From hjp+fedora-legacy at wsr.ac.at Sat Apr 23 22:02:52 2005 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Sun, 24 Apr 2005 00:02:52 +0200 Subject: automatic nightly updates In-Reply-To: <1114282200.5787.12.camel@blue> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> Message-ID: <20050423220251.GB9377@wsr.ac.at> On 2005-04-23 14:49:59 -0400, Jim Popovitch wrote: > On Sat, 2005-04-23 at 13:16 +0200, Peter J. Holzer wrote: > > I don't think we are talking about malicious updates here, just the risk > > associated with any change. No matter how careful the vendor tests the > > patches, they may still break something at the customers site. Also, > > some updates require a daemon to be restarted. So if you have to > > guarantee a certain service level, you don't want updates to happen at > > random times on your production servers. You want to test them on your > > test machines first, and when you are conviced they don't break anything > > you deploy them on the production servers at a time that is convenient > > to you. > > I think you are speaking of one extreme, but there are also others. > There are many customers of RedHat who buy hardware from the RH HW > compatibility list specifically because they know RH tests on that > hardware. This alleviates the customer from having to re-test and gets > the fixes into production faster. Who is going to test better RH or the > Customer's IT guy? <--- that's not a direct question, that's something > to ponder. There is no doubt that RH is testing a lot more thoroughly than almost any IT department can. But they can never test the exact HW/SW combination that will be running on the customer's machines, so local tests may still find problems that RH can't find. Also, if you test yourselves, RH doesn't stop testing. You don't have to decide whether you or RH are doing the tests. You decide whether you are testing in addition to RH. I admit that I can't remember if I ever caught a problem with a RH update during testing. I did catch problems with HP patches during testing, though. The main reason I don't use automatic updates is that I need to control when they happen. I can't have a samba or database server restart while somebody is running a batch job which takes several days. Unless its really urgent any update which may interrupt normal operation (if only for a few seconds) must be delayed until the next maintenance window. And its me who gets to decide whether is really urgent (and who has to explain that to my boss and our customers). hp -- _ | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in |_|_) | Sysadmin WSR \the source, and you might run into a memory leak if | | | hjp at wsr.ac.at \you enable embedded haskell as a loadable module and __/ | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae at op5.se -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From sfield97 at yahoo.com Sat Apr 23 21:18:47 2005 From: sfield97 at yahoo.com (Steve Field) Date: Sat, 23 Apr 2005 14:18:47 -0700 (PDT) Subject: FC2 x86-64 support vote Message-ID: <20050423211847.30590.qmail@web52606.mail.yahoo.com> FWIW I use FC2 x86-64 and would like to see FLP support this platform. I understand the priorities for i386, but if possible I'd like to see the x86-64 support. I also saw mention of downloading the source rpms and compiling them. I could also do that if there aren't enough resources. Could someone put together a quick page describing that process? Thanks for all your work. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From subsolar at subsolar.org Sun Apr 24 02:05:56 2005 From: subsolar at subsolar.org (Paul) Date: Sat, 23 Apr 2005 21:05:56 -0500 Subject: automatic nightly updates In-Reply-To: <1114282200.5787.12.camel@blue> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> Message-ID: <1114308356.4834.8.camel@azure> On Sat, 2005-04-23 at 14:49 -0400, Jim Popovitch wrote: > I think you are speaking of one extreme, but there are also others. > There are many customers of RedHat who buy hardware from the RH HW > compatibility list specifically because they know RH tests on that > hardware. This alleviates the customer from having to re-test and > gets > the fixes into production faster. Who is going to test better RH or > the > Customer's IT guy? <--- that's not a direct question, that's > something > to ponder. The customer's IT guy!!!! I've had RHEL updates break systems ... so I always uses test machines with the same hardware (or as close as possible) for any critical systems. RHEL updates go though significant QA and still can break things if you have an untested hardware combination. RH can't possibly test all combinations of hardware even for certified ones. Paul From pekkas at netcore.fi Sun Apr 24 06:02:02 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 24 Apr 2005 09:02:02 +0300 (EEST) Subject: FC2 x86-64 support vote In-Reply-To: <20050423211847.30590.qmail@web52606.mail.yahoo.com> References: <20050423211847.30590.qmail@web52606.mail.yahoo.com> Message-ID: On Sat, 23 Apr 2005, Steve Field wrote: > FWIW I use FC2 x86-64 and would like to see FLP > support this platform. > > I understand the priorities for i386, but if possible > I'd like to see the x86-64 support. > > I also saw mention of downloading the source rpms and > compiling them. I could also do that if there aren't > enough resources. Could someone put together a quick > page describing that process? I guess we could produce updates in a no-commitment, no-QA basis: if the src.rpm we produced for i386 recompiles for x64_86, we could publish it, but not require any publish or verify votes for it. It's already too difficult to get sufficient PUBLISH or VERIFY votes, so we must not add more requirements for publication. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From madlists at teaparty.net Mon Apr 25 09:15:12 2005 From: madlists at teaparty.net (Tom Yates) Date: Mon, 25 Apr 2005 10:15:12 +0100 (BST) Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050423003323.GA25451@jadzia.bu.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> Message-ID: On Fri, 22 Apr 2005, Matthew Miller wrote: > On Fri, Apr 22, 2005 at 01:23:32PM -0500, Eric Rostetter wrote: >> Since our current QA process will hold up the updates if any given version >> is help up, the advisory is of no concern here. So changing the advisory >> will not speed up releases. We'd need to change the QA process to do >> that. > > Right; see my post from a week or so ago. I think that's the way to go. as i've also said before, i too think this is the way to go. when a particular platform's release is VERIFIED, let it go. that would also ease absorbing eg x86-64 into FLP - a shortage of VERIFIES for uncommon platforms won't hold up the release of more popular platforms' fixes. -- Tom Yates - http://www.teaparty.net From schlitt at world.std.com Sun Apr 24 18:49:52 2005 From: schlitt at world.std.com (Dan Schlitt) Date: Sun, 24 Apr 2005 14:49:52 -0400 Subject: automatic nightly updates In-Reply-To: <1114308356.4834.8.camel@azure> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> Message-ID: I guess it is my paranoia from 15 years of system administration but I would never do unattended patching of any computer I really cared about. I have had patches for HP-UX and AIX cause serious problems and from the noises that occasionally came from the person at the desk next to me that also happens with Solaris patches. Why should I expect anything different for Red Hat or other distributions. It would be nice if yum had an option to just download the rpms. Then I could look at them and install them on my own schedule. But I haven't been able to detect such an option. /dan -- Dan Schlitt schlitt at world.std.com From jimpop at yahoo.com Mon Apr 25 18:02:53 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 25 Apr 2005 14:02:53 -0400 Subject: automatic nightly updates In-Reply-To: References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> Message-ID: <1114452174.5037.13.camel@localhost.localdomain> On Sun, 2005-04-24 at 14:49 -0400, Dan Schlitt wrote: > I guess it is my paranoia from 15 years of system administration but I > would never do unattended patching of any computer I really cared about. What about a cluster of 50+ webservers? I think part of this discussion needs to define what is applicable and what isn't. As has been previously stated there are cases when auto-update doesn't apply, i.e. complex database servers, etc. However for every case that can be made against auto-update, there is an alternate case for auto-update. Think of an enterprise with 1500 desktop PCs all around the world. Who is going to visit all locations to update? What about webserver farms? How about distributed internal DNS/NIS servers where the loss of one system isn't critical? etc, etc. People need to understand that every environment is unique and what doesn't work in one instance may very well work very well in another. -Jim P. From rostetter at mail.utexas.edu Mon Apr 25 18:41:01 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 13:41:01 -0500 Subject: automatic nightly updates In-Reply-To: <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> Message-ID: <1114454461.e34d6d3b26b32@mail.ph.utexas.edu> Quoting Joe Harrington : > No, I don't think any distro enables them by default. But Fedora, > Ubuntu, and RHEL all document and encourage the practice. Red Hat's Best Practices docs do *NOT* recommend auto updates. Of course, only "production level" people tend to follow Best Practices, and not "general users." I have no real problem with general users using auto updates, but I would say not too many "general users" are using Fedora Legacy either. Where do you think Red Hat recommends this at? I'd love to see any references people have. > Remember > that there is a heavy cost to *not* updating, even for a short time, > and the vast majority of users don't do manual updates, whether for > lack of knowledge, time, or motivation. So it's a matter of choosing > the better of two evils, for most people, and hence for the distros. I'll agree to that for "normal users" but not for those running production machines, research clusters, etc. > If you consider that the source of your updates is the same as the > source of your base OS, you should in principle be happy to get any > improvements. Heck, we test each new OS release before we put it in production, why wouldn't we do the same with the updates? > --jh-- -- Eric Rostetter From jkeating at j2solutions.net Mon Apr 25 18:41:21 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 11:41:21 -0700 Subject: automatic nightly updates In-Reply-To: <1114452174.5037.13.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> Message-ID: <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 14:02 -0400, Jim Popovitch wrote: > What about a cluster of 50+ webservers? > > I think part of this discussion needs to define what is applicable and > what isn't. As has been previously stated there are cases when > auto-update doesn't apply, i.e. complex database servers, etc. > However > for every case that can be made against auto-update, there is an > alternate case for auto-update. Think of an enterprise with 1500 > desktop PCs all around the world. Who is going to visit all locations > to update? What about webserver farms? How about distributed > internal > DNS/NIS servers where the loss of one system isn't critical? etc, > etc. > > People need to understand that every environment is unique and what > doesn't work in one instance may very well work very well in another. These scenarios are where you run internal update servers. You have a test lab that you use to validate upstream updates, then you populate your internal update systems with these updates. In these environments you also have scheduled times for updates, in case of breakage or reboots. You make it work. I have yet to see a scenario where automatic updates direct from the upstream vendor is a Good Idea on production systems. -- 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 jimpop at yahoo.com Mon Apr 25 18:33:07 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 25 Apr 2005 14:33:07 -0400 Subject: automatic nightly updates In-Reply-To: <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114453987.5637.9.camel@localhost.localdomain> On Mon, 2005-04-25 at 11:41 -0700, Jesse Keating wrote: > I have yet to see a scenario where automatic updates direct > from the upstream vendor is a Good Idea on production systems. You sort of just described such a system. It makes good sense to have one or two production servers auto-update. Those sames systems can then be quickly tested and then used as the update server for the internal system. What benefit do I gain by waiting on an email then manually downloading an update vs having the system automatically download and apply the update? Would you prefer Microsoft to automatically update end user systems (even small business Exchange systems hanging off a T1s everywhere), or do you think that it's best to wait on those people to get around to finally updating their virus ridden systems? I personally think a valid case can be made for vendors forcibly updating neglected systems. ;-) -Jim P. From rostetter at mail.utexas.edu Mon Apr 25 19:01:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 14:01:33 -0500 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <200504222357.j3MNvkee006952@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <1114204414.dd67f3cc152be@mail.ph.utexas.edu> <200504222357.j3MNvkee006952@oobleck.astro.cornell.edu> Message-ID: <1114455693.621f5c96dc9e2@mail.ph.utexas.edu> Quoting Joe Harrington : > > Of course, but it is recommend, and if so, for what uses? > > If you're not on FC now, you might not be aware that they average > several updates a day. That might change your mind about examining > each in detail. I'm not on FC, don't know anything about their release schedule, and no that doesn't change my mind one bit at all. > One of the main design changes in the FC series of releases was to get > the updates so they didn't have these issues, i.e., to make automatic > updates possible and desirable (since RH wanted to sell that as a > service under RHEL). First, that is the goal of most every project. But I've not seen any project that meets that goal. Second, no, RHEL was not about making patches that don't break things. It was about making a stable, 5-year support cycle for each release. You pay, in part, to get the help to resolve problems when they occur, not to guarantee they don't occur. > Daemons are restarted in postinstall scripts. That's what I would expect, but people on this list keep telling me that the RH policy is the exact opposite (which would surprise me, as RHL packages always restarted daemons on install, even restarting daemons not in the package being updated sometimes). I've not had time to look into any policy on this yet... Anyone have any pointers to RH policies like this? > The kernel-related packages no longer break anything when installed > but not booted. I've never seen one that did personally, but you don't get any updates if you don't boot to it... > Since this is the *Fedora* Legacy Project, why not set up an FC3 test > box, turn on nightly updates, and see? :-) Because the whole point of this is exactly as follows: Just because it works on one setup doesn't mean it will work on a different setup. Otherwise the whole issue would simply disappear. > --jh-- -- Eric Rostetter From jkeating at j2solutions.net Mon Apr 25 19:15:41 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 12:15:41 -0700 Subject: automatic nightly updates In-Reply-To: <1114453987.5637.9.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> Message-ID: <1114456541.19088.219.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 14:33 -0400, Jim Popovitch wrote: > You sort of just described such a system. It makes good sense to have > one or two production servers auto-update. No. Period. The autoupdating ones are the ones in the lab. Running as close to a config as the production systems as possible. THESE can auto-update for testing purposes. > Those sames systems can then > be quickly tested and then used as the update server for the internal > system. Bad idea. Don't autoupdate any production level system. If you can't have it go down at any time, don't allow auto updates. > What benefit do I gain by waiting on an email then manually > downloading an update vs having the system automatically download and > apply the update? Again, see above. > Would you prefer Microsoft to automatically update end user systems > (even small business Exchange systems hanging off a T1s everywhere), > or > do you think that it's best to wait on those people to get around to > finally updating their virus ridden systems? I personally think a > valid > case can be made for vendors forcibly updating neglected systems. ;-) I would never do business with a company that would want to install updates w/out my approval. People have the option to enable auto updates if they want. I personally have been bitten by way too many updates that failed in a particular configuration that just wasn't expected at the test labs at a vendor location. A vendor can't possibly test every permutation of how their update will effect running systems. They make a best effort and it is the end user's responsibility to plan, test, deploy, and test again to make sure the update doesn't cause any problems. Preferably with backups and a backout plan. No changes happen to production servers here without this. Because of that we haven't had an unexpected shutdown (minus hardware failure) in a very very very long time. -- 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 rostetter at mail.utexas.edu Mon Apr 25 19:23:20 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 14:23:20 -0500 Subject: automatic nightly updates In-Reply-To: <1114282200.5787.12.camel@blue> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> Message-ID: <1114457000.328f69792a6e2@mail.ph.utexas.edu> Quoting Jim Popovitch : > There are many customers of RedHat who buy hardware from the RH HW > compatibility list specifically because they know RH tests on that > hardware. This alleviates the customer from having to re-test and gets > the fixes into production faster. Who is going to test better RH or the > Customer's IT guy? We bought Dell PowerEdge 2650's which were certified by Red Hat *and* Dell to work. But a RH kernel update killed almost all of them... So much for buying from the Red Hat compatibility list. If both Red Hat and Dell missed the issue, and it took them months and multiple attempts to fix, what does that say about the issue? Heck, we even tested it on-site, but on lightly loaded machines, and didn't catch it. But we caught it almost immediately on a heavily loaded, critical production machine when we put it on there. So in this case even our own testing didn't work. But because of change control, we knew it had to be the kernel and backed it out. If we'd had a dozen automatted updates go in, how would we have even known which one (or combination of updates) caused it, or even know if it was related to the updates? -- Eric Rostetter From john at pybus.org Mon Apr 25 19:41:27 2005 From: john at pybus.org (John Pybus) Date: Mon, 25 Apr 2005 20:41:27 +0100 Subject: automatic nightly updates In-Reply-To: References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> Message-ID: <426D47E7.404@pybus.org> Dan Schlitt wrote: > I guess it is my paranoia from 15 years of system administration but I > would never do unattended patching of any computer I really cared about. What about those computers no-one "really cares" about? ;-) I don't do unattended updates on any computer I'm responsible for, not even on my test systems and desktops. But, I'd still support a default policy of automatic daily updates. Any sensible admin would turn it off and implement their own policy, and the rest (those who have presumably not responded to clear documentation of the default) would deserve untested updates of less assured reliability; many probably wouldn't mind. I know many 'administrators' of personal boxes, and even a number of groups of workstations and servers, where either no effort is made to apply updates, or only very sporadic effort. This includes RH7, RH9, FC1 and FC2 installs all now supported by FL (though I can't say how many have actually been configured to use FL repositories and how many are effectively abandoned). When others don't keep systems updated it affects me both by a greater general threat on the network from compromised boxes, and by lowering the reputation of the Linux systems I use. > It would be nice if yum had an option to just download the rpms. Then I > could look at them and install them on my own schedule. But I haven't > been able to detect such an option. This is something that'd be rather useful. As it is when my scripts warn me of impending updates I review them, run yum update and have to wait while they're fetched from a mirror. A version of yum check-update which pre-populated the RPM cache would be pretty handy. John From ingo at auroralinux.org Mon Apr 25 19:51:03 2005 From: ingo at auroralinux.org (Ingo T. Storm) Date: Mon, 25 Apr 2005 21:51:03 +0200 Subject: automatic nightly updates In-Reply-To: References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> Message-ID: <426D4A27.2060701@auroralinux.org> Dan Schlitt schrieb: > It would be nice if yum had an option to just download the rpms. It has - at least the releases I use. /usr/bin/yum --download-only update in a cron job should do exactly what you want. Ingo From jimpop at yahoo.com Mon Apr 25 19:24:44 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 25 Apr 2005 15:24:44 -0400 Subject: automatic nightly updates In-Reply-To: <1114456541.19088.219.camel@jkeating2.hq.pogolinux.com> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> <1114456541.19088.219.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114457084.5637.24.camel@localhost.localdomain> On Mon, 2005-04-25 at 12:15 -0700, Jesse Keating wrote: > On Mon, 2005-04-25 at 14:33 -0400, Jim Popovitch wrote: > > You sort of just described such a system. It makes good sense to have > > one or two production servers auto-update. > > No. Period. The autoupdating ones are the ones in the lab. Running as > close to a config as the production systems as possible. THESE can > auto-update for testing purposes. No, or yes. You start out saying "no", but end up saying "these can". > > Those sames systems can then > > be quickly tested and then used as the update server for the internal > > system. > > Bad idea. Don't autoupdate any production level system. If you can't > have it go down at any time, don't allow auto updates. Define "production level system" In my view, *any* system that is used in the course of business (be it for patch testing, or end-user facing) is a production system. I suppose that you can make the distinction between levels of systems (dev, test, acceptance, production?), but in my mind all those systems need to be up to vendor patch level else testing of a vendor patch is fruitless given the non-consistent environment. ...snip... > No changes happen to production servers here without this. Define "here". What is the environment there? -Jim P. From jh at oobleck.astro.cornell.edu Mon Apr 25 20:07:53 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Mon, 25 Apr 2005 16:07:53 -0400 Subject: automatic nightly updates In-Reply-To: <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> (message from Jesse Keating on Mon, 25 Apr 2005 11:41:21 -0700) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> Message-ID: <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> > I have yet to see a scenario where > automatic updates direct from the upstream vendor is a Good Idea on > production systems. Ok, here's one. My building has about 300 employees and one system manager. We're a university; that's what we can afford. Further, he's not an RHCE or an MSCE or anything else; he's a musician and this is his day job. We can't afford anyone with real credentials; they'd have to be paid more than the department chairman. Each person here has one or more computers. The mix is very heterogeneous, about evenly divided between Linux, Sun, Mac, and PC. The hardware is whatever was hot when the person bought the computer. There are no "recommended configurations" or anything like that; you get what you can get a good deal on and that fits your needs. Each senior person controls his own budget. Very few are people who would know what to do with a root password. The main tasks our system manager worries about are making new user accounts on the department's shared machines, installing and configuring new machines as people buy them, installing and configuring the third-party software they need, fixing hardware that breaks, and maintaining our servers. Needless to say, manually updating the 600 or so computers here is *low* on the system manager's list, but it's of course crucial that it happens, as are all the other things. So, automatic updates are the way we go. If an update were to break something (hasn't happened yet), people would squeal, he'd figure out what happened, and if there weren't another update forthcoming that fixed it, he'd write some scripts to back out the problem update and tell people to run them. Yup, folks, we're a zoo. And, the situation is the same in nearly every university department in the country, save for the mix of machines. Add onto our millions of machines those of private individuals, and you get a sizeable audience of people for whom auto update, no matter what the OS, is the best thing since the invention of ketchup. There are many situations where you wouldn't want auto update, some of which have been outlined here by people whose responsibilities cover them. In many of those situations, RH itself would tell the customer it should never be running Fedora, it should be running RHEL. Fedora's low cost and its declared experimental nature predisposes it to be run in situations like ours. If you don't believe that many people auto-update, do some statistics on your web servers for FC1. Calculate the *local* time of each request for the repo data (i.e., the first yum request). You'll have to do a lookup on the IP address and figure out what time zone they're in to do that. Then plot a histogram vs. local time. I'll bet money that you get more hits in the 4:00am - 6:00am range than during any other time. Cron.daily fires at 4:02 am and FC's scripts throw in a random delay of up to 2 hours. My point is simple: since auto update is very common and a good idea for many people, FLP should document the practice and gear its services to it. It means a little more care in putting the updates together, but not much, and certainly not more care than you are already taking. Gearing toward auto updates will not hurt manual updaters at all. Don't worry about making "formal recommendations" on whether to auto-update. Clearly, it's a good choice for some, a poor choice for others. Rather, write clear descriptions of the pros and cons. Anyone running Fedora is self-supported and had better be able to read the pros and cons and decide what best fits their particular situation best. --jh-- From jkeating at j2solutions.net Mon Apr 25 20:08:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 13:08:51 -0700 Subject: automatic nightly updates In-Reply-To: <1114457084.5637.24.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> <1114456541.19088.219.camel@jkeating2.hq.pogolinux.com> <1114457084.5637.24.camel@localhost.localdomain> Message-ID: <1114459731.19088.222.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 15:24 -0400, Jim Popovitch wrote: > Define "production level system" > > In my view, *any* system that is used in the course of business (be it > for patch testing, or end-user facing) is a production system. I > suppose that you can make the distinction between levels of systems > (dev, test, acceptance, production?), but in my mind all those systems > need to be up to vendor patch level else testing of a vendor patch is > fruitless given the non-consistent environment. > > ...snip... > > > No changes happen to production servers here without this. > > Define "here". What is the environment there? I see where our miscommunication is. To me a production server is one that is used in the day to day production of the company, users use it, services use it, etc.. A test lab system is not one of these systems. There is no loss of productivity if a test server crashes, especially if you're trying to make the test server crash. Think of it as the dogfood box next to your desk that you do test installs on and other random stuff, stuff you wouldn't want on your main workstation because it might crash. These are lab systems, not production servers. By 'here' I mean the company I work for and do IT for. -- 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 jkeating at j2solutions.net Mon Apr 25 20:11:30 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 13:11:30 -0700 Subject: automatic nightly updates In-Reply-To: <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> Message-ID: <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 16:07 -0400, Joe Harrington wrote: > My point is simple: since auto update is very common and a good idea > for many people, FLP should document the practice and gear its > services to it. It means a little more care in putting the updates > together, but not much, and certainly not more care than you are > already taking. Gearing toward auto updates will not hurt manual > updaters at all. We will NOT make it the practice and gear our services toward it. We will inform people how they can ENABLE autoupdate, with the caviat that we do not recommend it unless you are very clear on the risks involved and are willing to accept them. I will not accept risks FOR a user, that is up to the user to decide. Opt-in rather than opt-out. -- 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 jh at oobleck.astro.cornell.edu Mon Apr 25 20:40:52 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Mon, 25 Apr 2005 16:40:52 -0400 Subject: automatic nightly updates In-Reply-To: <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> (message from Jesse Keating on Mon, 25 Apr 2005 13:11:30 -0700) References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> Message-ID: <200504252040.j3PKeqev000422@oobleck.astro.cornell.edu> > We will NOT make it the practice and gear our services toward it. Relax. I didn't tell you to make it your practice. I said to *document* the practice prominently, and let people decide for themselves, which I think is what you also want. However, for anyone to be able to use it, you have to gear your services to it, by which I mean you have to avoid doing anything that would harm someone taking all your updates as they come out. As I said, I don't think you need to change how you handle the updates themselves. I'm talking about web site content, mainly, and also a level of awareness for any future situations that may come up. > I will not accept risks FOR a user, > that is up to the user to decide. Don't worry, as an unpaid, volunteer service, nobody has or can ask you to accept a risk for a user. That's also true of FP. Everyone in the Fedora world knows that the buck stops with them. > Opt-in rather than opt-out. Yes. That decision is made by FP when they choose the /etc/rc.d configuration to ship. --jh-- From jkeating at j2solutions.net Mon Apr 25 21:02:21 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 14:02:21 -0700 Subject: automatic nightly updates In-Reply-To: <200504252040.j3PKeqev000422@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> <200504252040.j3PKeqev000422@oobleck.astro.cornell.edu> Message-ID: <1114462941.19088.246.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 16:40 -0400, Joe Harrington wrote: > Relax. > > I didn't tell you to make it your practice. I said to *document* the > practice prominently, and let people decide for themselves, which I > think is what you also want. However, for anyone to be able to use > it, you have to gear your services to it, by which I mean you have to > avoid doing anything that would harm someone taking all your updates > as they come out. As I said, I don't think you need to change how you > handle the updates themselves. I'm talking about web site content, > mainly, and also a level of awareness for any future situations that > may come up. What content needs to change? Other than saying "you can do this, but we don't think you should for reasons A ~ X" I don't know what you want us to say. One of the 'risks' of automated updates is that we don't do anything in favor of automated updates, so you can wind up w/ package releases on the weekends and such. If you can accept that risk, go to it. > > I will not accept risks FOR a user, > > that is up to the user to decide. > > Don't worry, as an unpaid, volunteer service, nobody has or can ask > you to accept a risk for a user. That's also true of FP. Everyone in > the Fedora world knows that the buck stops with them. > > > Opt-in rather than opt-out. > > Yes. That decision is made by FP when they choose the /etc/rc.d > configuration to ship. I was under the impression that the nightly yum-cron job was shipping disabled. I see it may be enabled in FC4 which I highly disagree with, but unfortunately it may be too late to stop the change. That doesn't mean we have to eat that change. When we take in FC4, we can urge people to disable automatic updates and again warm them why they can be bad. Our user base is quite a bit different from the average user base of Fedora, so our users have different needs. Whats good enough for Fedora isn't allways good enough for Fedora Legacy. -- 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 jkeating at j2solutions.net Mon Apr 25 21:46:57 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 25 Apr 2005 14:46:57 -0700 Subject: automatic nightly updates In-Reply-To: <1114462941.19088.246.camel@jkeating2.hq.pogolinux.com> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> <200504252040.j3PKeqev000422@oobleck.astro.cornell.edu> <1114462941.19088.246.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114465617.19088.254.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-04-25 at 14:02 -0700, Jesse Keating wrote: > > I was under the impression that the nightly yum-cron job was shipping > disabled. I see it may be enabled in FC4 which I highly disagree > with, > but unfortunately it may be too late to stop the change. That doesn't > mean we have to eat that change. When we take in FC4, we can urge > people to disable automatic updates and again warm them why they can > be > bad. Our user base is quite a bit different from the average user > base > of Fedora, so our users have different needs. Whats good enough for > Fedora isn't allways good enough for Fedora Legacy. Ah HAH! I was correct. Yum nightly updates are NOT enabled by default in Fedora. It is purely opt-in, as it should be. I knew sanity would prevail! (I don't think there was any attempt to enable it, just some misinformation) -- 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 ismanager at ccbnpts.com Mon Apr 25 21:47:02 2005 From: ismanager at ccbnpts.com (Pettit, Paul) Date: Mon, 25 Apr 2005 16:47:02 -0500 Subject: automatic nightly updates In-Reply-To: <426D4A27.2060701@auroralinux.org> Message-ID: <004c01c549e0$50a6fc70$7202a8c0@ccb2vpjza> > Ingo T. Storm wrote: > > > Dan Schlitt schrieb: > > It would be nice if yum had an option to just download the rpms. > > It has - at least the releases I use. > > /usr/bin/yum --download-only update > > in a cron job should do exactly what you want. > > Ingo > And Ingo wins the award for the best response in this thread. Going to have to try that one out, thanks Ingo! ------ You know it's kind of humorous that this whole tread has happened again. I've refrained from posting as I'm still putting salve on the burns from the last time. It seems to me that there are many that feel very strongly on both sides and the sticking point is where people disagree on "common" practice. Until such time that all can agree on a universal rule on updates that everyone in the world signs off on, the best thing to do is do what you have been doing and that has worked till now. Just don't go looking for FL to take responsibility (not that *I* ever did) if you go the route of unattended auto-updating and something breaks. They only make sure you have the patch in a timely manner (and do a good job at that btw) and that it's had some kind of QA before they are available. Regardless of how many documents they put up, how many times they point out "best" practices, it's ultimately the system administrator's (i.e. your) job to make the call. If there is a chance that a patch will fubar your system(s), best to make sure YOU have it covered. Peace. Paul Pettit CTO and IS Manager Consistent Computer Bargains Inc. I've heard it said that the proof of lunacy is when you repeat the same steps expecting different results. I say it's proof that you're a Microsoft user. - comment by deshi777 on experts-exchange.com From agibson at ptm.com Mon Apr 25 22:30:19 2005 From: agibson at ptm.com (Adam Gibson) Date: Mon, 25 Apr 2005 18:30:19 -0400 Subject: automatic nightly updates In-Reply-To: <1114462941.19088.246.camel@jkeating2.hq.pogolinux.com> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> <1114459890.19088.225.camel@jkeating2.hq.pogolinux.com> <200504252040.j3PKeqev000422@oobleck.astro.cornell.edu> <1114462941.19088.246.camel@jkeating2.hq.pogolinux.com> Message-ID: <426D6F7B.8080502@ptm.com> Jesse Keating wrote: > I was under the impression that the nightly yum-cron job was shipping > disabled. I see it may be enabled in FC4 which I highly disagree with, I hope that FC4 sets a standard for the future as far as enabling updates by default... There is no way to satisfy everyone with enabling or disabling autoupdates by default. I have some systems that need manual updates. Some of which are customized too much and others that are too important to have downtime without someone to watch over the update process. I have other systems that are desktop systems that are I do not care if they break by getting a bad update. If it every happened I would just deal with it(haven't had a problem in 5 or 6 years). I have other systems that are desktop systems that are somewhere in the middle that sync off of a private mirror that only gets packages put on them after they are tested in my environment(autoupdate off of a custom mirror). Given all those scenarios, I would rather see auto-updates enabled by default. Desktops would get the updates without any tweaks. For the systems that I need to be updated differently, I have to tweak them anyway. This also makes sure that end users that just use Fedora for desktop use(which is a large percentage I bet) will be protected without reading any information on a website about how to enable auto-updates. I have a feeling there are quite a few systems that are installed by people that just want to see what Fedora/Linux is about and don't know the first thing about updates or the need to install them even if a big message was on the screen telling them so after every reboot. No matter what I say or anyone else says... nothing will work for everyone. I do personally think protecting people that are not very knowledgeable about Fedora/Linux should be the priority. From rostetter at mail.utexas.edu Mon Apr 25 22:31:05 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 17:31:05 -0500 Subject: automatic nightly updates In-Reply-To: <1114452174.5037.13.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> Message-ID: <1114468265.09a09f80e5c36@mail.ph.utexas.edu> Quoting Jim Popovitch : > On Sun, 2005-04-24 at 14:49 -0400, Dan Schlitt wrote: > > I guess it is my paranoia from 15 years of system administration but I > > would never do unattended patching of any computer I really cared about. > > What about a cluster of 50+ webservers? I see this no different that a cluster of 5 mail servers, or a stand-alone database server, or a single compute machine. If it is different, it is in that I can test things on one of the 50+ machines and find any problems there before I install it on the rest. > I think part of this discussion needs to define what is applicable and > what isn't. As has been previously stated there are cases when > auto-update doesn't apply, i.e. complex database servers, etc. However > for every case that can be made against auto-update, there is an > alternate case for auto-update. See the recently updated https://www.fedoralegacy.org/docs/autoupdates.php > Think of an enterprise with 1500 > desktop PCs all around the world. Who is going to visit all locations > to update? You don't need to. No one said you did. But that doesn't mean you should just have them all do auto updates from the vendor or a third party. > What about webserver farms? How about distributed internal > DNS/NIS servers where the loss of one system isn't critical? etc, etc. See above. It doesn't matter. Remember, you *can* apply updates automatically, from another source, after testing. Just don't forget to do the rest of the work up front. > People need to understand that every environment is unique and what > doesn't work in one instance may very well work very well in another. I think this is all addressed, though maybe not heavily, in the autoupdates.php web page. Not to mention the Red Hat, Microsoft, or a zillion other Best Practices Guides out there, all of which say don't use auto updates of untested software on production machines. > -Jim P. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Apr 25 22:39:31 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 17:39:31 -0500 Subject: automatic nightly updates In-Reply-To: <1114453987.5637.9.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> Message-ID: <1114468771.7a134b9ebc190@mail.ph.utexas.edu> Quoting Jim Popovitch : > system. What benefit do I gain by waiting on an email then manually > downloading an update vs having the system automatically download and > apply the update? The benefit that the e-mail might just tell you something important, like: * Install order of updates * Known problems or issues with the updates * Whether you need to update or not * How important the update is, so you can decide if you need it or not * Special installation instructions * Additional steps to take to complete the update process > Would you prefer Microsoft to automatically update end user systems > (even small business Exchange systems hanging off a T1s everywhere), or > do you think that it's best to wait on those people to get around to > finally updating their virus ridden systems? It is best for them to do it, so they don't have the problem that many of them had recently of installing the latest Server 2003 update on the Small Business Edition OS and hosing their entire system, hence shutting down their business, in the process. It was their own fault for automatically updating their SBE with Server 2003, when if they had read the announcement they would have seen that it was not supposed to be installed on SBE, though the automatic tools didn't enforce that. > I personally think a valid > case can be made for vendors forcibly updating neglected systems. ;-) Nope, sorry, legally they can't, unless you sign a contract with them to do so (see definition of "turn key system" for more information). Besides, this discussion is about users updating their own systems, not vendors updating their clients systems. > -Jim P. -- Eric Rostetter From jimpop at yahoo.com Mon Apr 25 22:26:25 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 25 Apr 2005 18:26:25 -0400 Subject: automatic nightly updates In-Reply-To: <1114468771.7a134b9ebc190@mail.ph.utexas.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> <1114468771.7a134b9ebc190@mail.ph.utexas.edu> Message-ID: <1114467985.8302.8.camel@localhost.localdomain> On Mon, 2005-04-25 at 17:39 -0500, Eric Rostetter wrote: > > > I personally think a valid > > case can be made for vendors forcibly updating neglected systems. ;-) > > Nope, sorry, legally they can't, You a lawyer now? ;-) > unless you sign a contract with them to do so (see definition > of "turn key system" for more information). See Microsoft (and presumably other) EULA. What does any of this have to do with turnkey systems? -Jim P. From rostetter at mail.utexas.edu Mon Apr 25 22:59:13 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 17:59:13 -0500 Subject: automatic nightly updates In-Reply-To: <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <200504252007.j3PK7rQ8000318@oobleck.astro.cornell.edu> Message-ID: <1114469953.d6c3829a88653@mail.ph.utexas.edu> Quoting Joe Harrington : > Ok, here's one. My building has about 300 employees and one system > manager. We're a university; that's what we can afford. This changes nothing. > The main tasks our system manager worries about are making new user > accounts on the department's shared machines, installing and > configuring new machines as people buy them, installing and > configuring the third-party software they need, fixing hardware > that breaks, and maintaining our servers. Well, hopefully he doesn't do auto updates on those servers and shared machines. > Needless to say, manually updating the 600 or so computers here is > *low* on the system manager's list, but it's of course crucial that it > happens, as are all the other things. So you split them into groups: * Servers, shared machines, etc. which get manual updates * Desktops/workstations that are critical, which get manual updates (e.g. administrative staff, payroll, purchasing, grades, enrollment, etc) * Other critical machines that need manual updates (the machine running the critical, long lasting experiment, etc). * Desktops/workstations that are not critical, which get auto updates (e.g. test machines, faculty machines, non-critical staff machines, etc). > So, automatic updates are the > way we go. Across the board? If so, best of luck to you. Or on non-critical machines? If so, then fine, good plan! > Yup, folks, we're a zoo. And, the situation is the same in nearly > every university department in the country, save for the mix of > machines. Not in any I've worked at, and I've worked at universities medium and large (no small ones, sorry). > There are many situations where you wouldn't want auto update, some of > which have been outlined here by people whose responsibilities cover > them. In many of those situations, RH itself would tell the customer > it should never be running Fedora, it should be running RHEL. Doesn't matter. Auto updates don't depend on FC or RHEL or Windows. The same issue no matter what OS you run. > If you don't believe that many people auto-update, do some statistics > on your web servers for FC1. We do think many people auto update. We just want to try to education people that doing so on production or business critical machines or security/access critical machines is a bad idea. > My point is simple: since auto update is very common and a good idea > for many people, FLP should document the practice and gear its > services to it. It does. > It means a little more care in putting the updates > together, but not much, and certainly not more care than you are > already taking. Gearing toward auto updates will not hurt manual > updaters at all. It requires no change in putting together updates. We already try to test the best we can. The more people we can get testing, the less of an issue it will become. But it doesn't/can't/won't change the fundamental argument. > Don't worry about making "formal recommendations" on whether to > auto-update. Clearly, it's a good choice for some, a poor choice for > others. Rather, write clear descriptions of the pros and cons. I've tried to do that, basically. Only positive feedback so far. > Anyone running Fedora is self-supported and had better be able to read > the pros and cons and decide what best fits their particular situation > best. This project, dispite its name, is about Red Hat Linux as much as Fedora. Let's not forget that. > --jh-- -- Eric Rostetter From jimpop at yahoo.com Mon Apr 25 22:30:53 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 25 Apr 2005 18:30:53 -0400 Subject: automatic nightly updates In-Reply-To: <1114468265.09a09f80e5c36@mail.ph.utexas.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114468265.09a09f80e5c36@mail.ph.utexas.edu> Message-ID: <1114468254.8302.11.camel@localhost.localdomain> On Mon, 2005-04-25 at 17:31 -0500, Eric Rostetter wrote: > > See the recently updated https://www.fedoralegacy.org/docs/autoupdates.php "Not Found The requested URL /docs/autoupdates.php was not found on this server." > > > Think of an enterprise with 1500 > > desktop PCs all around the world. Who is going to visit all locations > > to update? > > You don't need to. No one said you did. But that doesn't mean you should > just have them all do auto updates from the vendor or a third party. What's that RHN Management entitlement about then? You saying that RH should not be selling that? Ok. -Jim P. From rostetter at mail.utexas.edu Mon Apr 25 23:19:02 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 18:19:02 -0500 Subject: automatic nightly updates In-Reply-To: <004c01c549e0$50a6fc70$7202a8c0@ccb2vpjza> References: <004c01c549e0$50a6fc70$7202a8c0@ccb2vpjza> Message-ID: <1114471142.a052028382bea@mail.ph.utexas.edu> Quoting "Pettit, Paul" : > > Ingo T. Storm wrote: > > > > > Dan Schlitt schrieb: > > > It would be nice if yum had an option to just download the rpms. > > > > It has - at least the releases I use. > > > > /usr/bin/yum --download-only update > > > > in a cron job should do exactly what you want. > > > > Ingo > > > > And Ingo wins the award for the best response in this thread. Going to have > to try that one out, thanks Ingo! Agreed, except it doesn't work for most (or any?) of the FL yum versions, AFAIK. But, it is nice to know that yum has addressed the issue in newer versions. > You know it's kind of humorous that this whole tread has happened again. I bet it will happen more times in the future (probably every time someone gets burned by auto updates hosing their system). But, it has helped me refine the autoupdates.php document at least :) > Regardless of how many documents they put up, how many times they point out > "best" practices, it's ultimately the system administrator's (i.e. your) job > to make the call. If there is a chance that a patch will fubar your > system(s), best to make sure YOU have it covered. Exactly! > Peace. > > Paul Pettit > CTO and IS Manager > Consistent Computer Bargains Inc. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Apr 25 23:32:03 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 18:32:03 -0500 Subject: automatic nightly updates In-Reply-To: <1114467985.8302.8.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> <1114468771.7a134b9ebc190@mail.ph.utexas.edu> <1114467985.8302.8.camel@localhost.localdomain> Message-ID: <1114471923.8797b614013d9@mail.ph.utexas.edu> Quoting Jim Popovitch : > On Mon, 2005-04-25 at 17:39 -0500, Eric Rostetter wrote: > > > > > I personally think a valid > > > case can be made for vendors forcibly updating neglected systems. ;-) > > > > Nope, sorry, legally they can't, > > You a lawyer now? ;-) No. Sorry. Please ignore any legal advice I offer. > > unless you sign a contract with them to do so (see definition > > of "turn key system" for more information). > > See Microsoft (and presumably other) EULA. Which is a contract, which you must agree to. Okay, so you don't sign it. Rephrase it to read "agree to a contract" instead of "sign a contract" there. > What does any of this have to do with turnkey systems? It is one example of where you can agree to have someone maintain the software on the machine and modify it (e.g. update it) without your knowledge or per-instance consent. > -Jim P. Anyway, I'm done with this thread except for future responses addressing the web documentation of the issue. If anyone wants to comment on the docs about this please do. Anything else, well, fine also, but I'll try to stay out of it. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Apr 25 23:42:08 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 25 Apr 2005 18:42:08 -0500 Subject: automatic nightly updates In-Reply-To: <1114468254.8302.11.camel@localhost.localdomain> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <200504220114.j3M1EFpl002567@oobleck.astro.cornell.edu> <1114193705.32091648bf1d4@mail.ph.utexas.edu> <200504222027.j3MKRJJ7006529@oobleck.astro.cornell.edu> <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114468265.09a09f80e5c36@mail.ph.utexas.edu> <1114468254.8302.11.camel@localhost.localdomain> Message-ID: <1114472528.225cc0eaa13d3@mail.ph.utexas.edu> Quoting Jim Popovitch : > On Mon, 2005-04-25 at 17:31 -0500, Eric Rostetter wrote: > > > > See the recently updated https://www.fedoralegacy.org/docs/autoupdates.php > > "Not Found > The requested URL /docs/autoupdates.php was not found on this server." Heh, cute. I somehow mistyped it as an encrypted page which it isn't. Habit I guess from access secure sites all day. Just change https: to http: and it should work, ala: http://www.fedoralegacy.org/docs/autoupdates.php > > You don't need to. No one said you did. But that doesn't mean you should > > just have them all do auto updates from the vendor or a third party. > > What's that RHN Management entitlement about then? You saying that RH > should not be selling that? Ok. See their best practices guide. It allows you to set up a local, multi-level system for updates, and then update from that system after testing. Nice system really. It also means that when things do bust, they have to try to fix it for you. Which alone is worth its weight in gold. BTW, I hate the whole RHN thing, and don't use it as our lawyers won't bless the Red Hat language, and Red Hat hasn't been willing to work with our legal staff (negotiations are on-going still). But, it does have some good points in its design and implementation. And I can't totally blame Red Hat for not wanting to provide tech support to the world for free. > -Jim P. -- Eric Rostetter From mattdm at mattdm.org Tue Apr 26 00:02:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 20:02:12 -0400 Subject: automatic nightly updates In-Reply-To: <1114468771.7a134b9ebc190@mail.ph.utexas.edu> References: <4269648E.2080104@rosengren.org> <200504222126.j3MLQ2xx006728@oobleck.astro.cornell.edu> <20050423111651.GA9377@wsr.ac.at> <1114282200.5787.12.camel@blue> <1114308356.4834.8.camel@azure> <1114452174.5037.13.camel@localhost.localdomain> <1114454481.19088.211.camel@jkeating2.hq.pogolinux.com> <1114453987.5637.9.camel@localhost.localdomain> <1114468771.7a134b9ebc190@mail.ph.utexas.edu> Message-ID: <20050426000212.GA28954@jadzia.bu.edu> On Mon, Apr 25, 2005 at 05:39:31PM -0500, Eric Rostetter wrote: > The benefit that the e-mail might just tell you something important, > like: > * Install order of updates This should never be a problem with RPM. > * Known problems or issues with the updates If they're severe enough that the update shouldn't be applied, they're probably severe enough to prevent the update from being released in the first place. > * Whether you need to update or not I think that's also something that should be irrelevant here, since all of the updates for FL will be security fixes. > * How important the update is, so you can decide if you need it or not Ditto, really. (And if it's something that you might not need to update because it's not important to you, it probably won't hurt if it's auto-updated.) > * Special installation instructions Again, shouldn't happen. > * Additional steps to take to complete the update process Could happen -- but notification could happen after the update is applied. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From phendrick at bluefountain.com Tue Apr 26 11:23:39 2005 From: phendrick at bluefountain.com (Paul Hendrick) Date: Tue, 26 Apr 2005 12:23:39 +0100 Subject: running out of swap Message-ID: <1114514619.7841.23.camel@localhost.localdomain> we have a server running a script every night, and every night our memory usage jumps after it's run, eventually forcing the machine to crash when there's no swap space left. the script calls tar,gzip, postgres db_dumb and vacuumdb, then backs up the files to a tape. The memoy leaks are also occuring rarely even without the script being called, which is the cause of the confusion. I think it may be postgres leaking memory, but i don't know where or how to confirm this. does anybody have experience of this? the main memory intensive process on the box is python(it's running zope). postgres 7.4.5 zope 2.7.5 python 2.3.4 kernel 2.4.20 custom build. i'd really appreciate any thoughts! From nehresma at css.tayloru.edu Tue Apr 26 13:39:35 2005 From: nehresma at css.tayloru.edu (Nathan Ehresman) Date: Tue, 26 Apr 2005 08:39:35 -0500 Subject: running out of swap In-Reply-To: <1114514619.7841.23.camel@localhost.localdomain> References: <1114514619.7841.23.camel@localhost.localdomain> Message-ID: <20050426133935.GJ21832@css.tayloru.edu> On Tue, Apr 26, 2005 at 12:23:39PM +0100, Paul Hendrick wrote: > I think it may be postgres leaking memory, but i don't know where or > how to confirm this. does anybody have experience of this? I've never experienced this personally but try running top, and when it comes up pressing shift-M. That will sort by memory usage and show you the top processes. Nathan -- nre :wq From rostetter at mail.utexas.edu Tue Apr 26 19:39:40 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 26 Apr 2005 14:39:40 -0500 Subject: FC2 x86-64 support vote In-Reply-To: <20050423211847.30590.qmail@web52606.mail.yahoo.com> References: <20050423211847.30590.qmail@web52606.mail.yahoo.com> Message-ID: <1114544380.aa5b10fb60a15@mail.ph.utexas.edu> Quoting Steve Field : > I also saw mention of downloading the source rpms and > compiling them. I could also do that if there aren't > enough resources. Could someone put together a quick > page describing that process? I'm currently working on a doc for this. It will be a while until I get it ready for general use. If you want/need details before I get it officially up and running, let me know privately. -- Eric Rostetter From rostetter at mail.utexas.edu Tue Apr 26 20:52:49 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 26 Apr 2005 15:52:49 -0500 Subject: doc question for FC1/FC2 users In-Reply-To: <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1114548769.55ecdf97d8788@mail.ph.utexas.edu> Quoting Rob Myers : > On Wed, 2005-04-20 at 15:26 -0400, Chuck R. Anderson wrote: > > On Wed, Apr 20, 2005 at 02:20:10PM -0500, Eric Rostetter wrote: > > > > > > I've just updated the yum docs, and have a question about FC1 yum > (probably > > > FC2 also). In the docs, we have an example yum.conf which contains the > line: > > this may be a good time for you to revisit this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152801 > > rob. I think this bug should be closed. Reasons are: 1) Adding that line won't work for all cases (only works with FL yum, and FL yum not available for all releases, people use other yums, etc). 2) The page already says you should use the FL yum and the FL yum.conf instead if possible, which would give you the desired effect. 3) Using it can cause problems with unsigned packages, etc. (In particular if you mix other repos in, etc). 4) Using it requires additional steps (importing the needed gpg signatures, etc). 5) The gpg checks and keys are documented elsewhere. If anyone can explain to me otherwise, please do. But my feeling is this is a non-issue really, and the bug should be closed with a WONTFIX or whatever it is. -- Eric Rostetter From rostetter at mail.utexas.edu Tue Apr 26 21:08:39 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 26 Apr 2005 16:08:39 -0500 Subject: wording question In-Reply-To: References: Message-ID: <1114549719.855b39a2d9506@mail.ph.utexas.edu> Quoting David Eisenstein : > This sounds pretty good, Eric, though I am only finding the use of the > word "consensus" in our online docs a few places, and those mainly in the > wiki (nodes "UpdatedOverview" and "QaTesting"). Are there other places I > am not seeing it that you are concerned about? Perhaps not. But it is used by Jesse on the mailing list a lot. ;) > I guess it all depends upon what kinds of activities you feel we need to > use a "consent" model for. The various activities of our Project seem to > require different levels of control. Mostly this is for QA and package release, and for deciding whether to drop or add things (like when we dropped RHL 7.2 and RHL 8, or when we talked about adding RHL 7.1, etc). Things of that nature. It also came up with my proposed re-write of the overview. I was told to post it and try to get a consensus on it, but all I got was silence so it has never been updated. > Publishing things to the wiki, for I'm not worried about wiki things, mailing list postings, etc. I'm talking web site changes, policy changes, procedural changes, etc. > Basically, it seems like consent, the way you define it, is the way we're > doing things now anyway. Well, the overview rewrite has been dormant for months because we've not got a consensus on it, due to apathy. Right now, I can't update it on the web site because we don't have a concensus or veto. My changes would make this easier, as since no one is vetoing it or arguing against it, it could simply be put in place as-is. And one very bad problem (an overview of the project that in no way reflects reality) would be solved. > It is kinda the concept of "Do it now, and > apologize later," which gets results; a philosophy of "Don't do it until > you get permission," seems to cause things to languish, because nobody > remembers to give permission. This is exactly the situation we have now, and I'm proposing we change. My overview update is languishing because no one has given permission to update it, nor has anyone objected to updating it. In the current system, that means it is in limbo. In my proposed system, it could be moved into production since no one has said anything against it in the 6+ months it has been available for review. > HOWEVER -- in QA testing in the bugzilla, we must keep a permission (or > formal consent) model -- things mustn't be verified to updates-testing or > published to updates until there is (at least one, probably better two) > positive, PGP signed, votes from people doing QA work. QA cannot happen > without this kind of permission given. My system doesn't change this. We still have the rule that you must have X pgp-signed votes to publish. What it changes is that right now someone can veto it without a reason, where as in my version they would have to have a valid argument/reason to veto a publish. > It seems that, generally, if there is a negative comment given in > bugzilla, items do not move forward. In my system, the negative comment would have to be a valid argument against it, rather than just a negative comment. Other than that, it stays the same. > Instead of veto, maybe the idea of > "valid blocking issue," (or "Marc or Dominic veto" which is the same thing > 99% of the time ;-) ) or something like that, could be used. Right now we have the "Marc or Dominic veto" setup (except it also includes Jesse, etc). That is what I want to get away from, and into a "Someone has a valid reason not to publish" statement instead. And if no one has a valid reason not to publish, and it otherwise meets the publish criteria, then it is published. > By the way, Eric, I like what you have done with "How to use Bugzilla" on > the fedoralegacy.org website . > It looks pretty up-to-date in sync with our new bugzilla at Red Hat. :-) Thanks! > -David -- Eric Rostetter From rob.myers at gtri.gatech.edu Tue Apr 26 22:02:35 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Tue, 26 Apr 2005 18:02:35 -0400 Subject: doc question for FC1/FC2 users In-Reply-To: <1114548769.55ecdf97d8788@mail.ph.utexas.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> <1114548769.55ecdf97d8788@mail.ph.utexas.edu> Message-ID: <1114552955.32118.6.camel@rXm-581b.stl.gtri.gatech.edu> On Tue, 2005-04-26 at 15:52 -0500, Eric Rostetter wrote: > Quoting Rob Myers : > > > On Wed, 2005-04-20 at 15:26 -0400, Chuck R. Anderson wrote: > > > On Wed, Apr 20, 2005 at 02:20:10PM -0500, Eric Rostetter wrote: > > > > > > > > I've just updated the yum docs, and have a question about FC1 yum > > (probably > > > > FC2 also). In the docs, we have an example yum.conf which contains the > > line: > > > > this may be a good time for you to revisit this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152801 > > > > rob. > > I think this bug should be closed. Reasons are: > > 1) Adding that line won't work for all cases (only works with FL yum, and > FL yum not available for all releases, people use other yums, etc). gpg checking is available on a per repository basis. since all FL packages are signed it is reasonable to add it for the FL repository. > 2) The page already says you should use the FL yum and the FL yum.conf > instead if possible, which would give you the desired effect. we are talking about http://www.fedoralegacy.org/docs/yum-fc1.php right? the desired effect is to help people have secure updates by default. enabling gpg key in the sample yum.conf facilitates this. > 3) Using it can cause problems with unsigned packages, etc. (In particular > if you mix other repos in, etc). all FL packages are signed so it does not matter if this causes problems for unsigned packages or for other repos. > 4) Using it requires additional steps (importing the needed gpg signatures, > etc). i agree. it adds one additional step: the importation of FL's gpg key. this simple step is already included in step 2.2 of your documentation. > 5) The gpg checks and keys are documented elsewhere. by that flawed reasoning you shouldn't have any yum documentation on the fedoralegacy website. > If anyone can explain to me otherwise, please do. But my feeling is this > is a non-issue really, and the bug should be closed with a WONTFIX or > whatever it is. it should be clear that _i_ disagree with you on this, but what does everyone else think? rob. From marcdeslauriers at videotron.ca Wed Apr 27 04:29:47 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 27 Apr 2005 00:29:47 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> Message-ID: <1114576187.23656.3.camel@mdlinux> On Mon, 2005-04-25 at 10:15 +0100, Tom Yates wrote: > as i've also said before, i too think this is the way to go. when a > particular platform's release is VERIFIED, let it go. > > that would also ease absorbing eg x86-64 into FLP - a shortage of VERIFIES > for uncommon platforms won't hold up the release of more popular > platforms' fixes. I see two problems with releasing stuff one platform at a time: 1- It's a lot more work (and we're short on volunteers as it is...) 2- We'll get a ton of "When is the rhl9 update coming out?" and "Where can I download the FC1 update?" e-mails. Marc. -------------- 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 mattdm at mattdm.org Wed Apr 27 04:49:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Apr 2005 00:49:56 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114576187.23656.3.camel@mdlinux> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> Message-ID: <20050427044956.GA17977@jadzia.bu.edu> On Wed, Apr 27, 2005 at 12:29:47AM -0400, Marc Deslauriers wrote: > 1- It's a lot more work (and we're short on volunteers as it is...) Then we need to try and get infrastructure into place to make it not be a lot more work. Can you help me figure out exactly where the more work might be? Multiple bugzilla entries will be a bit more work, but because of the clone bug feature, I don't think it's a lot more. And there's a little more work on the mail announcement front, but that's mostly templates and cutting and pasting anyway. I know any amount of added work can be a *lot* when it's a short-staffed volunteer project, but I'm really a strong believer in the rewards of this one. > 2- We'll get a ton of "When is the rhl9 update coming out?" and "Where > can I download the FC1 update?" e-mails. And now we'll have somewhere to point them. :) Now, if one update is really basically available but the others aren't, it's some amount of work to look through a bug's history and figure that out. I think that simplifying that will make it easier to bring more people into working on QA. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From marcdeslauriers at videotron.ca Wed Apr 27 12:37:37 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 27 Apr 2005 08:37:37 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427044956.GA17977@jadzia.bu.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> Message-ID: <1114605457.31821.10.camel@mdlinux> On Wed, 2005-04-27 at 00:49 -0400, Matthew Miller wrote: > Then we need to try and get infrastructure into place to make it not be a > lot more work. Can you help me figure out exactly where the more work might > be? Multiple bugzilla entries will be a bit more work, but because of the > clone bug feature, I don't think it's a lot more. And there's a little more > work on the mail announcement front, but that's mostly templates and cutting > and pasting anyway. > It's pretty much 4 times more work... Well, we'll have to cut&paste and send out 4 advisories instead of 1. And each advisory will have to be a little different to reflect the actual security issue each release has, instead of just lumping them all in the same one even if certain issues didn't affect a particular release. We'll need to decide what we will do with the advisories we post to Bugtraq and Full Disclosure lists. Do we post 4 advisories to them for each bug? Do we wait until packages for every platform come out before posting a consolidated advisory to them? Do we just drop posting to Bugtraq and Full Disclosure alltogether? All this is to solve the problem of not having enough volunteers to QA and VERIFY packages. Shouldn't we be looking for more people to help out instead of increasing the workload to try and get a few things released faster? > Now, if one update is really basically available but the others aren't, it's > some amount of work to look through a bug's history and figure that out. I > think that simplifying that will make it easier to bring more people into > working on QA. With the QA whiteboard tags, it's really easy to figure out. Take a look at Dom's links page: http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Marc. -------------- 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 mattdm at mattdm.org Wed Apr 27 13:25:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Apr 2005 09:25:58 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114605457.31821.10.camel@mdlinux> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <1114605457.31821.10.camel@mdlinux> Message-ID: <20050427132558.GA30515@jadzia.bu.edu> On Wed, Apr 27, 2005 at 08:37:37AM -0400, Marc Deslauriers wrote: > It's pretty much 4 times more work... I respect your opinion on this a lot since you've been doing much of the work, but, c'mon, that's an exaggeration. Most of the per-release work is already being done -- building the package for each release, QAing it, etc. And I don't really think it's even 4x the paperwork. > Well, we'll have to cut&paste and send out 4 advisories instead of 1. > And each advisory will have to be a little different to reflect the > actual security issue each release has, instead of just lumping them all > in the same one even if certain issues didn't affect a particular > release. The advisories should already say which issues affect which releases, so that doesn't seem like much of a change. > We'll need to decide what we will do with the advisories we post to > Bugtraq and Full Disclosure lists. Do we post 4 advisories to them for > each bug? Do we wait until packages for every platform come out before > posting a consolidated advisory to them? Do we just drop posting to > Bugtraq and Full Disclosure alltogether? Fedora Core does 'em separately. > All this is to solve the problem of not having enough volunteers to QA > and VERIFY packages. Shouldn't we be looking for more people to help out > instead of increasing the workload to try and get a few things released > faster? That's only one of the things it helps solve. It also makes it much easier for actual end users (the point of the project, after all!) to track updates. And, making it more like the regular Fedora Core and Fedora Extras bug tracking makes it much easier to migrate bugs from there, and just to *work* in both worlds. And.... > With the QA whiteboard tags, it's really easy to figure out. > Take a look at Dom's links page: > http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt This seems like kludging a less-intuitive workflow on top of bugzilla, rather than really using bugzilla's primary tracking functionality. Are the status whiteboard tags documented somewhere? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From rostetter at mail.utexas.edu Wed Apr 27 14:33:02 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 09:33:02 -0500 Subject: doc question for FC1/FC2 users In-Reply-To: <1114552955.32118.6.camel@rXm-581b.stl.gtri.gatech.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> <1114548769.55ecdf97d8788@mail.ph.utexas.edu> <1114552955.32118.6.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1114612382.5101dc7268f26@mail.ph.utexas.edu> Quoting Rob Myers : > > I think this bug should be closed. Reasons are: > > > > 1) Adding that line won't work for all cases (only works with FL yum, and > > FL yum not available for all releases, people use other yums, etc). > > gpg checking is available on a per repository basis. since all FL > packages are signed it is reasonable to add it for the FL repository. I didn't know it was availabler per repository. Noted. > > 2) The page already says you should use the FL yum and the FL yum.conf > > instead if possible, which would give you the desired effect. > > we are talking about http://www.fedoralegacy.org/docs/yum-fc1.php right? No, the bug is about http://www.fedoralegacy.org/download/ I wouldn't mind adding it the page you mention though, if it is indeed supported as you say. Do you want it added to the [main] stanza or to each of the repo stanzas? > > 3) Using it can cause problems with unsigned packages, etc. (In particular > > if you mix other repos in, etc). > > all FL packages are signed so it does not matter if this causes problems > for unsigned packages or for other repos. I'm not sure that is a valid argument, but I'll allow it anyway. > > 4) Using it requires additional steps (importing the needed gpg signatures, > > etc). > > i agree. it adds one additional step: the importation of FL's gpg key. > this simple step is already included in step 2.2 of your documentation. On the doc you reference yes, but not in the doc the bug references. > > 5) The gpg checks and keys are documented elsewhere. > > by that flawed reasoning you shouldn't have any yum documentation on the > fedoralegacy website. Well, this is probably just an issue that we're refering to different docs. > > If anyone can explain to me otherwise, please do. But my feeling is this > > is a non-issue really, and the bug should be closed with a WONTFIX or > > whatever it is. > > it should be clear that _i_ disagree with you on this, but what does > everyone else think? I'm not sure we disagree, since we're talking about different docs. The bug references the download page, you reference the FC1 yum docs. > rob. -- Eric Rostetter From rob.myers at gtri.gatech.edu Wed Apr 27 14:58:46 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Wed, 27 Apr 2005 10:58:46 -0400 Subject: doc question for FC1/FC2 users In-Reply-To: <1114612382.5101dc7268f26@mail.ph.utexas.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> <1114548769.55ecdf97d8788@mail.ph.utexas.edu> <1114552955.32118.6.camel@rXm-581b.stl.gtri.gatech.edu> <1114612382.5101dc7268f26@mail.ph.utexas.edu> Message-ID: <1114613926.3152.20.camel@rXm-581b.stl.gtri.gatech.edu> On Wed, 2005-04-27 at 09:33 -0500, Eric Rostetter wrote: > Quoting Rob Myers : > > > > I think this bug should be closed. Reasons are: > > > > > > 1) Adding that line won't work for all cases (only works with FL yum, and > > > FL yum not available for all releases, people use other yums, etc). > > > > gpg checking is available on a per repository basis. since all FL > > packages are signed it is reasonable to add it for the FL repository. > > I didn't know it was availabler per repository. Noted. > > > > 2) The page already says you should use the FL yum and the FL yum.conf > > > instead if possible, which would give you the desired effect. > > > > we are talking about http://www.fedoralegacy.org/docs/yum-fc1.php right? > > No, the bug is about http://www.fedoralegacy.org/download/ okay, i corrected the urls in the bug... > I wouldn't mind adding it the page you mention though, if it is indeed > supported as you say. Do you want it added to the [main] stanza or > to each of the repo stanzas? i think it should be added to each stanza because that will preclude breaking any other repos that may be set up. what do you think? these things become easier when we're all on the same page. :) thanks for clearing that up eric. rob. From marcdeslauriers at videotron.ca Wed Apr 27 15:33:52 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 27 Apr 2005 11:33:52 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427132558.GA30515@jadzia.bu.edu> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <1114605457.31821.10.camel@mdlinux> <20050427132558.GA30515@jadzia.bu.edu> Message-ID: <1114616032.567.18.camel@mdlinux> On Wed, 2005-04-27 at 09:25 -0400, Matthew Miller wrote: > On Wed, Apr 27, 2005 at 08:37:37AM -0400, Marc Deslauriers wrote: > > It's pretty much 4 times more work... > > I respect your opinion on this a lot since you've been doing much of the > work, but, c'mon, that's an exaggeration. Most of the per-release work is > already being done -- building the package for each release, QAing it, etc. > And I don't really think it's even 4x the paperwork. > I only meant more work preparing the advisories, not doing QA and everything. If people prefer having it that way, I'll gladly do it. > > We'll need to decide what we will do with the advisories we post to > > Bugtraq and Full Disclosure lists. Do we post 4 advisories to them for > > each bug? Do we wait until packages for every platform come out before > > posting a consolidated advisory to them? Do we just drop posting to > > Bugtraq and Full Disclosure alltogether? > > Fedora Core does 'em separately. Yes, but they're not sent to Bugtraq or Full Disclosure. If it's okay to send 16 different advisories out to those lists when we have 4 fixed packages, then I don't mind doing it. > That's only one of the things it helps solve. It also makes it much easier > for actual end users (the point of the project, after all!) to track > updates. And, making it more like the regular Fedora Core and Fedora Extras > bug tracking makes it much easier to migrate bugs from there, and just to > *work* in both worlds. > OK, you've convinced me. I agree that the bugs would be easier to track if we had a separate bug per release. > > With the QA whiteboard tags, it's really easy to figure out. > > Take a look at Dom's links page: > > http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt > > This seems like kludging a less-intuitive workflow on top of bugzilla, > rather than really using bugzilla's primary tracking functionality. Are the > status whiteboard tags documented somewhere? Dom sent a mail to this list on Apr 12 to document the tags. You are absolutely right that it's a bad kludge. The problem is we're using Red Hat's bugzilla, so it's built-in tracking functionality doesn't work for Fedora Legacy. Instead of Red Hat's "Assigned" and "Need Info" statuses, we would need something like "Needs Work", "Needs PUBLISH", "Needs BUILD", "Needs VERIFY", "Needs Release". I am not a bugzilla expert, does someone know if different statuses can be created per product? Marc. -------------- 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 michal at harddata.com Wed Apr 27 17:10:42 2005 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 27 Apr 2005 11:10:42 -0600 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427044956.GA17977@jadzia.bu.edu>; from mattdm@mattdm.org on Wed, Apr 27, 2005 at 12:49:56AM -0400 References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> Message-ID: <20050427111042.A28262@mail.harddata.com> On Wed, Apr 27, 2005 at 12:49:56AM -0400, Matthew Miller wrote: > Multiple bugzilla entries will be a bit more work, but because of the > clone bug feature, I don't think it's a lot more. Multiple bugzilla entries will be actually tons of more work. My guess would be a bigger factor than just simple multiply by a number of entries. Majority of bugs actually closely related across distributions and an information if and how something was fixed for another package version helps a lot. Even if a fix does not apply directly, and often does or something pretty close can be made, an information how this was done elsewhere is valuable; both in an assesment of an impact and in making a patch. I already have substantial troubles in finding Legacy bugs. https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Legacy does produce some listing but this does not seem to be in any discernible order and searching through that, even if you have some idea what you are searching for, is difficult and takes time. Maybe I am not sufficiently conversant with bugzilla searches but I do not see how easily to filter out, for example, all CLOSED bugs from that pile. Make that haystack even bigger and force me to do repeated searches so I can be reasonably sure that I found all releated information I may need and I think that I will simply give up. > And there's a little more > work on the mail announcement front, but that's mostly templates and cutting > and pasting anyway. OTOH without a very careful tracking of everything you are now loosing an information was this problem a distro specific, was it already fixed somewhere else, will be ever fixed, and so on ... It seems that this split is proposed as a remedy for a situation when updates are waiting very long for releases. Somehow I doubt if this will help very much here. IMO "release early, release often" policy from the very beginning would have much bigger gains than losses in an overall picture, and it would help with that problem too, but it appears that I am in a minority position here. Michal From rostetter at mail.utexas.edu Wed Apr 27 17:36:40 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 12:36:40 -0500 Subject: doc question for FC1/FC2 users In-Reply-To: <1114613926.3152.20.camel@rXm-581b.stl.gtri.gatech.edu> References: <1114024810.ce36a23df6d96@mail.ph.utexas.edu> <20050420192657.GH4369@angus.ind.WPI.EDU> <1114026492.3552.295.camel@rXm-581b.stl.gtri.gatech.edu> <1114548769.55ecdf97d8788@mail.ph.utexas.edu> <1114552955.32118.6.camel@rXm-581b.stl.gtri.gatech.edu> <1114612382.5101dc7268f26@mail.ph.utexas.edu> <1114613926.3152.20.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1114623400.fc475cffeaa25@mail.ph.utexas.edu> Quoting Rob Myers : > > > gpg checking is available on a per repository basis. since all FL > > > packages are signed it is reasonable to add it for the FL repository. > > > > I didn't know it was availabler per repository. Noted. I've decided to go the per-repository route for FC releases. I'll keep the global approach for RHL. > > > > 2) The page already says you should use the FL yum and the FL yum.conf > > > > instead if possible, which would give you the desired effect. > > > > > > we are talking about http://www.fedoralegacy.org/docs/yum-fc1.php right? > > > > No, the bug is about http://www.fedoralegacy.org/download/ > > okay, i corrected the urls in the bug... I've updated the FC1 and FC2 pages. Please review my change, and close the bug if you are satisfied. > these things become easier when we're all on the same page. :) > > thanks for clearing that up eric. Yes, much easier if we are all talking about the same thing ;) > rob. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 27 18:25:40 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 13:25:40 -0500 Subject: bugzilla whiteboard info Message-ID: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> Can someone write up info about the use of the whiteboard status field in the Red Hat Bugzilla, to be added to the web page at http://www.fedoralegacy.org/docs/bugzilla.php ? For example, I just added some VERIFY votes to a bug there, and feel that maybe that means I should update the whiteboard, but I'm not sure if I should, and if I should I don't know how (what contents I should add or remove) I should do it... Text sent to me, the list, would be great. Plain text, diff/patch output, whatever, I'll make it work no matter what format you submit. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 27 20:19:42 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 15:19:42 -0500 Subject: FC2 transition progress update Message-ID: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> Can anyone provide a FC2 transition update? Where are we at on it? -- Eric Rostetter From jkeating at j2solutions.net Wed Apr 27 20:27:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 27 Apr 2005 13:27:51 -0700 Subject: FC2 transition progress update In-Reply-To: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> References: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> Message-ID: <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> On Wed, 2005-04-27 at 15:19 -0500, Eric Rostetter wrote: > Can anyone provide a FC2 transition update? Where are we at on it? Waiting for me to fix up mach on the build system to handle FC2, and to adjust a few little things on the master mirror. Should be done tonight so that we can start building packages. Do we have proper instructions for modifying yum/apt/up2date for hitting our repositories? -- 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 rostetter at mail.utexas.edu Wed Apr 27 20:36:35 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 15:36:35 -0500 Subject: FC2 transition progress update In-Reply-To: <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> References: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114634195.f4f3f76ce4aab@mail.ph.utexas.edu> Quoting Jesse Keating : > On Wed, 2005-04-27 at 15:19 -0500, Eric Rostetter wrote: > > Can anyone provide a FC2 transition update? Where are we at on it? > > Waiting for me to fix up mach on the build system to handle FC2, and to > adjust a few little things on the master mirror. Should be done tonight > so that we can start building packages. Sounds good. Let me know when things are done/ready. > Do we have proper instructions for modifying yum/apt/up2date for hitting > our repositories? I've been holding most of the updates until you tell me things are ready to go. Doesn't make sense to have docs/instructions/etc out there that don't work... Most of them exist in CVS, just not live on the web site. BTW, you will need to update the list of OS versions at download.fedoralegacy.org when you are ready, since I don't have access to that page. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Apr 27 20:49:08 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 27 Apr 2005 15:49:08 -0500 Subject: FC2 transition progress update In-Reply-To: <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> References: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> Message-ID: <1114634948.5e170f2a81c5e@mail.ph.utexas.edu> Quoting Jesse Keating : > Do we have proper instructions for modifying yum/apt/up2date for hitting > our repositories? I've updated the FC2 blurb on the main page, and released all FC info on the web site. Comments, suggestions, fixes, submissions, etc. all welcome. -- Eric Rostetter From cradle at umd.edu Wed Apr 27 21:29:50 2005 From: cradle at umd.edu (David Eisner) Date: Wed, 27 Apr 2005 17:29:50 -0400 Subject: FC2 transition progress update In-Reply-To: <1114634948.5e170f2a81c5e@mail.ph.utexas.edu> References: <1114633182.a70e34b8bcc4a@mail.ph.utexas.edu> <1114633671.6151.98.camel@jkeating2.hq.pogolinux.com> <1114634948.5e170f2a81c5e@mail.ph.utexas.edu> Message-ID: <4270044E.1070500@umd.edu> Eric Rostetter wrote: >I've updated the FC2 blurb on the main page, and released all FC info >on the web site. Comments, suggestions, fixes, submissions, etc. all >welcome. > > A few minor nits: ---snip--- At this time, we are only focusing on the i386 support. x86_64 support is not currently being supported. If we have sufficient community interest in the x86_64 support, and can build the needed infrastructure to build and test x86_64 packages, then support for them will be added. ---snip--- I would change this to: "At this time, we are focusing on providing i386 support. The x86_64 architecture is not currently supported. If there is sufficient community interest in supporting x86_64, and if the necessary build and test infrastructure can be assembled, then support for this architecture will be added." ---snip--- Initial FC2 documentation and information is now being released to the web site. ---snip--- I would change this to: "Initial FC2 documentation and information are now being released to the web site." -David From mattdm at mattdm.org Wed Apr 27 21:51:00 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Apr 2005 17:51:00 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427111042.A28262@mail.harddata.com> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <20050427111042.A28262@mail.harddata.com> Message-ID: <20050427215100.GA14098@jadzia.bu.edu> On Wed, Apr 27, 2005 at 11:10:42AM -0600, Michal Jaegermann wrote: > I already have substantial troubles in finding Legacy bugs. > https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Legacy > does produce some listing but this does not seem to be in any > discernible order and searching through that, even if you have some > idea what you are searching for, is difficult and takes time. Maybe > I am not sufficiently conversant with bugzilla searches but I do not > see how easily to filter out, for example, all CLOSED bugs from that > pile. Make that haystack even bigger and force me to do repeated > searches so I can be reasonably sure that I found all releated > information I may need and I think that I will simply give up. More posting later. For now, just this: it's very easy to do better and more targetted queries with bugzilla -- but unfortunately it's hard to make short pretty URLs that do so. For example: https://bugzilla.redhat.com/beta/buglist.cgi?product=Fedora+Legacy&bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=REOPENED is everything in open states. But then, look at the "Remember search" thing at the bottom of the page. Once you've made the searches you want, you can create memorized searches and they show up at the bottom of each page. (Or, of course, you can bookmark 'em.) But as Marc points out, the workflow in Red Hat's slightly weird bugzilla doesn't map to the FL workflow very well -- ironically, much worse than that in the default bugzilla. I'm going to talk to the RH bugzilla guys and see what we can figure out about that. > It seems that this split is proposed as a remedy for a situation > when updates are waiting very long for releases. Somehow I doubt No, actually, it's proposed as a remedy for a situation where it's hard to find things in bugzilla. Really! Not tying up releases is a pleasant side effect. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From michal at harddata.com Wed Apr 27 22:54:16 2005 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 27 Apr 2005 16:54:16 -0600 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427215100.GA14098@jadzia.bu.edu>; from mattdm@mattdm.org on Wed, Apr 27, 2005 at 05:51:00PM -0400 References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <20050427111042.A28262@mail.harddata.com> <20050427215100.GA14098@jadzia.bu.edu> Message-ID: <20050427165416.A2081@mail.harddata.com> On Wed, Apr 27, 2005 at 05:51:00PM -0400, Matthew Miller wrote: > > it's very easy to do better and more > targetted queries with bugzilla -- but unfortunately it's hard to make short > pretty URLs that do so. For example: > > https://bugzilla.redhat.com/beta/buglist.cgi?product=Fedora+Legacy&bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=REOPENED This I can do but there does not seem to be a way to do that via a web interface unless status options happen to consist one interval. Otherwise you have to type everything (well, at least once without any misteakes, and yes, the previous word is not a mistake, and save that as a bookmark for any possible combination which you may want - and this can be quite a few). I would really like to have things of a 'bug_status!=CLOSED' sort but that does not seem to be available. A way to specify sort criteria is also absent and how results are sorted, if sorted at all, is somewhat mysterious. > > But then, look at the "Remember search" thing at the bottom of the > page. If you search always the same way. Now if you will spread bug reports a number of searches you will have to "remember" will grow exponentially. Michal From mattdm at mattdm.org Wed Apr 27 23:07:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Apr 2005 19:07:19 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <20050427165416.A2081@mail.harddata.com> References: <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <20050427111042.A28262@mail.harddata.com> <20050427215100.GA14098@jadzia.bu.edu> <20050427165416.A2081@mail.harddata.com> Message-ID: <20050427230719.GA2832@jadzia.bu.edu> On Wed, Apr 27, 2005 at 04:54:16PM -0600, Michal Jaegermann wrote: > This I can do but there does not seem to be a way to do that via a > web interface unless status options happen to consist one interval. > Otherwise you have to type everything (well, at least once without > any misteakes, and yes, the previous word is not a mistake, and save > that as a bookmark for any possible combination which you may want - > and this can be quite a few). I would really like to have things of > a 'bug_status!=CLOSED' sort but that does not seem to be available. You can do this easily with the standard search form. You end up with a *super* long URL mostly consisting of "value1=&value2=&value3=" -- I just stripped those out. But there's no problem leaving them in for bookmarks or memorized searches -- or just searching again. I agree that it's annoying that there's no search checkbox for "all open states" -- instead, you have to select all four such states in the list box. But if you make having those options selected be the default search (again, easily done) then every time you go to the search page, that'll be already done. You then can hit search to get the current complete list of open issues, or add further restrictions (select the kernel component from that list, or highlight the release versions you want to look at). > > But then, look at the "Remember search" thing at the bottom of the > > page. > If you search always the same way. Now if you will spread bug > reports a number of searches you will have to "remember" will grow > exponentially. Nah, just linearly, unless you really need to have memorized searches that include all various possible *combinations* of releases. For my own bugzilla, which has three currently-supported releases, I have three memorized queries for each: Velouria Open <- new, in progress, etc. Fixed <- package built, awaiting QA Verified <- passed QA, awaiting "publication" Bossanova Open Fixed Verified Doolittle Open Fixed Verified And then I also have an "Unconfirmed" which shows all newly-filed incoming bugs in all releases, and "Assigned to Me" for the ones where I'm the bug assignee and "QA for me" for when I'm the QA contact. Okay, I really have to go. More later. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From dom at earth.li Thu Apr 28 09:27:34 2005 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 28 Apr 2005 10:27:34 +0100 Subject: bugzilla whiteboard info In-Reply-To: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> References: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> Message-ID: <20050428092733.GX4206@urchin.earth.li> On Wed, Apr 27, 2005 at 01:25:40PM -0500, Eric Rostetter wrote: > Text sent to me, the list, would be great. Plain text, diff/patch output, > whatever, I'll make it work no matter what format you submit. http://www.redhat.com/archives/fedora-legacy-list/2005-April/msg00046.html should be a reasonable starting point. I'd suggest that people update the tags themselves as they see fit (the idea being to relieve me of the tedium of updating the status of all the tickets myself :) Cheers, -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From schlitt at world.std.com Wed Apr 27 16:59:56 2005 From: schlitt at world.std.com (Dan Schlitt) Date: Wed, 27 Apr 2005 12:59:56 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: <1114616032.567.18.camel@mdlinux> References: <200504211930.j3LJUiCY000594@oobleck.astro.cornell.edu> <1114122056.8db0f21295a2e@mail.ph.utexas.edu> <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <1114605457.31821.10.camel@mdlinux> <20050427132558.GA30515@jadzia.bu.edu> <1114616032.567.18.camel@mdlinux> Message-ID: I much prefer the present message format. /dan -- Dan Schlitt schlitt at world.std.com From mattdm at mattdm.org Thu Apr 28 12:56:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 28 Apr 2005 08:56:39 -0400 Subject: separate emails to fedora-legacy-announce for each OS In-Reply-To: References: <20050422040924.GA19424@jadzia.bu.edu> <1114194212.2ee479c1a55f5@mail.ph.utexas.edu> <20050423003323.GA25451@jadzia.bu.edu> <1114576187.23656.3.camel@mdlinux> <20050427044956.GA17977@jadzia.bu.edu> <1114605457.31821.10.camel@mdlinux> <20050427132558.GA30515@jadzia.bu.edu> <1114616032.567.18.camel@mdlinux> Message-ID: <20050428125639.GA23520@jadzia.bu.edu> On Wed, Apr 27, 2005 at 12:59:56PM -0400, Dan Schlitt wrote: > I much prefer the present message format. What advantage does it present to you? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From rostetter at mail.utexas.edu Thu Apr 28 14:30:07 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 28 Apr 2005 09:30:07 -0500 Subject: bugzilla whiteboard info In-Reply-To: <20050428092733.GX4206@urchin.earth.li> References: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> <20050428092733.GX4206@urchin.earth.li> Message-ID: <1114698607.d835f63dd27c4@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > On Wed, Apr 27, 2005 at 01:25:40PM -0500, Eric Rostetter wrote: > > > Text sent to me, the list, would be great. Plain text, diff/patch output, > > whatever, I'll make it work no matter what format you submit. > > http://www.redhat.com/archives/fedora-legacy-list/2005-April/msg00046.html > > should be a reasonable starting point. Forgive my densness, but I'm clueless still. Does publish-* mean it needs publish votes, or that it has a publish vote, or that it has sufficient publish votes to be released? Same for the verify-* tags. I think the others are pretty clear, but I'm not sure what the verify/publish tags mean. A nice writeup would be great, but failing that, additional clues for me would suffice. > I'd suggest that people update > the tags themselves as they see fit (the idea being to relieve me of the > tedium of updating the status of all the tickets myself :) Yeah, but we need to document how to change them, and what to change them to, and when to change them. Sorry for being so slow, but I just don't know how this is all supposed to work yet. > Cheers, > > -- > Dominic Hargreaves | http://www.larted.org.uk/~dom/ > PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- Eric Rostetter From dom at earth.li Thu Apr 28 17:11:12 2005 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 28 Apr 2005 18:11:12 +0100 Subject: bugzilla whiteboard info In-Reply-To: <1114698607.d835f63dd27c4@mail.ph.utexas.edu> References: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> <20050428092733.GX4206@urchin.earth.li> <1114698607.d835f63dd27c4@mail.ph.utexas.edu> Message-ID: <20050428171112.GZ4206@urchin.earth.li> On Thu, Apr 28, 2005 at 09:30:07AM -0500, Eric Rostetter wrote: > Forgive my densness, but I'm clueless still. Does publish-* mean it > needs publish votes, or that it has a publish vote, or that it has > sufficient publish votes to be released? Same for the verify-* > tags. I think the others are pretty clear, but I'm not sure what > the verify/publish tags mean. A nice writeup would be great, but > failing that, additional clues for me would suffice. Sorry, yes, I wasn't very clear. In both cases it means that votes are required. I'd do a write-up but am pretty exhausted. > Yeah, but we need to document how to change them, and what to change them > to, and when to change them. Sorry for being so slow, but I just don't > know how this is all supposed to work yet. No problem - to be honest I was a bit unilateral adding these tags, since I was desparately trying to get rid of the issues.txt burden before it span out of control. Any input from anyone on how to improve the workflow in relation to bugzilla tags is welcome, but for the time being I think we should try and use them. Cheers, -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From mattdm at mattdm.org Thu Apr 28 17:41:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 28 Apr 2005 13:41:32 -0400 Subject: bugzilla whiteboard info In-Reply-To: <20050428171112.GZ4206@urchin.earth.li> References: <1114626340.68a00b46aef5e@mail.ph.utexas.edu> <20050428092733.GX4206@urchin.earth.li> <1114698607.d835f63dd27c4@mail.ph.utexas.edu> <20050428171112.GZ4206@urchin.earth.li> Message-ID: <20050428174132.GA380@jadzia.bu.edu> On Thu, Apr 28, 2005 at 06:11:12PM +0100, Dominic Hargreaves wrote: > Any input from anyone on how to improve the workflow in relation to > bugzilla tags is welcome, but for the time being I think we should try > and use them. I'm also talking to Dave Lawrence at Red Hat about how we can make the Bugzilla statuses for Fedora Legacy line up more with the FL workflow. I think this is preferable to using the whiteboard if at very least because it makes it possible to do the most common searches from the Simple form instead of needing to dive into the advanced one (and dive in with external knowledge of what the whiteboard tags might be). I'll post more on this really soon when I have some more fleshed-out possibilities. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jkosin at beta.intcomgrp.com Thu Apr 28 18:26:34 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 28 Apr 2005 14:26:34 -0400 Subject: sendmail-src RPM Message-ID: <42712ADA.7090805@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to build a new package for sendmail. Anyone know what the sendmail-8.12.9-dynamic.patch suppose to accomplish? I see it wants to modify a Makefile and it looks like it removes strerror.c form the list.... but there are too many files listed there to be exactly sure. Thanks, James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcSrZkNLDmnu1kSkRAkSOAJ0REXQ4SF304jf880lHsgiHAxjYiACeKd2P TJiUTlnuqfrsklvgHJevLec= =FkbJ -----END PGP SIGNATURE----- From ankurdiwan at rediffmail.com Fri Apr 29 04:00:09 2005 From: ankurdiwan at rediffmail.com (Ankur Diwan) Date: 29 Apr 2005 04:00:09 -0000 Subject: how to specify customise page size 2"X6" INCHES. Message-ID: <20050429040009.8905.qmail@webmail28.rediffmail.com> ?Hello, I am new to Linux Enviornment, My requirement is to set customise page size 2"X6" INCHES. How to set customise page size in Fedora Core 2 I Used following procedure to add printer 1. Red Hat -> System Seting -> Printing Printer Configuration Dialog Box Appears Press New Button 2. Add a new Print Queue dialog box appears Press Forward Button 3. Queue Name Dialog Box Appears Specify ankur in Name Text Box and then Press Forward 4. Queue type Dialog box appears Select a Queue Type : Locally connected Select /dev/lp0 press forward button 5. Printer Model dialog box appears Select the Printer Manufacturer and model Epson LX-300 Press Forward Button 6. Finish, and create the new print queue dialog box appears press finish button Printer with ankur as name is added in printer Queue When I double click the ankur printer 1. Edit a print queue Dialog Box appears 2. I click Driver Option Tab in Pring queue Dialog Box Page Size Option is available in it with following values Legal A5 A4 A5 A3 B5 Envolope Letter My question is how to specify a custom page size 2"X6" INCHES. Thanks in Advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oisin.Curtin at PhoenixFltOps.com Fri Apr 29 16:30:14 2005 From: Oisin.Curtin at PhoenixFltOps.com (Oisin Curtin) Date: Fri, 29 Apr 2005 16:30:14 +0000 Subject: how to specify customise page size 2"X6" INCHES. In-Reply-To: <20050429040009.8905.qmail@webmail28.rediffmail.com> References: <20050429040009.8905.qmail@webmail28.rediffmail.com> Message-ID: <42726116.3050804@PhoenixFltOps.com> Ankur Diwan wrote: > Hello, > I am new to Linux Enviornment, My requirement is to set customise page size 2"X6" INCHES. > > How to set customise page size in Fedora Core 2 I think you have to enter the size in the print dialog each time you print. The driver for my stylus C86 includes "Custom" as a size, but that just unlocks the custom dimensions in the print dialog when I print from an application. This is definitely a problem, but I think you will have to take it up with the printer driver developers. This list is only about extending support for orphaned Red Hat/Fedora products. The support here is limited to releasing security patches. -- Oisin "King Size" Curtin