From dwb7 at ccmr.cornell.edu Sat May 1 01:52:23 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Fri, 30 Apr 2004 21:52:23 -0400 Subject: Slashdot In-Reply-To: <200404301537.02900.jkeating@j2solutions.net> References: <200404301537.02900.jkeating@j2solutions.net> Message-ID: <20040501015223.GA15725@ccmr.cornell.edu> At the very least, maybe the front page should list what is needed in terms or participation. Might be able to recruit a few people. On Fri, Apr 30, 2004 at 03:37:02PM -0700, Jesse Keating wrote: Content-Description: signed data > We have been /.'d. Feel free to participate in the comments discussion. > I don't have a /. account so I don't really care to participate. It's > interesting to read about all the people switching away though. > > -- > 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 -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From barryn at pobox.com Sat May 1 03:50:16 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 30 Apr 2004 20:50:16 -0700 Subject: Apache/SSL security issue In-Reply-To: <4092AB62.9090303@chantrynetworks.com> References: <4092AB62.9090303@chantrynetworks.com> Message-ID: <20040501035016.GA3272@ip68-4-98-123.oc.oc.cox.net> On Fri, Apr 30, 2004 at 03:39:14PM -0400, Dan Mongrain wrote: > There has been an alert issued by RedHat on 9.0 > https://rhn.redhat.com/errata/RHSA-2004-182.html regarding Apache and > SSL. Will there be an update to address this issue in 8.0? FWIW I filed this bug: https://bugzilla.fedora.us/show_bug.cgi?id=1551 (And I also filed bugs for the other vulnerabilities in today's Red Hat 9 wave, as well as another from earlier this month that had fallen through the cracks.) -Barry K. Nathan From skvidal at phy.duke.edu Sat May 1 05:23:26 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 01:23:26 -0400 Subject: libpng for 7.x Message-ID: <1083389006.30914.41.camel@binkley> Hi, Libpng packages up for QA for rhl 7.X. https://bugzilla.fedora.us/show_bug.cgi?id=1550 -sv From michal at harddata.com Sat May 1 06:05:06 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 1 May 2004 00:05:06 -0600 Subject: libpng for 7.x In-Reply-To: <1083389006.30914.41.camel@binkley>; from skvidal@phy.duke.edu on Sat, May 01, 2004 at 01:23:26AM -0400 References: <1083389006.30914.41.camel@binkley> Message-ID: <20040501000506.A16884@mail.harddata.com> On Sat, May 01, 2004 at 01:23:26AM -0400, seth vidal wrote: > Hi, > Libpng packages up for QA for rhl 7.X. As last updates from Red Hat for 7.X distros had a version libpng-1.0.14-0.7x.4 (Build Date: Thu 19 Dec 2002) then calling current ones libpng-1.0.14-0.7x.4.legacy.0 seems a bit confusing. Was that intentional? Michal From skvidal at phy.duke.edu Sat May 1 06:07:24 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 02:07:24 -0400 Subject: libpng for 7.x In-Reply-To: <20040501000506.A16884@mail.harddata.com> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> Message-ID: <1083391643.30914.43.camel@binkley> On Sat, 2004-05-01 at 00:05 -0600, Michal Jaegermann wrote: > On Sat, May 01, 2004 at 01:23:26AM -0400, seth vidal wrote: > > Hi, > > Libpng packages up for QA for rhl 7.X. > > As last updates from Red Hat for 7.X distros had a version > libpng-1.0.14-0.7x.4 (Build Date: Thu 19 Dec 2002) then calling > current ones libpng-1.0.14-0.7x.4.legacy.0 seems a bit confusing. > Was that intentional? > I was just following the standard of not bumping over the rhl release numbers - I just appended .legacy.0 and moved along. Is that not correct? -sv From jkeating at j2solutions.net Sat May 1 06:11:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Apr 2004 23:11:06 -0700 Subject: libpng for 7.x In-Reply-To: <1083391643.30914.43.camel@binkley> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> <1083391643.30914.43.camel@binkley> Message-ID: <200404302311.09804.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 April 2004 23:07, seth vidal wrote: > I was just following the standard of not bumping over the rhl release > numbers - I just appended .legacy.0 and moved along. > > Is that not correct? There is no correct way. Perhaps if Red Hat had a constant method of doing their version numbers there may be, but no... I'd say bump the 4 to 5, and append .legacy so libpng-1.0.14-0.7x.5.legacy - -- 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.3 (GNU/Linux) iD8DBQFAkz994v2HLvE71NURAnSUAJ9UYvG9+toSk8CjEKqCJd4Zbch1LwCgvxPV TCk9/aHo36tejdKC5AtIh+o= =Y3is -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Sat May 1 06:14:56 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 02:14:56 -0400 Subject: libpng for 7.x In-Reply-To: <200404302311.09804.jkeating@j2solutions.net> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> <1083391643.30914.43.camel@binkley> <200404302311.09804.jkeating@j2solutions.net> Message-ID: <1083392095.30914.47.camel@binkley> On Fri, 2004-04-30 at 23:11 -0700, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 30 April 2004 23:07, seth vidal wrote: > > I was just following the standard of not bumping over the rhl release > > numbers - I just appended .legacy.0 and moved along. > > > > Is that not correct? > > There is no correct way. Perhaps if Red Hat had a constant method of doing > their version numbers there may be, but no... > > I'd say bump the 4 to 5, and append .legacy > > so libpng-1.0.14-0.7x.5.legacy done. -sv From skvidal at phy.duke.edu Sat May 1 06:47:31 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 02:47:31 -0400 Subject: libxml2 for rhl 7.3 Message-ID: <1083394051.30914.49.camel@binkley> libxml2 packages up for QA for rhl7.3 https://bugzilla.fedora.us/show_bug.cgi?id=1324 need some QA and builds for rhl7.2 and rhl8.0 if people have those systems/buildroots. -sv From skvidal at phy.duke.edu Sat May 1 06:59:38 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 02:59:38 -0400 Subject: gdk-pixbuf packages for rhl 7.3 up for QA Message-ID: <1083394778.30914.52.camel@binkley> Hi, gdk-pixbuf packages for rhl7.3 to fix: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0592 are up for QA. see bug: https://bugzilla.fedora.us/show_bug.cgi?id=1371 please QA and report - if happy, then say so. Thanks -sv From skvidal at phy.duke.edu Sat May 1 07:49:31 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 03:49:31 -0400 Subject: cadaver packages for rhl 7.3 up for QA Message-ID: <1083397770.30914.55.camel@binkley> Hi, cadaver packages for rhl7.3 up for QA as per: https://bugzilla.fedora.us/show_bug.cgi?id=1552 please QA and test. Thanks. -sv From skvidal at phy.duke.edu Sat May 1 08:43:33 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 04:43:33 -0400 Subject: sysklogd packages for rhl7.3(7.x?) and rhl9 for memory overrun up for QA Message-ID: <1083401013.30914.58.camel@binkley> Sysklogd ackages for rhl7.3(7.x possibly) and rhl9 that correct a memory overrun in syslogd's crunchlist are up for QA. please check them and test them (and of course comment) https://bugzilla.fedora.us/show_bug.cgi?id=1553 thanks, -sv From skvidal at phy.duke.edu Sat May 1 13:27:28 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 09:27:28 -0400 Subject: building srpms -- debuginfo In-Reply-To: <200405011204.25772.rok.papez@lugos.si> References: <200405011204.25772.rok.papez@lugos.si> Message-ID: <1083418047.30914.62.camel@binkley> On Sat, 2004-05-01 at 12:04 +0200, Rok Pape? wrote: > Hello Seth. > > How do you enable building of debuginfo packages ? You don't - rpm does it automatically if you're using rpm 4.1 or higher. -sv From mattdm at mattdm.org Sat May 1 13:32:14 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 1 May 2004 09:32:14 -0400 Subject: libpng for 7.x In-Reply-To: <200404302311.09804.jkeating@j2solutions.net> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> <1083391643.30914.43.camel@binkley> <200404302311.09804.jkeating@j2solutions.net> Message-ID: <20040501133214.GA4010@jadzia.bu.edu> On Fri, Apr 30, 2004 at 11:11:06PM -0700, Jesse Keating wrote: > There is no correct way. Perhaps if Red Hat had a constant method of doing > their version numbers there may be, but no... > I'd say bump the 4 to 5, and append .legacy > so libpng-1.0.14-0.7x.5.legacy Ouch. That seem like a recipe for disaster. What if RH would, out of the blue, decide to actually release an official update to something we thought was completely out of maintenance? Not likely to happen with 7.x, but maybe one or two RHL9 updates will still trickle out. I think Seth's choice of not touching the base RH package's version number is a better policy choice -- largely _because_ there is no upstream constant method. Instead, we should leave whatever they do alone, and add after that. $0.02... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at phy.duke.edu Sat May 1 15:31:41 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 11:31:41 -0400 Subject: libpng for 7.x In-Reply-To: <20040501133214.GA4010@jadzia.bu.edu> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> <1083391643.30914.43.camel@binkley> <200404302311.09804.jkeating@j2solutions.net> <20040501133214.GA4010@jadzia.bu.edu> Message-ID: <1083425500.30914.65.camel@binkley> > Ouch. That seem like a recipe for disaster. What if RH would, out of the > blue, decide to actually release an official update to something we thought > was completely out of maintenance? Not likely to happen with 7.x, but maybe > one or two RHL9 updates will still trickle out. I think Seth's choice of not > touching the base RH package's version number is a better policy choice -- > largely _because_ there is no upstream constant method. Instead, we should > leave whatever they do alone, and add after that. Red hat knows that fedora legacy exists. If they pull anything like that for a 7.x release then I will feel very very justified in smacking the packager in question. -sv From kwan at digitalhermit.com Sat May 1 16:11:38 2004 From: kwan at digitalhermit.com (Kwan Lowe) Date: Sat, 01 May 2004 12:11:38 -0400 Subject: httpd updates Message-ID: <1083427897.4944.6.camel@deepthought.digitalhermit.com> Hello All: I made some RPMs from the latest RH9 httpd for RH8 for my personal use. Pretty much it's just the fixes from Joe Orton copied into the RH8 version. They're certainly untested beyond my (otherwise stock) machines so use at your own risk. If there are any glaring errors in how I handled these, please let me know. http://www.digitalhermit.com/~kwan/legacy/ Thanks, Kwan From jkeating at j2solutions.net Sat May 1 16:23:09 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 1 May 2004 09:23:09 -0700 Subject: libpng for 7.x In-Reply-To: <20040501133214.GA4010@jadzia.bu.edu> References: <1083389006.30914.41.camel@binkley> <200404302311.09804.jkeating@j2solutions.net> <20040501133214.GA4010@jadzia.bu.edu> Message-ID: <200405010923.09327.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 01 May 2004 06:32, Matthew Miller wrote: > Ouch. That seem like a recipe for disaster. What if RH would, out of the > blue, decide to actually release an official update to something we > thought was completely out of maintenance? Not likely to happen with > 7.x, but maybe one or two RHL9 updates will still trickle out. I think > Seth's choice of not touching the base RH package's version number is a > better policy choice -- largely _because_ there is no upstream constant > method. Instead, we should leave whatever they do alone, and add after > that. Given that the package name has a 0.7x in it already, it's highly unlikely they would bump a 0.7x package into RHL9 space. The RHL9 package most likely has 0.9 in the package name, and is thus guaranteed to be newer than our 0.7x packages, no matter what our build level. - -- 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.3 (GNU/Linux) iD8DBQFAk87t4v2HLvE71NURAlqeAJ9tNKB1lRCu6c/XiR/iFjfS4bBWvgCgqrsS 1zSQH9Gj/bwtiTmDRj5/zcc= =2qLs -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Sat May 1 16:26:00 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 01 May 2004 12:26:00 -0400 Subject: httpd updates In-Reply-To: <1083427897.4944.6.camel@deepthought.digitalhermit.com> References: <1083427897.4944.6.camel@deepthought.digitalhermit.com> Message-ID: <1083428759.30914.74.camel@binkley> On Sat, 2004-05-01 at 12:11 -0400, Kwan Lowe wrote: > Hello All: > I made some RPMs from the latest RH9 httpd for RH8 for my personal > use. Pretty much it's just the fixes from Joe Orton copied into the RH8 > version. They're certainly untested beyond my (otherwise stock) > machines so use at your own risk. > If there are any glaring errors in how I handled these, please let me > know. > http://www.digitalhermit.com/~kwan/legacy/ > Could you attach those with md5sums to the bug related to this? Thanks -sv From davej at redhat.com Sat May 1 16:41:52 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 1 May 2004 17:41:52 +0100 Subject: libpng for 7.x In-Reply-To: <1083425500.30914.65.camel@binkley> References: <1083389006.30914.41.camel@binkley> <20040501000506.A16884@mail.harddata.com> <1083391643.30914.43.camel@binkley> <200404302311.09804.jkeating@j2solutions.net> <20040501133214.GA4010@jadzia.bu.edu> <1083425500.30914.65.camel@binkley> Message-ID: <20040501164152.GA25037@redhat.com> On Sat, May 01, 2004 at 11:31:41AM -0400, seth vidal wrote: > > > Ouch. That seem like a recipe for disaster. What if RH would, out of the > > blue, decide to actually release an official update to something we thought > > was completely out of maintenance? Not likely to happen with 7.x, but maybe > > one or two RHL9 updates will still trickle out. I think Seth's choice of not > > touching the base RH package's version number is a better policy choice -- > > largely _because_ there is no upstream constant method. Instead, we should > > leave whatever they do alone, and add after that. > > Red hat knows that fedora legacy exists. If they pull anything like that > for a 7.x release then I will feel very very justified in smacking the > packager in question. For RHL9 kernel updates at least, I'm happy to work with Fedora-legacy folks to get updates out rather than ever having to do another RHL9 update on behalf of Red Hat. I imagine other Red Hat package owners will feel the seem way. Dave From kwan at digitalhermit.com Sat May 1 16:47:58 2004 From: kwan at digitalhermit.com (Kwan Lowe) Date: Sat, 01 May 2004 12:47:58 -0400 Subject: httpd updates In-Reply-To: <1083428759.30914.74.camel@binkley> References: <1083427897.4944.6.camel@deepthought.digitalhermit.com> <1083428759.30914.74.camel@binkley> Message-ID: <1083430078.4944.12.camel@deepthought.digitalhermit.com> On Sat, 2004-05-01 at 12:26, seth vidal wrote: > Could you attach those with md5sums to the bug related to this? Here's the info for the files: * Sat May 01 2004 Kwan Lowe 2.0.40-11.9_legacy1 - rebuild for RedHat8 using Joe Orton patches (below) - add security fix for CVE CAN-2004-0113 - add fix for slow graceful restarts in prefork - mod_deflate: update to recent version (#115280) - mod_ssl: misc bug fixes - core: add EnableSendfile directive (#78224) 91cc37b753e3930f7817f12e960a0e1a httpd-2.0.40-11.9_legacy1.i386.rpm 1b8a4faf58d5a49fdc138958e38cf278 httpd-2.0.40-11.9_legacy1.src.rpm bf91140f83a749903a69950f22a6c4ba httpd-devel-2.0.40-11.9_legacy1.i386.rpm e669f43a4699d4ed11bc26a30ff1a744 httpd-manual-2.0.40-11.9_legacy1.i386.rpm 9fd9db4ebdc49ab85c558c522c07f64c mod_ssl-2.0.40-11.9_legacy1.i386.rpm So far I'm only testing CAN-2004-0113. I've not had time to look into the other patches to test them. From jkeating at j2solutions.net Sat May 1 17:00:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 1 May 2004 10:00:11 -0700 Subject: libpng for 7.x In-Reply-To: <20040501164152.GA25037@redhat.com> References: <1083389006.30914.41.camel@binkley> <1083425500.30914.65.camel@binkley> <20040501164152.GA25037@redhat.com> Message-ID: <200405011000.11919.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 01 May 2004 09:41, Dave Jones wrote: > For RHL9 kernel updates at least, I'm happy to work with Fedora-legacy > folks to get updates out rather than ever having to do another RHL9 > update on behalf of Red Hat. I imagine other Red Hat package owners > will feel the seem way. Dave, we deeply appreciate your help! I got your mail and I will be contacting you soon to work on that. We have to clear up a few infrastructure things first, but that's coming along smoothly. - -- 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.3 (GNU/Linux) iD8DBQFAk9eb4v2HLvE71NURAsI1AJ0c3czsWTXnqxvuIAC7T/kp1cuCXACfZtWu 28PXsgu645t4IJFGKHD5PfI= =Y/Sz -----END PGP SIGNATURE----- From davej at redhat.com Sat May 1 18:13:27 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 1 May 2004 19:13:27 +0100 Subject: libpng for 7.x In-Reply-To: <200405011000.11919.jkeating@j2solutions.net> References: <1083389006.30914.41.camel@binkley> <1083425500.30914.65.camel@binkley> <20040501164152.GA25037@redhat.com> <200405011000.11919.jkeating@j2solutions.net> Message-ID: <20040501181327.GC25037@redhat.com> On Sat, May 01, 2004 at 10:00:11AM -0700, Jesse Keating wrote: > On Saturday 01 May 2004 09:41, Dave Jones wrote: > > For RHL9 kernel updates at least, I'm happy to work with Fedora-legacy > > folks to get updates out rather than ever having to do another RHL9 > > update on behalf of Red Hat. I imagine other Red Hat package owners > > will feel the seem way. > > Dave, we deeply appreciate your help! I got your mail and I will be > contacting you soon to work on that. We have to clear up a few > infrastructure things first, but that's coming along smoothly. No problem, shout if there's anything I can do to help. Dave From rok.papez at lugos.si Sat May 1 09:57:43 2004 From: rok.papez at lugos.si (Rok =?utf-8?q?Pape=C5=BE?=) Date: Sat, 1 May 2004 11:57:43 +0200 Subject: sysklogd packages for rhl7.3(7.x?) and rhl9 for memory overrun up for QA In-Reply-To: <1083401013.30914.58.camel@binkley> References: <1083401013.30914.58.camel@binkley> Message-ID: <200405011157.43191.rok.papez@lugos.si> Hello Seth && Fedora Legacy. Dne sobota 01 maj 2004 10:43 je seth vidal napisal(a): > Sysklogd ackages for rhl7.3(7.x possibly) and rhl9 that correct a memory > overrun in syslogd's crunchlist are up for QA. > > please check them and test them (and of course comment) > > https://bugzilla.fedora.us/show_bug.cgi?id=1553 QA testing report: ============== 1. SRPMS inspection: only a code patch was added, source files are owned by user "skvidal", no other changes 2. Code inspection: PASS 3. SRPMS rebuild: PASS 3. RPM Upgrade: PASS 4. Functionality test: PASS As far as I'm concerned, package is OK and can be pushed to repository. 1. SRPMS inspection details: ===================== # rpm -qp sysklogd-1.4.1-13.legacy.9.src.rpm -l -v -rw-rw-r-- 1 skvidal skvidal 91105 feb 7 2003 sysklogd-1.4.1rh.tar.gz -rw-rw-r-- 1 skvidal skvidal 767 maj 1 10:07 sysklogd-crunchlist-count.patch -rw-rw-r-- 1 skvidal skvidal 8792 maj 1 10:13 sysklogd.spec # rpm -qp sysklogd-1.4.1-12.src.rpm -l -v -rw-rw-r-- 1 root root 91105 feb 7 2003 sysklogd-1.4.1rh.tar.gz -rw-rw-r-- 0 root root 8612 feb 7 2003 sysklogd.spec This is not an issue... 2. Code inspection: ================ - the same patch was already published in FC2 bugzilla entry diff -ur sysklogd-1.4.1rh.orig/syslogd.c sysklogd-1.4.1rh/syslogd.c --- sysklogd-1.4.1rh.orig/syslogd.c 2001-08-15 13:16:05.000000000 -0400 +++ sysklogd-1.4.1rh/syslogd.c 2004-04-08 17:09:42.000000000 -0400 @@ -1266,12 +1266,10 @@ /* strip off trailing delimiters */ while (p[strlen(p)-1] == LIST_DELIMITER) { - count--; p[strlen(p)-1] = '\0'; } /* cut off leading delimiters */ while (p[0] == LIST_DELIMITER) { - count--; p++; } ==> count is leater assigned a value, "count--" has no effect. Obsolete code. @@ -1279,7 +1277,7 @@ for (count=i=0; p[i]; i++) if (p[i] == LIST_DELIMITER) count++; - if ((result = (char **)malloc(sizeof(char *) * count+2)) == NULL) { + if ((result = (char **)malloc(sizeof(char *) * (count+2))) == NULL) { printf ("Sorry, can't get enough memory, exiting.\n"); exit(0); } ==> count+2 has to be in parantheses since multiplication has precedence over summation. The allocated space needs to be for a (count+2) pointers to characters, not for a (count) number of pointers + 2 bytes. -- best regards, Rok Pape? From rok.papez at lugos.si Sat May 1 10:04:25 2004 From: rok.papez at lugos.si (Rok =?utf-8?q?Pape=C5=BE?=) Date: Sat, 1 May 2004 12:04:25 +0200 Subject: building srpms -- debuginfo Message-ID: <200405011204.25772.rok.papez@lugos.si> Hello Seth. How do you enable building of debuginfo packages ? -- best regards, Rok Pape? From jonny.strom at netikka.fi Sun May 2 19:46:22 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Sun, 02 May 2004 22:46:22 +0300 Subject: Uppdates for rh 7.3 Message-ID: <4095500E.2050303@netikka.fi> Hi all I have been working over the weekend on back porting fixes to Redhat 7.3, since I have done the pack port for 6 different programs so was I thinking to send out this mail so that ppl. can QA them over the coming week and put the feedback into bugzilla. Here is the url: http://av8.netikka.fi/~johnny/fedora_legacy/rh73/ Thanks Johnny From christof at damian.net Mon May 3 07:14:16 2004 From: christof at damian.net (Christof Damian) Date: Mon, 3 May 2004 09:14:16 +0200 Subject: yum and redhat 7.2 Message-ID: <20040503071416.GC1544@batman.gotham.krass.com> Hello, I currently get a 503 Service Temporarily Unavailable Error on http://download.fedoralegacy.org/redhat/7.2/os/i386/headers/header.info Is there a problem with the server? Thanks, Christof -- Christof Damian christof at damian.net From skvidal at phy.duke.edu Mon May 3 07:16:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 03 May 2004 03:16:17 -0400 Subject: yum and redhat 7.2 In-Reply-To: <20040503071416.GC1544@batman.gotham.krass.com> References: <20040503071416.GC1544@batman.gotham.krass.com> Message-ID: <1083568577.19508.3.camel@binkley> On Mon, 2004-05-03 at 09:14 +0200, Christof Damian wrote: > Hello, > I currently get a 503 Service Temporarily Unavailable Error on > http://download.fedoralegacy.org/redhat/7.2/os/i386/headers/header.info > > Is there a problem with the server? Hi, Yes there has been some bandwidth issues with the place the server is currently located. That is soon to be resolved as the new server setup is at a new location. It should be online sometime this week. You're encouraged, of course, to use a mirror that is closer to you. -sv From fleck004 at umn.edu Mon May 3 19:14:29 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Mon, 3 May 2004 14:14:29 -0500 Subject: Problem with GPG Key In-Reply-To: <1083568577.19508.3.camel@binkley> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> Message-ID: <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> I've installed yum according to the documentation at the fedora-legacy site, and installed and imported the GPG key. yum says the signature check fails: Error: GPG Signature check failed for /var/cache/yum/updates/packages/util-linux-2.11f-19.7.2.legacy.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/util-linux-2.11f-19.7.2.legacy.i386.rpm You may also want to check to make sure you have the right gpg keys Exiting. I did do .rpm > and that came up with Good Signature, along with the warning mentioned on the legacy security page. Can anyone give me some pointers as to what to try next? Thanks. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From jkeating at j2solutions.net Mon May 3 19:14:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 May 2004 12:14:01 -0700 Subject: Problem with GPG Key In-Reply-To: <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> Message-ID: <200405031214.04274.jkeating@j2solutions.net> On Monday 03 May 2004 12:14, Peter Fleck wrote: > I did do .rpm > and that came up with > Good Signature, along with the warning mentioned on the legacy > security page. What is the warning? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fleck004 at umn.edu Mon May 3 19:27:59 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Mon, 3 May 2004 14:27:59 -0500 Subject: Problem with GPG Key In-Reply-To: <200405031214.04274.jkeating@j2solutions.net> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> Message-ID: from http://www.fedoralegacy.org/about/security.php in discussing a bug in RPM: >>>> Note: A side effect of the above bug is that you may see notices like the following when you try to verify packages: gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. This warning can be ignored as it is simply due to our signing key not having any additional signatures so as to make it work reliably in RPM. <<<< I get that when I use . On May 3, 2004, at 2:14 PM, Jesse Keating wrote: > On Monday 03 May 2004 12:14, Peter Fleck wrote: >> I did do .rpm > and that came up with >> Good Signature, along with the warning mentioned on the legacy >> security page. > > What is the warning? > > ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From jkeating at j2solutions.net Mon May 3 20:37:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 May 2004 13:37:18 -0700 Subject: Please Use the Mirrors! Message-ID: <200405031337.21863.jkeating@j2solutions.net> Bandwith is very precious on the master download.fedoralegacy.org server as we are transitioning to the new server. People have been using download exclusively had effectively DDoSing the system so that all other services drop off. I'm asking once more to please use one of the mirrors until we get things sorted out. Thanks. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From seyman at wanadoo.fr Mon May 3 21:57:03 2004 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Mon, 3 May 2004 23:57:03 +0200 Subject: Please Use the Mirrors! In-Reply-To: <200405031337.21863.jkeating@j2solutions.net> References: <200405031337.21863.jkeating@j2solutions.net> Message-ID: <20040503215703.GA8140@orient.maison.moi> On Mon, May 03, 2004 at 01:37:18PM -0700, Jesse Keating wrote: > > Bandwith is very precious on the master download.fedoralegacy.org server > as we are transitioning to the new server. Any chance we can reserve download.fedoralegacy.org access to mirrors only with users downloading from said mirrors ? Emmanuel From jkeating at j2solutions.net Mon May 3 21:59:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 May 2004 14:59:02 -0700 Subject: Please Use the Mirrors! In-Reply-To: <20040503215703.GA8140@orient.maison.moi> References: <200405031337.21863.jkeating@j2solutions.net> <20040503215703.GA8140@orient.maison.moi> Message-ID: <200405031459.05596.jkeating@j2solutions.net> On Monday 03 May 2004 14:57, Emmanuel Seyman wrote: > Any chance we can reserve download.fedoralegacy.org access to mirrors > only with users downloading from said mirrors ? When the new server comes on, there may be reserved rsync access for mirrors, but the plan is that there is enough bandwidth to service the mirrors and the users that aren't using the mirrors. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Mon May 3 22:07:30 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 3 May 2004 15:07:30 -0700 (PDT) Subject: Please Use the Mirrors! In-Reply-To: <20040503215703.GA8140@orient.maison.moi> Message-ID: On Mon, 3 May 2004, Emmanuel Seyman wrote: > On Mon, May 03, 2004 at 01:37:18PM -0700, Jesse Keating wrote: > > > > Bandwith is very precious on the master download.fedoralegacy.org > > server as we are transitioning to the new server. > > Any chance we can reserve download.fedoralegacy.org access to mirrors > only with users downloading from said mirrors ? Indeed. If I'm not mistaken, this is the tack that RedHat takes for their own download site. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Mon May 3 22:07:34 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 May 2004 15:07:34 -0700 Subject: Please Use the Mirrors! In-Reply-To: References: Message-ID: <200405031507.34887.jkeating@j2solutions.net> On Monday 03 May 2004 15:07, Chuck Wolber wrote: > Indeed. If I'm not mistaken, this is the tack that RedHat takes for > their own download site. This was a non-issue when I wasn't capped. Now that I'm capped, even the http traffic to download.fedoralegacy.org is killing me. rsync was shut off long ago. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue May 4 00:26:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 May 2004 17:26:52 -0700 Subject: Call for testers Message-ID: <200405031726.55086.jkeating@j2solutions.net> Hey folks. We've got a new server we'd like to test out, to make sure we've got everything set up right. I'd like some folks to test yum/apt/http downloads. I'd like to see 7.2/7.3/8.0/9 tests for each repot. If you wish to help w/ the test, please contact me off list for server info. Thanks! -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From kas at informatics.muni.cz Tue May 4 08:49:58 2004 From: kas at informatics.muni.cz (Jan Kasprzak) Date: Tue, 4 May 2004 10:49:58 +0200 Subject: FWD: iDEFENSE: Upcoming OpenSSH Security Advisory Announcement Message-ID: <20040504084957.GB16174@fi.muni.cz> Hello, FL people, does anybody know details about this vulnerability? -Yenya : From: Richard Johnson : To: full-disclosure at lists.netsys.com, bugtraq at securityfocus.com, vuln-dev at securityfocus.com, vulnwatch at vulnwatch.org, misc at openbsd.org : Subject: [Full-Disclosure] iDEFENSE: Upcoming OpenSSH Security Advisory Announcement : Date: Mon, 03 May 2004 11:51:12 -0400 : : : iDEFENSE Security Advisory 05.03.04: : http://www.idefense.com/advisory/05.03.04.txt : Upcoming OpenSSH Preauthentication Vulnerability Announcement : May 3, 2004 : : There is an upcoming OpenSSH vulnerability that we're working on with : the OpenBSD Crew. Details will be published early next week. : : However, I can say that when OpenSSH's sshd(8) is running with priv : seperation, the bug cannot be exploited for immediate root access. : : OpenSSH 3.3p was released a few years ago, with various improvements : but in particular, it significantly improves the Linux and Solaris : support for priv sep. However, it is not yet perfect. Compression is : disabled on some systems, and the many varieties of PAM are causing : major headaches. : : However, everyone should update to OpenSSH 3.8 immediately, and enable : priv seperation in their ssh daemons, by setting this in your : /etc/ssh/sshd_config file: : : UsePrivilegeSeparation yes : : Depending on what your system is, privsep may break some ssh : functionality. However, with privsep turned on, you are immune from : at least one remote hole. Understand? Being immune from at least one : remote bug is worth broken functionality, especially when the software : suffers from additional remote bugs. : : 3.8 does not contain a fix for this upcoming bug. : : If priv seperation does not work on your operating system, you need to : work with your vendor so that we get patches to make it work on your : system. OpenSSH developers are swamped enough without trying to : support the myriad of PAM and other issues which exist in various : systems. For more information regarding the OpenBSD Crew's struggle : with PAM issues, please read: : http://www.openssh.com/txt/sshpam.adv : : Basically, OpenSSH sshd(8) is something like 27000 lines of code. A : lot of that runs as root. But when UsePrivilegeSeparation is enabled, : the daemon splits into two parts. A part containing about 2500 lines : of code remains as root, and the rest of the code is shoved into a : chroot-jail without any privs. This makes the daemon less vulnerable : to attack. Less vulnerable is better than more vulnerable, and we : hope that someday the OpenBSD team can make things not vulnerable. : : Threat elimination is more important than threat reduction, after all. : : Apparently the OpenBSD Crew has been trying to warn vendors about 3.8 : and the need for privs sep to be in use. Since priv sep has existed : for many years, and still is not used in 100% of deployed OpenSSH : installations, the world is doing this marvelous team of cryptography : experts and emerging mediocre programmers a world of discredit. Some : developers, like Alan Cox, have reprotedly gone even further stating : that privsep was not being worked on because "Nobody provided any info : which proves the problem, and many people dont trust you theo" and : suggested that Theo "might be feeding everyone a trojan". The official : OpenBSD Crew's response to this allegation can be seen here: : http://www.openssh.com/txt/sshpam.adv : : HP's representative has thusfar been downright rude, and we anticipate : that he will be removed from his position at the company in the near : future for the negative attention that he is bringing to the company, : and the lack of lucrative security PRODUCT and RESEARCH to the market. : : Only the Solar Designer seems to think priv sep is a good idea, since : historically he has been fond of developing security solutions : following known flawed models in the hopes of making exploitation of : security issues harder but not impossible, putting security back into : the hands of hackers and out of the hands of scriptkids and security : consultants. : : iDEFENSE recommends either using OpenBSD, Openwall Linux (Owl), or : Microsoft Windows. All other operating systems are insecure. : : So, if vendors would JUMP and get it working better, and send the : OpenBSD Crew patches IMMEDIATELY, we can perhaps make a better 3.9 : release on Friday which supports all systems better. So please send : patches to them IMMEDIATELY so progress can be made. Then on Tuesday : or Friday the complete bug report with patches (and year old exploits, : we are sure) will hit BUGTRAQ(tm). : : Let me repeat: even if the bug exists in a privsep'd sshd, it is not : exploitable. Clearly we cannot yet publish what the bug is, or : provide anyone with the real patch, but we can try to get maximum : deployement of privsep, and therefore make it hurt less when the : problem is published. : : If you doubt the sincerity of this claim, please review the following : case study and included references to the security of a privilage : separation enabled open secure shell daemon's unbreakable status. : http://www.phrack.org/phrack/60/p60-0x06.txt : : : So please push your vendor to get us maximally working privsep patches : as soon as possible!!!! : : We've given most vendors since Friday last week until Thursday to get : privsep working well for you so that when the announcement comes out : next week their customers are immunized. That is nearly a full week : (but they have already wasted a weekend and a Monday). Really I think : this is the best we can hope to do (this thing will eventually leak, : at which point the details will be published). : : Customers can judge their vendors by how they respond to this issue. : : OpenBSD and NetBSD users should also update to OpenSSH 3.8 right away. : On OpenBSD privsep works flawlessly, and I have reports that is also : true on NetBSD. All other systems appear to have minor or major : weaknesses when this code is running. : : We would urge the OpenBSD Crew to remake the OpenSSH Security page : ( http://www.openssh.com/security.html ) to make it less confusing. : It would serve the public interest much better if the page listed : specifically what versions are affected by which bugs, making it clear : which versions bugs were introduced in, and which versions said bugs : have been fixed in. The current listing is too difficult to process, : and listing what versions are no longer vulnerable to a particular : known issue seems silly, since one would hope that the most recent : available version of a security PRODUCT would not suffer from any : published and widely known security problems. : : If you or your organization would like to purchase advanced details : of this vulnerability, please contact sales at idefense.com with your : inquiry. : : We at iDEFENSE would like to thank Kurt Seifried, consultant and : "OUTSIDE_INTEL" operative/analyst (and SECURITY EXPERT) for all his : hard and profound work for us. Also we would like to applaud him for : his brilliant work on translating the English translations of the CORE : Impact documentation to better English; a most impressive addition to : any resume is being able to brag of being a contractor for multiple : goverment contractors, because frankly - he is just that damn good. : : ______________________________________ : < Work for iDEFENSE and become famous! > : -------------------------------------- : \ _ : \ (_) : \ ^__^ / \ : \ (oo)\_____/_\ \ : (__)\ ) / : ||----w (( : || ||>> : : iDEFENSE is a global security intelligence company that proactively : monitors sources throughout the world from technical vulnerabilities : and hacker profiling to the global spread of viruses and other *yawn* : delicious code. Our security intelligence services provide decision : makers, frontline security professionals and network administrators : with timely access to actionable intelligence and decision support on : cyber-related threats. For more information, visit our flash enabled : interweb portal at http://www.idefense.com. : -- : Paul Cassell -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. --Linus Torvalds From yehudi at tehila.gov.il Tue May 4 09:02:43 2004 From: yehudi at tehila.gov.il (Yaakov Yehudi) Date: Tue, 4 May 2004 12:02:43 +0300 Subject: iDEFENSE: Upcoming OpenSSH Security Advisory Announcement In-Reply-To: <20040504084957.GB16174@fi.muni.cz> Message-ID: <00cf01c431b6$8f887470$dc09050a@YAAKOV> It is a hoax! Look at the diagram near the bottom of the original email! :-( Regards, Yaakov -----Original Message----- From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of Jan Kasprzak Sent: Tuesday, May 04, 2004 11:50 To: fedora-legacy-list at redhat.com Subject: FWD: iDEFENSE: Upcoming OpenSSH Security Advisory Announcement Hello, FL people, does anybody know details about this vulnerability? -Yenya : From: Richard Johnson : To: full-disclosure at lists.netsys.com, bugtraq at securityfocus.com, vuln-dev at securityfocus.com, vulnwatch at vulnwatch.org, misc at openbsd.org : Subject: [Full-Disclosure] iDEFENSE: Upcoming OpenSSH Security Advisory Announcement : Date: Mon, 03 May 2004 11:51:12 -0400 : : : iDEFENSE Security Advisory 05.03.04: : http://www.idefense.com/advisory/05.03.04.txt : Upcoming OpenSSH Preauthentication Vulnerability Announcement : May 3, 2004 : : There is an upcoming OpenSSH vulnerability that we're working on with : the OpenBSD Crew. Details will be published early next week. : : However, I can say that when OpenSSH's sshd(8) is running with priv : seperation, the bug cannot be exploited for immediate root access. : : OpenSSH 3.3p was released a few years ago, with various improvements : but in particular, it significantly improves the Linux and Solaris : support for priv sep. However, it is not yet perfect. Compression is : disabled on some systems, and the many varieties of PAM are causing : major headaches. : : However, everyone should update to OpenSSH 3.8 immediately, and enable : priv seperation in their ssh daemons, by setting this in your : /etc/ssh/sshd_config file: : : UsePrivilegeSeparation yes : : Depending on what your system is, privsep may break some ssh : functionality. However, with privsep turned on, you are immune from : at least one remote hole. Understand? Being immune from at least one : remote bug is worth broken functionality, especially when the software : suffers from additional remote bugs. : : 3.8 does not contain a fix for this upcoming bug. : : If priv seperation does not work on your operating system, you need to : work with your vendor so that we get patches to make it work on your : system. OpenSSH developers are swamped enough without trying to : support the myriad of PAM and other issues which exist in various : systems. For more information regarding the OpenBSD Crew's struggle : with PAM issues, please read: : http://www.openssh.com/txt/sshpam.adv : : Basically, OpenSSH sshd(8) is something like 27000 lines of code. A : lot of that runs as root. But when UsePrivilegeSeparation is enabled, : the daemon splits into two parts. A part containing about 2500 lines : of code remains as root, and the rest of the code is shoved into a : chroot-jail without any privs. This makes the daemon less vulnerable : to attack. Less vulnerable is better than more vulnerable, and we : hope that someday the OpenBSD team can make things not vulnerable. : : Threat elimination is more important than threat reduction, after all. : : Apparently the OpenBSD Crew has been trying to warn vendors about 3.8 : and the need for privs sep to be in use. Since priv sep has existed : for many years, and still is not used in 100% of deployed OpenSSH : installations, the world is doing this marvelous team of cryptography : experts and emerging mediocre programmers a world of discredit. Some : developers, like Alan Cox, have reprotedly gone even further stating : that privsep was not being worked on because "Nobody provided any info : which proves the problem, and many people dont trust you theo" and : suggested that Theo "might be feeding everyone a trojan". The official : OpenBSD Crew's response to this allegation can be seen here: : http://www.openssh.com/txt/sshpam.adv : : HP's representative has thusfar been downright rude, and we anticipate : that he will be removed from his position at the company in the near : future for the negative attention that he is bringing to the company, : and the lack of lucrative security PRODUCT and RESEARCH to the market. : : Only the Solar Designer seems to think priv sep is a good idea, since : historically he has been fond of developing security solutions : following known flawed models in the hopes of making exploitation of : security issues harder but not impossible, putting security back into : the hands of hackers and out of the hands of scriptkids and security : consultants. : : iDEFENSE recommends either using OpenBSD, Openwall Linux (Owl), or : Microsoft Windows. All other operating systems are insecure. : : So, if vendors would JUMP and get it working better, and send the : OpenBSD Crew patches IMMEDIATELY, we can perhaps make a better 3.9 : release on Friday which supports all systems better. So please send : patches to them IMMEDIATELY so progress can be made. Then on Tuesday : or Friday the complete bug report with patches (and year old exploits, : we are sure) will hit BUGTRAQ(tm). : : Let me repeat: even if the bug exists in a privsep'd sshd, it is not : exploitable. Clearly we cannot yet publish what the bug is, or : provide anyone with the real patch, but we can try to get maximum : deployement of privsep, and therefore make it hurt less when the : problem is published. : : If you doubt the sincerity of this claim, please review the following : case study and included references to the security of a privilage : separation enabled open secure shell daemon's unbreakable status. : http://www.phrack.org/phrack/60/p60-0x06.txt : : : So please push your vendor to get us maximally working privsep patches : as soon as possible!!!! : : We've given most vendors since Friday last week until Thursday to get : privsep working well for you so that when the announcement comes out : next week their customers are immunized. That is nearly a full week : (but they have already wasted a weekend and a Monday). Really I think : this is the best we can hope to do (this thing will eventually leak, : at which point the details will be published). : : Customers can judge their vendors by how they respond to this issue. : : OpenBSD and NetBSD users should also update to OpenSSH 3.8 right away. : On OpenBSD privsep works flawlessly, and I have reports that is also : true on NetBSD. All other systems appear to have minor or major : weaknesses when this code is running. : : We would urge the OpenBSD Crew to remake the OpenSSH Security page : ( http://www.openssh.com/security.html ) to make it less confusing. : It would serve the public interest much better if the page listed : specifically what versions are affected by which bugs, making it clear : which versions bugs were introduced in, and which versions said bugs : have been fixed in. The current listing is too difficult to process, : and listing what versions are no longer vulnerable to a particular : known issue seems silly, since one would hope that the most recent : available version of a security PRODUCT would not suffer from any : published and widely known security problems. : : If you or your organization would like to purchase advanced details : of this vulnerability, please contact sales at idefense.com with your : inquiry. : : We at iDEFENSE would like to thank Kurt Seifried, consultant and : "OUTSIDE_INTEL" operative/analyst (and SECURITY EXPERT) for all his : hard and profound work for us. Also we would like to applaud him for : his brilliant work on translating the English translations of the CORE : Impact documentation to better English; a most impressive addition to : any resume is being able to brag of being a contractor for multiple : goverment contractors, because frankly - he is just that damn good. : : ______________________________________ : < Work for iDEFENSE and become famous! > : -------------------------------------- : \ _ : \ (_) : \ ^__^ / \ : \ (oo)\_____/_\ \ : (__)\ ) / : ||----w (( : || ||>> : : iDEFENSE is a global security intelligence company that proactively : monitors sources throughout the world from technical vulnerabilities : and hacker profiling to the global spread of viruses and other *yawn* : delicious code. Our security intelligence services provide decision : makers, frontline security professionals and network administrators : with timely access to actionable intelligence and decision support on : cyber-related threats. For more information, visit our flash enabled : interweb portal at http://www.idefense.com. : -- : Paul Cassell -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. --Linus Torvalds -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Tue May 4 17:02:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 4 May 2004 10:02:23 -0700 Subject: When submitting packages... Message-ID: <200405041002.23629.jkeating@j2solutions.net> Just a reminder to use sha1sums instead of md5s please. Sha1sums have a slightly less risk to birthday attacks, and it's how we've been doing it all along. People (QA testers) get confused if there are 2 different signatures used. Thanks! -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue May 4 18:53:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 4 May 2004 11:53:53 -0700 Subject: A plea to the people downloading from download.fedoralegacy.org (rsync access) In-Reply-To: <424CE0C8-6234-11D8-ABA5-000A957D6FD4@cc.gatech.edu> References: <200402180743.20823.jkeating@j2solutions.net> <424CE0C8-6234-11D8-ABA5-000A957D6FD4@cc.gatech.edu> Message-ID: <200405041153.53089.jkeating@j2solutions.net> On Wednesday 18 February 2004 09:02, Neil Bright wrote: > Feel free to add me to the mirrors list: > > Georgia Tech. Software Library > College of Computing > Georgia Institute of Technology > Atlanta, GA USA > > http://www.gtlib.cc.gatech.edu/pub/fedoralegacy > ftp://ftp.gtlib.cc.gatech.edu/pub/fedoralegacy > rsync://rsync.gtlib.cc.gatech.edu/fedoralegacy What IP address will you be using to rsync? I need to set up an access list. THanks! -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue May 4 19:15:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 4 May 2004 12:15:07 -0700 Subject: A plea to the people downloading from download.fedoralegacy.org (rsync access) In-Reply-To: <200405041153.53089.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> <424CE0C8-6234-11D8-ABA5-000A957D6FD4@cc.gatech.edu> <200405041153.53089.jkeating@j2solutions.net> Message-ID: <200405041215.07227.jkeating@j2solutions.net> On Tuesday 04 May 2004 11:53, Jesse Keating wrote: > What IP address will you be using to rsync? I need to set up an > access list. THanks! OOps, this wasn't supposed to go to the list. My 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue May 4 19:47:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 4 May 2004 12:47:23 -0700 Subject: Legacy Mirror List Updated Message-ID: <200405041247.26751.jkeating@j2solutions.net> I've processed all the mirror requests that I have to date. Please review the mirror list (http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php) and make sure it looks right. If you run a mirror and are not listed there, please contact me. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From john at chattanooga.net Tue May 4 20:55:40 2004 From: john at chattanooga.net (John Aldrich) Date: Tue, 4 May 2004 16:55:40 -0400 Subject: YUM help Message-ID: <200405041655.40469.john@chattanooga.net> I want to make sure my yum.conf file is correct... it seems strange to me that I should be getting a URL of www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers The "Null" is the part that's throwing me... it appears that the mirrors are not synced yet... all I'm getting is "404" errors... Here's my /etc/yum.conf... Thanks... [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 retries=20 [base] name=Fedora Core $releasever - $basearch - Base baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever baseurl=http://download.fedoralegacy.org/redhat/$releasever/os/$basearch baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/redhat/$releasever/os/$basearch baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/$releasever/os/$basearch [updates-released] name=Fedora Core $releasever - $basearch - Released Updates baseurl=http://fedora.redhat.com/updates/released/fedora-core-$releasever #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://fedora.redhat.com/updates/testing/fedora-core-$releasever #[development] #name=Fedora Core $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ [updates] name=Red Hat Linux $releasever updates baseurl=http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/redhat/$releasever/updates/$basearch baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/$releasever/legacy-utils/$basearch From ugob at camo-route.com Tue May 4 20:59:41 2004 From: ugob at camo-route.com (Ugo Bellavance) Date: Tue, 4 May 2004 16:59:41 -0400 Subject: YUM help Message-ID: <54C38A0B814C8E438EF73FC76F362927410D25@mtlnt501fs.CAMOROUTE.COM> >-----Message d'origine----- >De : John Aldrich [mailto:john at chattanooga.net] >Envoy? : 4 mai, 2004 16:56 >? : fedora-legacy-list at redhat.com >Objet : YUM help > > >I want to make sure my yum.conf file is correct... it seems >strange to me that >I should be getting a URL of >www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers >The "Null" is the part that's throwing me... it appears that >the mirrors are >not synced yet... all I'm getting is "404" errors... I think the "Null" is the problem. It looks that it cannot resolve the value of the $releasever variable. > >Here's my /etc/yum.conf... >Thanks... > >[main] >cachedir=/var/cache/yum >debuglevel=2 >logfile=/var/log/yum.log >pkgpolicy=newest >distroverpkg=fedora-release >tolerant=1 >exactarch=1 >retries=20 > >[base] >name=Fedora Core $releasever - $basearch - Base >baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever >baseurl=http://download.fedoralegacy.org/redhat/$releasever/os/ >$basearch >baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoraleg >acy.org/redhat/$releasever/os/$basearch >baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/ >$releasever/os/$basearch > >[updates-released] >name=Fedora Core $releasever - $basearch - Released Updates >baseurl=http://fedora.redhat.com/updates/released/fedora-core-$ >releasever > >#[updates-testing] >#name=Fedora Core $releasever - $basearch - Unreleased Updates >#baseurl=http://fedora.redhat.com/updates/testing/fedora-core-$ >releasever > >#[development] >#name=Fedora Core $releasever - Development Tree >#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/cor >e/development/$basearch/ > >[updates] >name=Red Hat Linux $releasever updates >baseurl=http://download.fedoralegacy.org/redhat/$releasever/upd >ates/$basearch >baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoraleg >acy.org/redhat/$releasever/updates/$basearch >baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/ >$releasever/updates/$basearch > >[legacy-utils] >name=Fedora Legacy utilities for Red Hat Linux $releasever >baseurl=http://download.fedoralegacy.org/redhat/$releasever/leg >acy-utils/$basearch >baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoraleg >acy.org/redhat/$releasever/legacy-utils/$basearch >baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/ >$releasever/legacy-utils/$basearch > > > > > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rjohnson at medata.com Tue May 4 21:10:35 2004 From: rjohnson at medata.com (Rick Johnson) Date: Tue, 04 May 2004 14:10:35 -0700 Subject: YUM help In-Reply-To: <54C38A0B814C8E438EF73FC76F362927410D25@mtlnt501fs.CAMOROUTE.COM> References: <54C38A0B814C8E438EF73FC76F362927410D25@mtlnt501fs.CAMOROUTE.COM> Message-ID: <409806CB.3010305@medata.com> Ugo Bellavance wrote: >>I want to make sure my yum.conf file is correct... it seems >>strange to me that >>I should be getting a URL of >>www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers >>The "Null" is the part that's throwing me... it appears that >>the mirrors are >>not synced yet... all I'm getting is "404" errors... > > I think the "Null" is the problem. It looks that it cannot resolve the value of the $releasever variable. > In which case, define it manually using: releasever="9" or whatnot. Do you have a custom /etc/redhat.release file (or is it missing all-together)? Also - pertaining to the original config: >[updates] >name=Red Hat Linux $releasever updates >baseurl=http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch >baseurl=ftp://mirror.physics.ncsu.edu/mirror/download.fedoralegacy.org/redhat/$releasever/updates/$basearch >baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/$releasever/updates/$basearch It could easily be said with a single baseurl= line, as long as each entry starts with one or more spaces or other white space. To simplify reordering the lines "as needed" in my case, I write it this way: baseurl= ftp:// http:// http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch This allows me to reorder the list or comment out line by line in vim w/o needing to replace the first baseurl line. I'm not sure if defining it as above will superscede the previous definition or append. If the former, it's a bad thing, if the latter, then my way's just another way of going about it. Additionally, the "updates" section may be redundant since updates-released usually contains Red Hat supplied updated as well as legacy packages. Finally - I'm seeing a mix of two versions here. Part of the INI pertains to fedora core specifically, and the other part pertains to Red Hat 7.x-9. Attached is a copy of my yum.conf which I use with Red Hat 8.0 (running Yum 2.x and an updated RPM). My Red Hat 9 config will soon look the same. HTH, -Rick -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: yum.conf URL: From john at chattanooga.net Tue May 4 21:18:59 2004 From: john at chattanooga.net (John Aldrich) Date: Tue, 4 May 2004 17:18:59 -0400 Subject: YUM help In-Reply-To: <409806CB.3010305@medata.com> References: <54C38A0B814C8E438EF73FC76F362927410D25@mtlnt501fs.CAMOROUTE.COM> <409806CB.3010305@medata.com> Message-ID: <200405041718.59613.john@chattanooga.net> On Tuesday 04 May 2004 05:10 pm, Rick Johnson wrote: > > I think the "Null" is the problem. It looks that it cannot resolve the > > value of the $releasever variable. > That's what I figured... > > In which case, define it manually using: > > releasever="9" or whatnot. > > Do you have a custom /etc/redhat.release file (or is it missing > all-together)? > Nope... here's the output of "cat /etc/redhat-release": [root at slave1 etc]# cat /etc/redhat-release Red Hat Linux release 9 (Shrike) As you can see, it's a standard redhat-release file... Dunno why it's not working. I'm gonna give your /etc/yum.conf file a shot and see if that works. :-) From john at chattanooga.net Tue May 4 21:20:46 2004 From: john at chattanooga.net (John Aldrich) Date: Tue, 4 May 2004 17:20:46 -0400 Subject: YUM help In-Reply-To: <409806CB.3010305@medata.com> References: <54C38A0B814C8E438EF73FC76F362927410D25@mtlnt501fs.CAMOROUTE.COM> <409806CB.3010305@medata.com> Message-ID: <200405041720.46616.john@chattanooga.net> On Tuesday 04 May 2004 05:10 pm, Rick Johnson wrote: > In which case, define it manually using: > > releasever="9" or whatnot. > Looks like that did it. :-) Looks like your yum.conf file also worked. :-) Thanks. From rok.papez at lugos.si Tue May 4 21:36:15 2004 From: rok.papez at lugos.si (Rok =?utf-8?q?Pape=C5=BE?=) Date: Tue, 4 May 2004 23:36:15 +0200 Subject: rsync packages for RH9, CAN-2004-0426: not properly sanitizing paths, up for QA Message-ID: <200405042336.15936.rok.papez@lugos.si> Hello Legacy. http://bugzilla.fedora.us/show_bug.cgi?id=1569 New rpms with: - Fix for segfault when RSYNC_PROXY port part is too long - Fix for CAN-2004-0426: not properly sanitizing paths http://rok.iprom.si/~rok/fedora_legacy/ 661f9891f471e213245ffe9e06b3c8e7 rsync-2.5.7-1.legacy.9.i386.rpm e1e40246c452d41b17f3392b095e2c50 rsync-2.5.7-1.legacy.9.src.rpm Please QA! An exploit for testing CAN-2004-0426 would be very appreciated :). -- best regards, Rok Pape? From whooperhsd3 at earthlink.net Tue May 4 22:10:58 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Tue, 4 May 2004 18:10:58 -0400 (EDT) Subject: YUM help In-Reply-To: <200405041655.40469.john@chattanooga.net> References: <200405041655.40469.john@chattanooga.net> Message-ID: <64727.65.40.71.237.1083708658.squirrel@65.40.71.237> John Aldrich said: > I want to make sure my yum.conf file is correct... it seems strange to me > that > I should be getting a URL of > www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers > The "Null" is the part that's throwing me... it appears that the mirrors > are > not synced yet... all I'm getting is "404" errors... Did you get this yum from Fedora Legacy? > Here's my /etc/yum.conf... > Thanks... > > [main] > cachedir=/var/cache/yum > debuglevel=2 > logfile=/var/log/yum.log > pkgpolicy=newest > distroverpkg=fedora-release ^^^^^^^^^^^^^^ That package doesn't exist on RHL. -- William Hooper From fedora at wir-sind-cool.org Wed May 5 00:53:59 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 5 May 2004 02:53:59 +0200 Subject: YUM help In-Reply-To: <200405041655.40469.john@chattanooga.net> References: <200405041655.40469.john@chattanooga.net> Message-ID: <20040505025359.410521ee.fedora@wir-sind-cool.org> On Tue, 4 May 2004 16:55:40 -0400, John Aldrich wrote: > I want to make sure my yum.conf file is correct... it seems strange to me that > I should be getting a URL of > www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers > The "Null" is the part that's throwing me... it appears that the mirrors are > not synced yet... all I'm getting is "404" errors... Which package and version of yum? The fedora.us one? From skvidal at phy.duke.edu Wed May 5 06:55:08 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 02:55:08 -0400 Subject: packages needing QA and how to QA Message-ID: <1083740108.30323.22.camel@binkley> Hi all, Some packages need some more people to check them out. This is more or less how you do that: http://www.fedoralegacy.org/wiki/index.php/QaTesting the packages that need some checking: libxml2 - https://bugzilla.fedora.us/show_bug.cgi?id=1324 gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 mozilla and friends - https://bugzilla.fedora.us/show_bug.cgi?id=1532 kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 packages that have two PUBLISH and are more or less there but wouldn't hurt from having more people try them: sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 utempter - https://bugzilla.fedora.us/show_bug.cgi?id=1546 xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 So download the packages, check the checksums, look over the patches, build/install them and tell us if things look right. the more input the less broken things will be. :) Thanks, -sv From john at chattanooga.net Wed May 5 11:11:58 2004 From: john at chattanooga.net (John Aldrich) Date: Wed, 5 May 2004 07:11:58 -0400 Subject: YUM help In-Reply-To: <64727.65.40.71.237.1083708658.squirrel@65.40.71.237> References: <200405041655.40469.john@chattanooga.net> <64727.65.40.71.237.1083708658.squirrel@65.40.71.237> Message-ID: <200405050711.58831.john@chattanooga.net> On Tuesday 04 May 2004 06:10 pm, William Hooper wrote: > John Aldrich said: > > I want to make sure my yum.conf file is correct... it seems strange to me > > that > > I should be getting a URL of > > www.gtlib.cc.gatech.edu/pub/fedoralegacy/redhat/Null/os/i386/headers > > The "Null" is the part that's throwing me... it appears that the mirrors > > are > > not synced yet... all I'm getting is "404" errors... > > Did you get this yum from Fedora Legacy? > Sure did... :-) In any event, it's working now, and all's I need to do is figure out how to automagically download and install the updates as-needed. :-) From kwan at digitalhermit.com Wed May 5 11:25:13 2004 From: kwan at digitalhermit.com (Kwan Lowe) Date: Wed, 05 May 2004 07:25:13 -0400 Subject: YUM help In-Reply-To: <200405050711.58831.john@chattanooga.net> References: <200405041655.40469.john@chattanooga.net> <64727.65.40.71.237.1083708658.squirrel@65.40.71.237> <200405050711.58831.john@chattanooga.net> Message-ID: <1083756312.6261.1.camel@deepthought.digitalhermit.com> On Wed, 2004-05-05 at 07:11, John Aldrich wrote: > id you get this yum from Fedora Legacy? > > > Sure did... :-) In any event, it's working now, and all's I need to do is > figure out how to automagically download and install the updates as-needed. THere's a yum service that you can enable via chkconfig to do this nightly: chkconfig --level 35 yum on From ncb at cc.gatech.edu Wed May 5 13:48:40 2004 From: ncb at cc.gatech.edu (Neil Bright) Date: Wed, 5 May 2004 09:48:40 -0400 Subject: A plea to the people downloading from download.fedoralegacy.org (rsync access) In-Reply-To: <200405041153.53089.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> <424CE0C8-6234-11D8-ABA5-000A957D6FD4@cc.gatech.edu> <200405041153.53089.jkeating@j2solutions.net> Message-ID: Whoops, should have included that in my original note. I'll be mirroring from zaphod.cc.gatech.edu (130.207.108.107) Thanks! On May 4, 2004, at 2:53 PM, Jesse Keating wrote: > On Wednesday 18 February 2004 09:02, Neil Bright wrote: >> Feel free to add me to the mirrors list: >> >> Georgia Tech. Software Library >> College of Computing >> Georgia Institute of Technology >> Atlanta, GA USA >> >> http://www.gtlib.cc.gatech.edu/pub/fedoralegacy >> ftp://ftp.gtlib.cc.gatech.edu/pub/fedoralegacy >> rsync://rsync.gtlib.cc.gatech.edu/fedoralegacy > > What IP address will you be using to rsync? I need to set up an access > list. THanks! +=================================================================+ Neil Bright Computing and Networking Services, ncb at cc.gatech.edu CERCS / IHPCL, College of Computing (404) 385-0448 Georgia Institute of Technology From villegas at math.gatech.edu Wed May 5 13:59:28 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Wed, 5 May 2004 09:59:28 -0400 Subject: packages needing QA and how to QA In-Reply-To: <1083740108.30323.22.camel@binkley> References: <1083740108.30323.22.camel@binkley> Message-ID: <20040505135928.GL9662@hemi.math.gatech.edu> I don't see the sysklogd one in there, is that all ready, I did the QA late yesterday, and was about to update the bugzilla on it. Everything ok with it (R: 14.legacy.9). Please let me know if it was an omision, to update the bugzilla entry. Carlos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at wir-sind-cool.org Wed May 5 14:06:05 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 5 May 2004 16:06:05 +0200 Subject: packages needing QA and how to QA In-Reply-To: <20040505135928.GL9662@hemi.math.gatech.edu> References: <1083740108.30323.22.camel@binkley> <20040505135928.GL9662@hemi.math.gatech.edu> Message-ID: <20040505160605.53dec725.fedora@wir-sind-cool.org> On Wed, 5 May 2004 09:59:28 -0400, Carlos Villegas wrote: > > I don't see the sysklogd one in there, is that all ready, I did > the QA late yesterday, and was about to update the bugzilla on > it. Everything ok with it (R: 14.legacy.9). Please let me know > if it was an omision, to update the bugzilla entry. http://fedora.us/LEGACY --> https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY --> https://bugzilla.fedora.us/show_bug.cgi?id=1553 From skvidal at phy.duke.edu Wed May 5 14:11:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 10:11:12 -0400 Subject: packages needing QA and how to QA In-Reply-To: <20040505135928.GL9662@hemi.math.gatech.edu> References: <1083740108.30323.22.camel@binkley> <20040505135928.GL9662@hemi.math.gatech.edu> Message-ID: <1083766272.30445.7.camel@opus> On Wed, 2004-05-05 at 09:59, Carlos Villegas wrote: > I don't see the sysklogd one in there, is that all ready, I did > the QA late yesterday, and was about to update the bugzilla on > it. Everything ok with it (R: 14.legacy.9). Please let me know > if it was an omision, to update the bugzilla entry. > an error of omission only. it was late and I was reading a list w/lots of lines. :) -sv From villegas at math.gatech.edu Wed May 5 14:26:07 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Wed, 5 May 2004 10:26:07 -0400 Subject: packages needing QA and how to QA In-Reply-To: <1083766272.30445.7.camel@opus> References: <1083740108.30323.22.camel@binkley> <20040505135928.GL9662@hemi.math.gatech.edu> <1083766272.30445.7.camel@opus> Message-ID: <20040505142607.GM9662@hemi.math.gatech.edu> On Wed, May 05, 2004 at 10:11:12AM -0400, seth vidal wrote: > an error of omission only. > > it was late and I was reading a list w/lots of lines. :) Thanks, I just bugzilla'ed my vote. Carlos From dwb7 at ccmr.cornell.edu Wed May 5 14:36:06 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Wed, 5 May 2004 10:36:06 -0400 Subject: packages needing QA and how to QA In-Reply-To: <1083740108.30323.22.camel@binkley>; from skvidal@phy.duke.edu on Wed, May 05, 2004 at 02:55:08 -0400 References: <1083740108.30323.22.camel@binkley> Message-ID: <20040505143606.GG10785@domino.ccmr.cornell.edu> Don't forget cvs: http://bugzilla.fedora.us/show_bug.cgi?id=1485 On 2004.05.05 02:55 seth vidal wrote: > Hi all, > Some packages need some more people to check them out. > > This is more or less how you do that: > http://www.fedoralegacy.org/wiki/index.php/QaTesting > > the packages that need some checking: > > libxml2 - https://bugzilla.fedora.us/show_bug.cgi?id=1324 > gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=1371 > cadaver - https://bugzilla.fedora.us/show_bug.cgi?id=1552 > mc - https://bugzilla.fedora.us/show_bug.cgi?id=1548 > mozilla and friends - https://bugzilla.fedora.us/show_bug.cgi?id=1532 > kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=1373 > lha - https://bugzilla.fedora.us/show_bug.cgi?id=1547 > rsync - https://bugzilla.fedora.us/show_bug.cgi?id=1569 > > packages that have two PUBLISH and are more or less there but wouldn't > hurt from having more people try them: > > sysstat - https://bugzilla.fedora.us/show_bug.cgi?id=1372 > libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1550 > utempter - https://bugzilla.fedora.us/show_bug.cgi?id=1546 > xchat - https://bugzilla.fedora.us/show_bug.cgi?id=1549 > > > > So download the packages, check the checksums, look over the patches, > build/install them and tell us if things look right. the more input > the > less broken things will be. :) > > Thanks, > -sv > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From skvidal at phy.duke.edu Wed May 5 14:46:22 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 10:46:22 -0400 Subject: packages needing QA and how to QA In-Reply-To: <20040505143606.GG10785@domino.ccmr.cornell.edu> References: <1083740108.30323.22.camel@binkley> <20040505143606.GG10785@domino.ccmr.cornell.edu> Message-ID: <1083768381.30445.22.camel@opus> On Wed, 2004-05-05 at 10:36, David Botsch wrote: > Don't forget cvs: > http://bugzilla.fedora.us/show_bug.cgi?id=1485 > Thanks - cvs, too! Sorry for missing some. Thanks to all y'all who caught the ones I missed. -sv From jjasen at realityfailure.org Wed May 5 14:50:05 2004 From: jjasen at realityfailure.org (John Jasen) Date: Wed, 5 May 2004 10:50:05 -0400 (EDT) Subject: packages needing QA and how to QA In-Reply-To: <1083768381.30445.22.camel@opus> References: <1083740108.30323.22.camel@binkley> <20040505143606.GG10785@domino.ccmr.cornell.edu> <1083768381.30445.22.camel@opus> Message-ID: Would it be possible to drop all the QA bugfixes into updates-testing, so those of us who are lazy can apt-get them? -- -- John E. Jasen (jjasen at realityfailure.org) -- No one will sorrow for me when I die, because those who would -- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring From skvidal at phy.duke.edu Wed May 5 14:52:38 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 10:52:38 -0400 Subject: packages needing QA and how to QA In-Reply-To: References: <1083740108.30323.22.camel@binkley> <20040505143606.GG10785@domino.ccmr.cornell.edu> <1083768381.30445.22.camel@opus> Message-ID: <1083768758.30445.24.camel@opus> On Wed, 2004-05-05 at 10:50, John Jasen wrote: > Would it be possible to drop all the QA bugfixes into updates-testing, so > those of us who are lazy can apt-get them? That's the point of the initial QA. So they can get to updates-testing. if everything looks ok - they go to updates-testing, then it's more or less a countdown before they get pushed, unless there is a problem. I think that's how it works. Jesse, can you clarify that? -sv From jkeating at j2solutions.net Wed May 5 14:57:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 May 2004 07:57:46 -0700 Subject: packages needing QA and how to QA In-Reply-To: <1083768758.30445.24.camel@opus> References: <1083740108.30323.22.camel@binkley> <1083768758.30445.24.camel@opus> Message-ID: <200405050757.46852.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 05 May 2004 07:52, seth vidal wrote: > That's the point of the initial QA. So they can get to updates-testing. > > if everything looks ok - they go to updates-testing, then it's more or > less a countdown before they get pushed, unless there is a problem. > > I think that's how it works. > > Jesse, can you clarify that? Pretty close. In bugzilla, they get QA for patch cleanliness, spec cleanliness, building clean, etc... If all those pass, then it should be pushed to updates-testing, where people begin to test the binary side of the package, whether it installs, functions, doesn't break other things, fixes exploit (if one available), etc... all those type of things. (note, this can be done during first QA stage as well). If multiple people voice that it works at this stage, or enough time goes by and there seems to be no interest in testing the package, it'll be pushed into full updates and a release announcement will be sent. - -- 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.3 (GNU/Linux) iD4DBQFAmQDq4v2HLvE71NURAuY6AKCtrfOTevy4uptYfGZ2YU7/3gfVQwCY694a u6QmU9ucgiyaemxDd+2VnA== =FG6V -----END PGP SIGNATURE----- From misterbawb at gmail.com Wed May 5 17:03:24 2004 From: misterbawb at gmail.com (misterbawb at gmail.com) Date: Wed, 5 May 2004 13:03:24 -0400 Subject: Self-Introduction: Daniel Drown Message-ID: Full legal name: Daniel Drown Location: Jersey City, NJ, USA Profession: Programmer Company: DataPipe Your goals in the Fedora Legacy Project: Keeping rh7.3, rh8.0, and rh9 boxes secure Historical qualifications: managing internal packages, C programming work, many legacy redhat boxes that need security updates. GPG KEYID and fingerprint: pub 1024D/A5D50305 2004-05-05 Daniel Drown Key fingerprint = 4E91 A416 EAC0 C2E9 E9D2 561C 6A26 614F A5D5 0305 sub 2048g/7A4EE589 2004-05-05 [expires: 2009-05-04] From bhirt at mobygames.com Wed May 5 17:07:45 2004 From: bhirt at mobygames.com (Brian Hirt) Date: Wed, 5 May 2004 11:07:45 -0600 Subject: yum installation management. Message-ID: Like lots of users out there, my company used to use Red Hat Network to support our boxes. One of the things i really liked about RHN was that you could remotely administer a bunch of servers fairly easily without having to log onto each machine to check for updates or to install updates. I'm aware that Yum and others packages can be run from cron to automatically install packages. However, if you want a little bit more control over what you install and when you install them, I haven't seen something out there that suits me. I spent some time whipping up a little system that is similar to RHN. The administration is from a web page where you can view which components on your servers are out of date and request that the remotely administered systems update certain packages. Each of the remotely administered systems checks in with the central database and updates packages that it's been requested to update. The administered boxes also notify the central server when if finds new packages that should be updated. The system is written entirely in perl, and has three components. There is one mod_perl program running on the webserver, and two client programs that run on each of the administered boxes. One of the clients performs the updates, and the other client checks nightly to see if there are new packages that need updating. All of the state is stored in a backend SQL database. I'm using postgresql, but as it's a fairly simple system using basic SQL, i have no doubts that mysql could easily be used too. So, before i go on and on about this slightly off topic email I wanted to find out if other people might be interested in a system like this that they could use in their own installations. I'd like to make this project open, but don't really know how many people would find such a system useful. So, the purpose of this email is to gauge if there is any interest in such a project and to let people know about it. If you have any interest is a project like this, I would love to talk to you and get your ideas. From skvidal at phy.duke.edu Wed May 5 17:14:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 13:14:17 -0400 Subject: yum installation management. In-Reply-To: References: Message-ID: <1083777257.30445.46.camel@opus> On Wed, 2004-05-05 at 13:07, Brian Hirt wrote: > Like lots of users out there, my company used to use Red Hat Network to > support our boxes. One of the things i really liked about RHN was > that you could remotely administer a bunch of servers fairly easily > without having to log onto each machine to check for updates or to > install updates. I'm aware that Yum and others packages can be run > from cron to automatically install packages. However, if you want a > little bit more control over what you install and when you install > them, I haven't seen something out there that suits me. > > I spent some time whipping up a little system that is similar to RHN. > The administration is from a web page where you can view which > components on your servers are out of date and request that the > remotely administered systems update certain packages. Each of the > remotely administered systems checks in with the central database and > updates packages that it's been requested to update. The administered > boxes also notify the central server when if finds new packages that > should be updated. > If someone wants to run that in their infrastructure that's fine but I don't think fedoralegacy has the machine power or human power to maintain something like that. -sv From bhirt at mobygames.com Wed May 5 17:36:37 2004 From: bhirt at mobygames.com (Brian Hirt) Date: Wed, 5 May 2004 11:36:37 -0600 Subject: yum installation management. In-Reply-To: <1083777257.30445.46.camel@opus> References: <1083777257.30445.46.camel@opus> Message-ID: I guess i wasn't being really clear. It would be something that individuals would run an their own infrastructure. Hence, my original post is slightly off topic, because it would work with any yum setup, not just the use fedora legacy project. --brian On May 5, 2004, at 11:14 AM, seth vidal wrote: > On Wed, 2004-05-05 at 13:07, Brian Hirt wrote: >> Like lots of users out there, my company used to use Red Hat Network >> to >> support our boxes. One of the things i really liked about RHN was >> that you could remotely administer a bunch of servers fairly easily >> without having to log onto each machine to check for updates or to >> install updates. I'm aware that Yum and others packages can be run >> from cron to automatically install packages. However, if you want a >> little bit more control over what you install and when you install >> them, I haven't seen something out there that suits me. >> >> I spent some time whipping up a little system that is similar to RHN. >> The administration is from a web page where you can view which >> components on your servers are out of date and request that the >> remotely administered systems update certain packages. Each of the >> remotely administered systems checks in with the central database and >> updates packages that it's been requested to update. The administered >> boxes also notify the central server when if finds new packages that >> should be updated. >> > > If someone wants to run that in their infrastructure that's fine but I > don't think fedoralegacy has the machine power or human power to > maintain something like that. > > -sv > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From skvidal at phy.duke.edu Wed May 5 17:38:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 05 May 2004 13:38:36 -0400 Subject: yum installation management. In-Reply-To: References: <1083777257.30445.46.camel@opus> Message-ID: <1083778716.30445.50.camel@opus> On Wed, 2004-05-05 at 13:36, Brian Hirt wrote: > I guess i wasn't being really clear. It would be something that > individuals would run an their own infrastructure. Hence, my original > post is slightly off topic, because it would work with any yum setup, > not just the use fedora legacy project. > Ah - then I think telling people about that here, or on fedora-list or one of many lists is appropriate. -sv From ssharma at revsharecorp.com Wed May 5 18:30:25 2004 From: ssharma at revsharecorp.com (Ajay Sharma) Date: Wed, 05 May 2004 11:30:25 -0700 Subject: yum installation management. In-Reply-To: References: Message-ID: <409932C1.9090804@revsharecorp.com> Brian Hirt wrote: > I spent some time whipping up a little system that is similar to RHN. > The administration is from a web page where you can view which > components on your servers are out of date and request that the remotely > administered systems update certain packages. I liked logging into a webpage and updating a dozen servers too. Logging into each box is a pain... Maybe you can hook up with the NRH-up2date project: http://www.nrh-up2date.org/ later, ajay -- Satyajot (Ajay) Sharma RevShare Corp System Administrator From michal at harddata.com Wed May 5 19:00:51 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 5 May 2004 13:00:51 -0600 Subject: netpbm changes Message-ID: <20040505125950.A5611@mail.harddata.com> I added a spec file to https://bugzilla.fedora.us/show_bug.cgi?id=1257 which is using patches attached to that report. Packages recompiled with that look fine to me but somebody with RH8 installation needs to have a look if things do not need to be modified there. On 7.x installations this works fine for me but have a look. This report references RPMS posted on 2004-02-25 by John Dalbec but, unfortunately, these are broken (the assume 'mktemp' utility with more capabilities than what is available by default). Michal From villegas at math.gatech.edu Wed May 5 20:14:34 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Wed, 5 May 2004 16:14:34 -0400 Subject: proposed changes for the web page Message-ID: <20040505201434.GN9662@hemi.math.gatech.edu> Some minor (and not so minor) comments on the web page and stuff: 1. When trying to checkout the CVS tree for the web page, it requires a password that is not specified in the instructions. I'm not sure if this is a temporary thing during the server move. I would have sent a patch instead of this email :) 2. The "Self introduction" stuff should be linked from the "Participate" section as well, I personally had a hard time finding it, and only found it because I knew it existed and looked for it. 3. A minor improvement I wanted to make was to allow legacy searches on bugzilla by version, so I wanted to add some links, that provide the functionality that currently exists at: http://fedora.us/LEGACY but a little bit more finegrained (allow version specific searches), the links should be: All legacy bugs: https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY All legacy bugs affecting RHL 9: https://bugzilla.fedora.us/buglist.cgi?keywords_type=allwords&keywords=LEGACY+rh90 And so on. The purpose of that is to easily construct lists by releases, so that people like me who can only do QA for one release can focus on those. 4. I think either the wiki should dissappear (and all it's information should be merged onto the (static) webpage, or the wiki should be a "mirror" of the webpage, being an alternative to cvs modifications, and such. The reason is that I think it's kind of confusing to have some stuff, like the QA "guidelines" under the wiki and not under "the real" web page. Carlos From jackie.m at vt.edu Thu May 6 00:36:08 2004 From: jackie.m at vt.edu (Jackie Meese) Date: Wed, 5 May 2004 20:36:08 -0400 Subject: yum installation management. In-Reply-To: <409932C1.9090804@revsharecorp.com> References: <409932C1.9090804@revsharecorp.com> Message-ID: <5DE8FFE4-9EF5-11D8-95CB-000A95AC794E@vt.edu> On May 5, 2004, at 2:30 PM, Ajay Sharma wrote: > Brian Hirt wrote: >> I spent some time whipping up a little system that is similar to RHN. >> The administration is from a web page where you can view which >> components on your servers are out of date and request that the >> remotely administered systems update certain packages. > > I liked logging into a webpage and updating a dozen servers too. > Logging into each box is a pain... Maybe you can hook up with the > NRH-up2date project: > > http://www.nrh-up2date.org/ My preference for command line and instant, admin run commands on multiple machine has led me to find mrsh a useful tool. It's tasty when combined with yum (or up2date-nox). http://www.unicom.com/sw/mrsh/ It's not been updated in years, but it's a simple and elegant shell script, so it doesn't really need to be. I recommend ssh and aliases. My favorite alias: $73mrsh -- yum install package will install the package "package" to all machines listed in the "73mrsh" command alias. ---- Jackie Meese, Systems Administrator Institute for Distance and Distributed Learning, Va Tech Phone: 231-3682 http://www.iddl.vt.edu/ 3027 Torgersen Hall Mail Code: 0445 I am, and always will be, an idiot. From fleck004 at umn.edu Thu May 6 17:16:13 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Thu, 6 May 2004 12:16:13 -0500 Subject: Problem with GPG Key In-Reply-To: References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> Message-ID: <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> Hi - I posted previously about this problem. It hasn't gone away. I'm unable to use yum because of the following error: >>> Error: GPG Signature check failed for /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm You may also want to check to make sure you have the right gpg keys Exiting. <<< Today I uninstalled (rpm -e yum), then reinstalled yum (from download.fedoralegacy.ort) but I still get the gpg error. Here are versions, if that's any help: # rpm -q gnupg python rpm rpm-python gnupg-1.0.7-13 python-1.5.2-43.72 rpm-4.0.4-7x rpm-python-4.0.4-7x Any ideas on how to proceed in getting this to work would be truly appreciated. Thanks. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From jkeating at j2solutions.net Thu May 6 17:26:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 6 May 2004 10:26:00 -0700 Subject: Problem with GPG Key In-Reply-To: <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> References: <20040503071416.GC1544@batman.gotham.krass.com> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> Message-ID: <200405061026.03288.jkeating@j2solutions.net> On Thursday 06 May 2004 10:16, Peter Fleck wrote: > Today I uninstalled (rpm -e yum), then reinstalled yum (from > download.fedoralegacy.ort) but I still get the gpg error. Here are > versions, if that's any help: > > # rpm -q gnupg python rpm rpm-python > gnupg-1.0.7-13 > python-1.5.2-43.72 > rpm-4.0.4-7x > rpm-python-4.0.4-7x > > Any ideas on how to proceed in getting this to work would be truly > appreciated. Thanks. A) Remove the cache file B) double check that you imported the Legacy GPG key from our website (not the key server) C) Manually verify key (rpm --checksig foo.rpm) D) sacrifice a chicken -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Thu May 6 18:49:53 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 6 May 2004 13:49:53 -0500 Subject: Problem with GPG Key In-Reply-To: <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> Message-ID: <20040506134953.ts00wco8c0c80ws8@mail.ph.utexas.edu> Quoting Peter Fleck : > Error: GPG Signature check failed for > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm Either you didn't install the GPG keys for FedoraLegacy, or the file download was corrupted. > You may want to run yum clean or remove the file: > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > You may also want to check to make sure you have the right gpg keys > Exiting. Yep, what it says. If you do an rpm --checksig, I think that will tell you which is the problem (the key isn't installed, or the file is corrupted). > Today I uninstalled (rpm -e yum), then reinstalled yum (from > download.fedoralegacy.ort) but I still get the gpg error. Here are > versions, if that's any help: Did you install the keys after you installed the RPM? If it is the keys are not installed, then install them. If it is the file is corrupted, then use a different mirror site. -- Eric Rostetter From bhughes at elevating.com Thu May 6 19:33:56 2004 From: bhughes at elevating.com (Bret Hughes) Date: 06 May 2004 14:33:56 -0500 Subject: Please Use the Mirrors! In-Reply-To: <200405031337.21863.jkeating@j2solutions.net> References: <200405031337.21863.jkeating@j2solutions.net> Message-ID: <1083872037.24024.62.camel@bretsony> On Mon, 2004-05-03 at 15:37, Jesse Keating wrote: > Bandwith is very precious on the master download.fedoralegacy.org server > as we are transitioning to the new server. People have been using > download exclusively had effectively DDoSing the system so that all > other services drop off. I'm asking once more to please use one of the > mirrors until we get things sorted out. Thanks. Perhaps something on the index page of download.fedoralegacy.org that says "Please use the mirrors" and give some links to them. Right now there is no indication that you do not want folks to use the site. Also on fedoralegacy.org/download/ change the link under "Manually downloading specific packages" to point to the mirrors page rather than download.fedoralegacy.org. Seems to me that rsync would help people create local repositories for their company's use. Even if they have only 3 or four machines, it has to be made easy for them to create the repo. I can't remember the issue, but several months ago I tried to use mirror to create the tree so I could aptify my local tree but could not get it to work (and no, I do not do recursive listings). I can try again if you like. I don't have the bandwidth to be a true mirror site but I could save some band width for you with local mirrored trees. This is going to be much more of an issue now that RHL 9 is there too. Bret From villegas at math.gatech.edu Thu May 6 19:55:27 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Thu, 6 May 2004 15:55:27 -0400 Subject: Please Use the Mirrors! In-Reply-To: <1083872037.24024.62.camel@bretsony> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> Message-ID: <20040506195527.GD4976@hemi.math.gatech.edu> Along the same lines, there is a "default yum.conf" file in the download section, which has no mirrors in it, it should probably have all the mirrors, also I think that file should be automatically generated with php to contain all the mirrors, in some random order, and a comment both in the config file and in the web page asking people to organize the mirrors as appropiate, I'd also force gpg checks in the default config file. Let me know (off list) if you need help writting that php. Carlos From strange at nsk.no-ip.org Thu May 6 21:18:58 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 6 May 2004 22:18:58 +0100 Subject: Please Use the Mirrors! In-Reply-To: <20040506195527.GD4976@hemi.math.gatech.edu>; from villegas@math.gatech.edu on Thu, May 06, 2004 at 03:55:27PM -0400 References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> Message-ID: <20040506221858.B19354@nsk.no-ip.org> On Thu, May 06, 2004 at 03:55:27PM -0400, Carlos Villegas wrote: > > Along the same lines, there is a "default yum.conf" file in the > download section, which has no mirrors in it, it should probably > have all the mirrors, also I think that file should be automatically > generated with php to contain all the mirrors, in some random > order, and a comment both in the config file and in the web page > asking people to organize the mirrors as appropiate, I'd also > force gpg checks in the default config file. Let me know (off > list) if you need help writting that php. Better yet, have yum support redirects (I don't know if it doesn't already) and have the yum.conf point to a dynamic webpage that redirects to a local mirror for the client (using the cpan module for country location, or something of the like). The same could be said for the download webpage. In extremis, deny completely download from the master server from normal clients. (Some other projects do that, I don't see any problem with the project adopting the same policy.) Regards, Luciano Rocha From dom at earth.li Fri May 7 00:26:37 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 7 May 2004 01:26:37 +0100 Subject: Kernel updates for QA Message-ID: <20040507002636.GS960@tirian.magd.ox.ac.uk> Hi, I've put up some packages for QA at http://bugzilla.fedora.us/show_bug.cgi?id=1484 Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From fleck004 at umn.edu Thu May 6 23:46:28 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Thu, 6 May 2004 18:46:28 -0500 Subject: Problem with GPG Key Message-ID: <98161F78-9FB7-11D8-9EAE-00039303286A@umn.edu> On May 6, 2004, at 12:26 PM, Jesse Keating wrote: > > A) Remove the cache file > B) double check that you imported the Legacy GPG key from our website > (not the key server) > C) Manually verify key (rpm --checksig foo.rpm) > D) sacrifice a chicken I did all of the above. It's a bloody mess here with the chicken feathers and all but I still get the error. > Error: GPG Signature check failed for > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm for any file I attempt. rpm --checksig verifies the signature, I downloaded the signature again from the legacy site and imported (already there), I tried the legacy site and a mirror, deleting the entire cache both times. I'm stumped and don't have much experience in this area. Should I uninstall/reinstall gnupg? Thanks. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From davej at redhat.com Fri May 7 00:39:24 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 7 May 2004 01:39:24 +0100 Subject: Kernel updates for QA In-Reply-To: <20040507002636.GS960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> Message-ID: <20040507003924.GA31018@redhat.com> On Fri, May 07, 2004 at 01:26:37AM +0100, Dominic Hargreaves wrote: > Hi, > > I've put up some packages for QA at > http://bugzilla.fedora.us/show_bug.cgi?id=1484 cpufreq *is* in RHL9 kernel, and is vulnerable. Other than that, looks like you've got it covered. You may also need the qla2300 perms fix (fixed in SuSE update kernels, missed everywhere else). Not sure if that driver made it into RHL9, and I don't have an unpacked source tree handy. Diff below. Dave --- linux-2.4.21/drivers/scsi/qla2xxx-60500/qla2x00.c.secfix 2004-02-10 09:28:33.000000000 +0100 +++ linux-2.4.21/drivers/scsi/qla2xxx-60500/qla2x00.c 2004-04-23 13:14:07.000000000 +0200 @@ -17298,10 +17298,10 @@ #ifndef __VMWARE__ // XXX: Fix this when proc_mknod works again on main!!! #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)MKDEV(apidev_major, 0)); #else - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)mk_kdev(apidev_major, 0)); #endif #endif //__VMWARE__ --- linux-2.4.21/drivers/scsi/qla2xxx-60650/qla2x00.c.secfix 2004-02-10 09:28:33.000000000 +0100 +++ linux-2.4.21/drivers/scsi/qla2xxx-60650/qla2x00.c 2004-04-23 13:14:07.000000000 +0200 @@ -18757,10 +18757,10 @@ #ifndef __VMWARE__ // XXX: Fix this when proc_mknod works again on main!!! #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)MKDEV(apidev_major, 0)); #else - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)mk_kdev(apidev_major, 0)); #endif #endif //__VMWARE__ --- linux-2.4.21/drivers/scsi/qla2xxx/qla2x00.c.secfix 2004-02-10 09:29:30.000000000 +0100 +++ linux-2.4.21/drivers/scsi/qla2xxx/qla2x00.c 2004-04-23 11:22:59.000000000 +0200 @@ -18720,10 +18720,10 @@ #ifndef __VMWARE__ // XXX: Fix this when proc_mknod works again on main!!! #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)MKDEV(apidev_major, 0)); #else - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, (kdev_t)mk_kdev(apidev_major, 0)); #endif #endif //__VMWARE__ From skvidal at phy.duke.edu Thu May 6 21:23:16 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 06 May 2004 17:23:16 -0400 Subject: Please Use the Mirrors! In-Reply-To: <20040506221858.B19354@nsk.no-ip.org> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> <20040506221858.B19354@nsk.no-ip.org> Message-ID: <1083878596.27730.86.camel@opus> > Better yet, have yum support redirects (I don't know if it doesn't > already) and have the yum.conf point to a dynamic webpage that redirects > to a local mirror for the client (using the cpan module for country > location, or something of the like). yum supports http redirects but it doesn't support javascript redirects or META refresh redirects (nor will it, so don't ask! :) -sv From mattdm at mattdm.org Thu May 6 21:33:29 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 May 2004 17:33:29 -0400 Subject: netpbm changes In-Reply-To: <20040505125950.A5611@mail.harddata.com> References: <20040505125950.A5611@mail.harddata.com> Message-ID: <20040506213329.GA30823@jadzia.bu.edu> On Wed, May 05, 2004 at 01:00:51PM -0600, Michal Jaegermann wrote: > I added a spec file to > https://bugzilla.fedora.us/show_bug.cgi?id=1257 > which is using patches attached to that report. Packages recompiled > with that look fine to me but somebody with RH8 installation > needs to have a look if things do not need to be modified there. > On 7.x installations this works fine for me but have a look. > This report references RPMS posted on 2004-02-25 by John Dalbec > but, unfortunately, these are broken (the assume 'mktemp' > utility with more capabilities than what is available by default). Yeah. Broken in RHL 9, and the promised update never showed up. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at wir-sind-cool.org Thu May 6 19:34:37 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 6 May 2004 21:34:37 +0200 Subject: Problem with GPG Key In-Reply-To: <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> Message-ID: <20040506213437.52a6214a.fedora@wir-sind-cool.org> On Thu, 6 May 2004 12:16:13 -0500, Peter Fleck wrote: > Hi - I posted previously about this problem. It hasn't gone away. > > I'm unable to use yum because of the following error: > >>> > Error: GPG Signature check failed for > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > You may want to run yum clean or remove the file: > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > You may also want to check to make sure you have the right gpg keys > Exiting. > <<< Run rpm -Kv /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm and post the output. From fleck004 at umn.edu Thu May 6 20:04:59 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Thu, 6 May 2004 15:04:59 -0500 Subject: Problem with GPG Key Message-ID: On May 6, 2004, at 12:26 PM, Jesse Keating wrote: > > A) Remove the cache file > B) double check that you imported the Legacy GPG key from our website > (not the key server) > C) Manually verify key (rpm --checksig foo.rpm) > D) sacrifice a chicken I did all of the above. It's a bloody mess here with the chicken feathers and all but I still get the error. > Error: GPG Signature check failed for > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm for any file I attempt. rpm --checksig verifies the signature, I downloaded the signature again from the legacy site and imported (already there), I tried the legacy site and a mirror, deleting the entire cache both times. I'm stumped and don't have much experience in this area. Should I uninstall/reinstall gnupg? Thanks. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From michal at harddata.com Fri May 7 01:21:50 2004 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 6 May 2004 19:21:50 -0600 Subject: netpbm changes In-Reply-To: <20040506213329.GA30823@jadzia.bu.edu>; from mattdm@mattdm.org on Thu, May 06, 2004 at 05:33:29PM -0400 References: <20040505125950.A5611@mail.harddata.com> <20040506213329.GA30823@jadzia.bu.edu> Message-ID: <20040506192150.A22739@mail.harddata.com> On Thu, May 06, 2004 at 05:33:29PM -0400, Matthew Miller wrote: > > Yeah. Broken in RHL 9, and the promised update never showed up. Sure that it is broken in RHL 9? It seemed to me that update was using an option to 'mktemp' which exists there, and does the right thing, but which is not available in earlier versions (which implies that this fix needs to be somewhat different). Anyway, we are talking about some overdue stuff which does not depend on RHL 9. Michal From jkeating at j2solutions.net Thu May 6 19:39:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 6 May 2004 12:39:05 -0700 Subject: Please Use the Mirrors! In-Reply-To: <1083872037.24024.62.camel@bretsony> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> Message-ID: <200405061239.05577.jkeating@j2solutions.net> On Thursday 06 May 2004 12:33, Bret Hughes wrote: > Perhaps something on the index page of download.fedoralegacy.org that > says "Please use the mirrors" and give some links to them. Right now > there is no indication that you do not want folks to use the site. > > Also on fedoralegacy.org/download/ change the link under "Manually > downloading specific packages" to point to the mirrors page rather > than download.fedoralegacy.org. > > Seems to me that rsync would help people create local repositories > for their company's use. Even if they have only 3 or four machines, > it has to be made easy for them to create the repo. I can't remember > the issue, but several months ago I tried to use mirror to create the > tree so I could aptify my local tree but could not get it to work > (and no, I do not do recursive listings). I can try again if you > like. > > I don't have the bandwidth to be a true mirror site but I could save > some band width for you with local mirrored trees. This is going to > be much more of an issue now that RHL 9 is there too. This is now much less of an issue. The issue was never intended to last this long, however it did. Now we're with a new host on new hardware and things should just work fine. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From whooperhsd3 at earthlink.net Fri May 7 02:18:09 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Thu, 6 May 2004 22:18:09 -0400 (EDT) Subject: Problem with GPG Key In-Reply-To: <98161F78-9FB7-11D8-9EAE-00039303286A@umn.edu> References: <98161F78-9FB7-11D8-9EAE-00039303286A@umn.edu> Message-ID: <65037.65.40.71.237.1083896289.squirrel@65.40.71.237> Peter Fleck said: >> Error: GPG Signature check failed for >> /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > > for any file I attempt. rpm --checksig verifies the signature, As root? -- William Hooper From ow.mun.heng at wdc.com Fri May 7 03:12:39 2004 From: ow.mun.heng at wdc.com (Ow Mun Heng) Date: Fri, 7 May 2004 11:12:39 +0800 Subject: Kernel updates for QA Message-ID: > -----Original Message----- > From: Dave Jones [mailto:davej at redhat.com] > Sent: Friday, May 07, 2004 8:39 AM > To: Discussion of the Fedora Legacy Project > Subject: Re: Kernel updates for QA > > > On Fri, May 07, 2004 at 01:26:37AM +0100, Dominic Hargreaves wrote: > > Hi, > > > > I've put up some packages for QA at > > http://bugzilla.fedora.us/show_bug.cgi?id=1484 > > cpufreq *is* in RHL9 kernel, and is vulnerable. > Other than that, looks like you've got it covered. > You may also need the qla2300 perms fix (fixed in SuSE update > kernels, missed everywhere else). Not sure if that driver > made it into RHL9, and I don't have an unpacked source tree > handy. Diff below. Sorry for being ignorant. But what is the vulneralbility on cpufreq?? I'm on RH9 on a 2.6.3 kernel. The diff below, I only see references to vmware for the qla2300. (This is a scsi driver right? based that on the file pathname) > > Dave > > --- linux-2.4.21/drivers/scsi/qla2xxx-60500/qla2x00.c.secfix > 2004-02-10 09:28:33.000000000 +0100 > +++ linux-2.4.21/drivers/scsi/qla2xxx-60500/qla2x00.c > 2004-04-23 13:14:07.000000000 +0200 > @@ -17298,10 +17298,10 @@ > #ifndef __VMWARE__ > // XXX: Fix this when proc_mknod works again on main!!! > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)MKDEV(apidev_major, 0)); > #else > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)mk_kdev(apidev_major, 0)); > #endif > #endif //__VMWARE__ > --- linux-2.4.21/drivers/scsi/qla2xxx-60650/qla2x00.c.secfix > 2004-02-10 09:28:33.000000000 +0100 > +++ linux-2.4.21/drivers/scsi/qla2xxx-60650/qla2x00.c > 2004-04-23 13:14:07.000000000 +0200 > @@ -18757,10 +18757,10 @@ > #ifndef __VMWARE__ > // XXX: Fix this when proc_mknod works again on main!!! > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)MKDEV(apidev_major, 0)); > #else > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)mk_kdev(apidev_major, 0)); > #endif > #endif //__VMWARE__ > --- linux-2.4.21/drivers/scsi/qla2xxx/qla2x00.c.secfix > 2004-02-10 09:29:30.000000000 +0100 > +++ linux-2.4.21/drivers/scsi/qla2xxx/qla2x00.c > 2004-04-23 11:22:59.000000000 +0200 > @@ -18720,10 +18720,10 @@ > #ifndef __VMWARE__ > // XXX: Fix this when proc_mknod works again on main!!! > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)MKDEV(apidev_major, 0)); > #else > - proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir, > + proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir, > (kdev_t)mk_kdev(apidev_major, 0)); > #endif > #endif //__VMWARE__ > > > -- > 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 Fri May 7 04:36:39 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 May 2004 00:36:39 -0400 Subject: netpbm changes In-Reply-To: <20040506192150.A22739@mail.harddata.com> References: <20040505125950.A5611@mail.harddata.com> <20040506213329.GA30823@jadzia.bu.edu> <20040506192150.A22739@mail.harddata.com> Message-ID: <20040507043639.GA12145@jadzia.bu.edu> On Thu, May 06, 2004 at 07:21:50PM -0600, Michal Jaegermann wrote: > > Yeah. Broken in RHL 9, and the promised update never showed up. > Sure that it is broken in RHL 9? It seemed to me that update Pretty sure. > was using an option to 'mktemp' which exists there, and does the > right thing, but which is not available in earlier versions Nope -- the needed mktemp first appeared in FC. Red Hat Linux 9's version is too old to have the option which the last RHL9 netpbm update uses. See: Shouldn't ever have gotten past QA; should have been fixed pretty fast when the mistake was realized. Or at the very least, when an outsider pointed it out and filed a bug report. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From michal at harddata.com Fri May 7 06:30:55 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 7 May 2004 00:30:55 -0600 Subject: netpbm changes In-Reply-To: <20040507043639.GA12145@jadzia.bu.edu>; from mattdm@mattdm.org on Fri, May 07, 2004 at 12:36:39AM -0400 References: <20040505125950.A5611@mail.harddata.com> <20040506213329.GA30823@jadzia.bu.edu> <20040506192150.A22739@mail.harddata.com> <20040507043639.GA12145@jadzia.bu.edu> Message-ID: <20040507003055.C29012@mail.harddata.com> On Fri, May 07, 2004 at 12:36:39AM -0400, Matthew Miller wrote: > On Thu, May 06, 2004 at 07:21:50PM -0600, Michal Jaegermann wrote: > > Sure that it is broken in RHL 9? It seemed to me that update > > Pretty sure. > > > was using an option to 'mktemp' which exists there, and does the > > right thing, but which is not available in earlier versions > > Nope -- the needed mktemp first appeared in FC. Oh, well. In that case what I posted in comments to https://bugzilla.fedora.us/show_bug.cgi?id=1257 should work ok, maybe with minor adaptations, on RHL9 too. Michal From gary.stainburn at ringways.co.uk Fri May 7 09:30:58 2004 From: gary.stainburn at ringways.co.uk (Gary Stainburn) Date: Fri, 7 May 2004 10:30:58 +0100 Subject: Please Use the Mirrors! In-Reply-To: <20040506195527.GD4976@hemi.math.gatech.edu> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> Message-ID: <200405071030.58154.gary.stainburn@ringways.co.uk> On Thursday 06 May 2004 8:55 pm, Carlos Villegas wrote: > Along the same lines, there is a "default yum.conf" file in the > download section, which has no mirrors in it, it should probably > have all the mirrors, also I think that file should be automatically > generated with php to contain all the mirrors, in some random > order, and a comment both in the config file and in the web page > asking people to organize the mirrors as appropiate, I'd also > force gpg checks in the default config file. Let me know (off > list) if you need help writting that php. > > Carlos A simple to implement half-way point would be to simply have appropriate yum.conf files listed on the mirror page so that people could simply download and use the appropriate one. -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 From gary.stainburn at ringways.co.uk Fri May 7 09:33:50 2004 From: gary.stainburn at ringways.co.uk (Gary Stainburn) Date: Fri, 7 May 2004 10:33:50 +0100 Subject: Please Use the Mirrors! In-Reply-To: <1083872037.24024.62.camel@bretsony> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> Message-ID: <200405071033.50197.gary.stainburn@ringways.co.uk> On Thursday 06 May 2004 8:33 pm, Bret Hughes wrote: [snip] > Seems to me that rsync would help people create local repositories for > their company's use. Even if they have only 3 or four machines, it has > to be made easy for them to create the repo. I can't remember the > issue, but several months ago I tried to use mirror to create the tree > so I could aptify my local tree but could not get it to work (and no, I > do not do recursive listings). I can try again if you like. As someone who has only briefly looked at rsync, would it be possible for someone to knock up a small HOWTO. I've corrently only got one server and one laptop running FC1, but having seen it perform, it's likely that I'm going to upgrade my 6-7 RH7.3 boxes soon. > > I don't have the bandwidth to be a true mirror site but I could save > some band width for you with local mirrored trees. This is going to be > much more of an issue now that RHL 9 is there too. > > Bret -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 From davej at redhat.com Fri May 7 10:42:06 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 7 May 2004 11:42:06 +0100 Subject: Kernel updates for QA In-Reply-To: References: Message-ID: <20040507104206.GE31018@redhat.com> On Fri, May 07, 2004 at 11:12:39AM +0800, Ow Mun Heng wrote: > Sorry for being ignorant. But what is the vulneralbility on cpufreq?? Users can read arbitary regions of memory using cpufreq's /proc handler. > I'm on RH9 on a 2.6.3 kernel. It's fixed in 2.6.6rc3 > The diff below, I only see references to vmware for the qla2300. > (This is a scsi driver right? based that on the file pathname) Duhh, wasn't thinking last night. This looks like a SuSE-specific addition. Dave From drees at greenhydrant.com Fri May 7 13:05:19 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 07 May 2004 06:05:19 -0700 Subject: Please Use the Mirrors! In-Reply-To: <200405071033.50197.gary.stainburn@ringways.co.uk> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <200405071033.50197.gary.stainburn@ringways.co.uk> Message-ID: <409B898F.5070907@greenhydrant.com> Gary Stainburn wrote, On 5/7/2004 2:33 AM: > On Thursday 06 May 2004 8:33 pm, Bret Hughes wrote: > >>Seems to me that rsync would help people create local repositories for >>their company's use. Even if they have only 3 or four machines, it has >>to be made easy for them to create the repo. I can't remember the >>issue, but several months ago I tried to use mirror to create the tree >>so I could aptify my local tree but could not get it to work (and no, I >>do not do recursive listings). I can try again if you like. > > As someone who has only briefly looked at rsync, would it be possible for > someone to knock up a small HOWTO. > > I've corrently only got one server and one laptop running FC1, but having seen > it perform, it's likely that I'm going to upgrade my 6-7 RH7.3 boxes soon. If the goal is to save bandwidth, installing a local caching proxy like squid is a good idea, just make sure that you set the maximum file size to something large enough to cover the biggest RPM in the repository. Typically machines will do a number of things in day-to-day operation, check for the latest headers, and download updates. Both of those operations will be cached by the local proxy. The downside of rsync is that you need to run it periodically, and there will be quite a large amount of storage space required as well. However, if you still want to rsync, this command will work: rsync -rpt --delete \ --exclude="lost+found" --exclude=\*.src.rpm \ ${SERVER}/redhat/7.3 ${LOCALREPO} Replace ${SERVER} with a mirror, and ${LOCALREPO} with your local repository directory. Note that this command only mirrors the redhat 7.3 repository. -Dave From fleck004 at umn.edu Fri May 7 13:36:03 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Fri, 7 May 2004 08:36:03 -0500 Subject: Problem with GPG Key In-Reply-To: <20040506213437.52a6214a.fedora@wir-sind-cool.org> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> <20040506213437.52a6214a.fedora@wir-sind-cool.org> Message-ID: <7C582437-A02B-11D8-918D-00039303286A@umn.edu> > Run > > rpm -Kv > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > > and post the output. [root at seafish fleck004]# rpm -Kv /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm: MD5 sum OK: 084e0d35954655739b8d074ac2a4044f gpg: Signature made Sat 24 Jan 2004 02:01:34 AM CST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA Looks like something is wrong here. On May 6, 2004, at 2:34 PM, Michael Schwendt wrote: > On Thu, 6 May 2004 12:16:13 -0500, Peter Fleck wrote: > >> Hi - I posted previously about this problem. It hasn't gone away. >> >> I'm unable to use yum because of the following error: >>>>> >> Error: GPG Signature check failed for >> /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm >> You may want to run yum clean or remove the file: >> /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm >> You may also want to check to make sure you have the right gpg keys >> Exiting. >> <<< > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From fleck004 at umn.edu Fri May 7 13:36:29 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Fri, 7 May 2004 08:36:29 -0500 Subject: Problem with GPG Key In-Reply-To: <65037.65.40.71.237.1083896289.squirrel@65.40.71.237> References: <98161F78-9FB7-11D8-9EAE-00039303286A@umn.edu> <65037.65.40.71.237.1083896289.squirrel@65.40.71.237> Message-ID: <8BE80EA9-A02B-11D8-918D-00039303286A@umn.edu> On May 6, 2004, at 9:18 PM, William Hooper wrote: > > Peter Fleck said: >>> Error: GPG Signature check failed for >>> /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm >> >> for any file I attempt. rpm --checksig verifies the signature, > > As root? Yes, as root. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From gary.stainburn at ringways.co.uk Fri May 7 13:28:03 2004 From: gary.stainburn at ringways.co.uk (Gary Stainburn) Date: Fri, 7 May 2004 14:28:03 +0100 Subject: Please Use the Mirrors! In-Reply-To: <409B898F.5070907@greenhydrant.com> References: <200405031337.21863.jkeating@j2solutions.net> <200405071033.50197.gary.stainburn@ringways.co.uk> <409B898F.5070907@greenhydrant.com> Message-ID: <200405071428.03028.gary.stainburn@ringways.co.uk> On Friday 07 May 2004 2:05 pm, David Rees wrote: > Gary Stainburn wrote, On 5/7/2004 2:33 AM: [snip] > > If the goal is to save bandwidth, installing a local caching proxy like > squid is a good idea, just make sure that you set the maximum file size > to something large enough to cover the biggest RPM in the repository. > Typically machines will do a number of things in day-to-day operation, > check for the latest headers, and download updates. Both of those > operations will be cached by the local proxy. The downside of rsync is > that you need to run it periodically, and there will be quite a large > amount of storage space required as well. > > However, if you still want to rsync, this command will work: > > rsync -rpt --delete \ > --exclude="lost+found" --exclude=\*.src.rpm \ > ${SERVER}/redhat/7.3 ${LOCALREPO} > > Replace ${SERVER} with a mirror, and ${LOCALREPO} with your local > repository directory. > > Note that this command only mirrors the redhat 7.3 repository. > > -Dave Thanks for this Dave. I'll probaby look at doing something like this on a central server to create a local copy (and repeat for FC1). What I need to know now is how's the best way to make these local copies available to RH73 and FC1 boxes so that I can yum on them. What do I have to do on the server? configure apache or an ftp server? What do I have to do on the client ? add the local server to their yum.conf? -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 From SNielsen at comscore.com Fri May 7 14:19:35 2004 From: SNielsen at comscore.com (Nielsen, Steve) Date: Fri, 7 May 2004 10:19:35 -0400 Subject: yum installation management. Message-ID: <66E9FEE99E96034ABB4DE197A927DBF101CC1E7D@csiadmail01.office.comscore.com> I would be interested in the code. Can you make it available for download? Steve -----Original Message----- From: Brian Hirt [mailto:bhirt at mobygames.com] Sent: Wednesday, May 05, 2004 12:08 PM To: Discussion of the Fedora Legacy Project Cc: Brian Hirt Subject: yum installation management. Like lots of users out there, my company used to use Red Hat Network to support our boxes. One of the things i really liked about RHN was that you could remotely administer a bunch of servers fairly easily without having to log onto each machine to check for updates or to install updates. I'm aware that Yum and others packages can be run from cron to automatically install packages. However, if you want a little bit more control over what you install and when you install them, I haven't seen something out there that suits me. I spent some time whipping up a little system that is similar to RHN. The administration is from a web page where you can view which components on your servers are out of date and request that the remotely administered systems update certain packages. Each of the remotely administered systems checks in with the central database and updates packages that it's been requested to update. The administered boxes also notify the central server when if finds new packages that should be updated. The system is written entirely in perl, and has three components. There is one mod_perl program running on the webserver, and two client programs that run on each of the administered boxes. One of the clients performs the updates, and the other client checks nightly to see if there are new packages that need updating. All of the state is stored in a backend SQL database. I'm using postgresql, but as it's a fairly simple system using basic SQL, i have no doubts that mysql could easily be used too. So, before i go on and on about this slightly off topic email I wanted to find out if other people might be interested in a system like this that they could use in their own installations. I'd like to make this project open, but don't really know how many people would find such a system useful. So, the purpose of this email is to gauge if there is any interest in such a project and to let people know about it. If you have any interest is a project like this, I would love to talk to you and get your ideas. -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jjasen at realityfailure.org Fri May 7 14:41:50 2004 From: jjasen at realityfailure.org (John Jasen) Date: Fri, 7 May 2004 10:41:50 -0400 (EDT) Subject: packages needing QA and how to QA In-Reply-To: <20040505160605.53dec725.fedora@wir-sind-cool.org> References: <1083740108.30323.22.camel@binkley> <20040505135928.GL9662@hemi.math.gatech.edu> <20040505160605.53dec725.fedora@wir-sind-cool.org> Message-ID: these are all rebuilt on a 7.3 system and installed. If I missed any, let me know, and I'll give them a spin on a 7.3 box or so. Thanks! lha-1.14i-4.7.3.1.legacy.i386.rpm -- built from srpm and installed cleanly. libpng-1.0.14-0.7x.5.legacy.i386.rpm and libpng-devel-1.0.14-0.7x.5.legacy.i386.rpm -- built from srpm and installed cleanly. gdk-pixbuf-0.14.0-9.legacy.i386.rpm gdk-pixbuf-devel-0.14.0-9.legacy.i386.rpm gdk-pixbuf-gnome-0.14.0-9.legacy.i386.rpm -- built and installed cleanly. probably need a spec file change if its going to 7.x and 8.0 utempter-0.5.2-6.7.3.1.legacy.i386.rpm -- built and installed cleanly sysklogd-1.4.1-9.legacy.7x.i386.rpm -- built and installed cleanly sysstat-4.0.3-3.legacy.i386.rpm -- built and installed cleanly. Do we want OS revision in the package names for distribution? libxml2-2.4.19-5.legacy.i386.rpm (and -devel and -python) -- built and installed cleanly. Do we want OS revision in the package names for distribution? mod_python-2.7.8-1.7.3.2.legacy.i386.rpm -- built and installed cleanly rsync-2.5.7-1.legacy.7x.i386.rpm -- built and installed cleanly mozilla-1.4.2 -- still rebuilding -- -- John E. Jasen (jjasen at realityfailure.org) -- No one will sorrow for me when I die, because those who would -- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring From drees at greenhydrant.com Fri May 7 14:43:00 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 7 May 2004 07:43:00 -0700 (PDT) Subject: Please Use the Mirrors! In-Reply-To: <200405071428.03028.gary.stainburn@ringways.co.uk> References: <200405031337.21863.jkeating@j2solutions.net> <200405071033.50197.gary.stainburn@ringways.co.uk> <409B898F.5070907@greenhydrant.com> <200405071428.03028.gary.stainburn@ringways.co.uk> Message-ID: <3522.208.48.139.163.1083940980.squirrel@208.48.139.163> Gary Stainburn wrote: > On Friday 07 May 2004 2:05 pm, David Rees wrote: >> However, if you still want to rsync, this command will work: >> >> rsync -rpt --delete \ >> --exclude="lost+found" --exclude=\*.src.rpm \ >> ${SERVER}/redhat/7.3 ${LOCALREPO} >> >> Replace ${SERVER} with a mirror, and ${LOCALREPO} with your local >> repository directory. >> >> Note that this command only mirrors the redhat 7.3 repository. > > Thanks for this Dave. I'll probaby look at doing something like this on a > central server to create a local copy (and repeat for FC1). > > What I need to know now is how's the best way to make these local copies > available to RH73 and FC1 boxes so that I can yum on them. > > What do I have to do on the server? configure apache or an ftp server? > What do I have to do on the client ? add the local server to their > yum.conf? You'll need to configure Apache to serve up the ${LOCALREPO} directory along with directory indexes. On the client, adjust the yum.conf to point to your server. If you want to mirror FC1, you'll have to look up the rsync mirrors from the Fedora project, and then use a similar command. -Dave From rjohnson at medata.com Fri May 7 14:49:48 2004 From: rjohnson at medata.com (Rick Johnson) Date: Fri, 07 May 2004 07:49:48 -0700 Subject: Please Use the Mirrors! In-Reply-To: <409B898F.5070907@greenhydrant.com> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <200405071033.50197.gary.stainburn@ringways.co.uk> <409B898F.5070907@greenhydrant.com> Message-ID: <409BA20C.8040205@medata.com> David Rees wrote: > If the goal is to save bandwidth, installing a local caching proxy like > squid is a good idea, just make sure that you set the maximum file size > to something large enough to cover the biggest RPM in the repository. > Typically machines will do a number of things in day-to-day operation, > check for the latest headers, and download updates. Both of those > operations will be cached by the local proxy. The downside of rsync is > that you need to run it periodically, and there will be quite a large > amount of storage space required as well. I've done something compromising in my situation. I've created one server as a "cache" for yum. I then have my various servers' (which are local) /var/cache/yum directories nfs mounted to their version's appropriate yum cache. The first server will usually fetch most of the packages/headers/etc. and then the subsequent machines that night will pull the packages from their "local" cache vs. downloading them again. For machines local to this NFS server, this works quite well. Performance is a bit slower than it would be if they were local, and doing this over our wide-area network is prohibitively slow. It also cannot be done easily for machines on the "wrong" side of the firewall. In some ways this is more efficent than rsyncing the entire tree since most of my "servers" don't have "all" packages installed. The downside is that the header.info files are retrieved each time, so it may or may not balance out in the end. -Rick -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. (from home) PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From rostetter at mail.utexas.edu Fri May 7 15:49:26 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 7 May 2004 10:49:26 -0500 Subject: Please Use the Mirrors! In-Reply-To: <1083872037.24024.62.camel@bretsony> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> Message-ID: <20040507104926.1fyo8cw888kwo88w@mail.ph.utexas.edu> Quoting Bret Hughes : > Perhaps something on the index page of download.fedoralegacy.org that > says "Please use the mirrors" and give some links to them. Right now > there is no indication that you do not want folks to use the site. I've never added anything to the download page for two reasons: 1) I never thought of it. 2) Everytime the bandwidth issue comes up I'm told the new site will be up "in a matter of days" so there seems no point. Since the "matter of days" has been more like months, in retrospect it would have been a good idea. So, is the new server (I know it is in testing now) really going to be up in a matter of days? Or is it going to be longer so we really need to change the download pages to show the mirrors instead? Or will the new machine not really solve the problem, and we need to push the mirrors harder anyway? > Also on fedoralegacy.org/download/ change the link under "Manually > downloading specific packages" to point to the mirrors page rather than > download.fedoralegacy.org. I think the bigger problem is the apt/yum users. In particular because many of them run daily automatic updates, etc. I doubt the people downloading individual packages are the problem. (Though maybe web robots are following the links, and could be a source of the problem). > Seems to me that rsync would help people create local repositories for > their company's use. Even if they have only 3 or four machines, it has > to be made easy for them to create the repo. Yes, I agree. I currently mirror update sites to my local machine, and all my other local machines update from there. So allowing me to rsync once a day will save you having to provide yum/apt access to about 100 machines all at once (when I do my mass updates of about 100 machines at a time). Would seem to be a good tradeoff. But I also can't open this to everyone. It is open to my 1200 users here, and that's all I can support. > I don't have the bandwidth to be a true mirror site but I could save > some band width for you with local mirrored trees. This is going to be > much more of an issue now that RHL 9 is there too. I agree 100%. Not that I have a solution, but I agree. It is not just a bandwidth saving for me either. When a machine here gets hacked, infected by a virus, trojaned, etc. we cut off their access at the border until they are cleaned and patched. Since their access to the internet is cut, they can't get updates from outside. So I need that local mirror (for the various OS versions) to provide updates to them. I'd love to see a way for site-specific mirrors to be allowed. Though perhaps we can just mirror from a mirror rather than the main server. > Bret -- Eric Rostetter From jkeating at j2solutions.net Fri May 7 15:52:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 May 2004 08:52:44 -0700 Subject: Please Use the Mirrors! In-Reply-To: <20040507104926.1fyo8cw888kwo88w@mail.ph.utexas.edu> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040507104926.1fyo8cw888kwo88w@mail.ph.utexas.edu> Message-ID: <200405070852.44363.jkeating@j2solutions.net> On Friday 07 May 2004 08:49, Eric Rostetter wrote: > So, is the new server (I know it is in testing now) really going to > be up in a matter of days? Or is it going to be longer so we really > need to change the download pages to show the mirrors instead? Or > will the new machine not really solve the problem, and we need to > push the mirrors harder anyway? New server is already up. Issues should be resolved. Official mirrors have priority access to rsync, public rsync is slightly limited. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jjasen at realityfailure.org Fri May 7 16:32:38 2004 From: jjasen at realityfailure.org (John Jasen) Date: Fri, 7 May 2004 12:32:38 -0400 (EDT) Subject: packages needing QA and how to QA In-Reply-To: References: <1083740108.30323.22.camel@binkley> <20040505135928.GL9662@hemi.math.gatech.edu> <20040505160605.53dec725.fedora@wir-sind-cool.org> Message-ID: On Fri, 7 May 2004, John Jasen wrote: > mozilla-1.4.2 -- still rebuilding mozilla-1.4.2-2.1.0.legacy.i386.rpm: builds and installs cleanly. -- -- John E. Jasen (jjasen at realityfailure.org) -- No one will sorrow for me when I die, because those who would -- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring From dkoobs at fcsservices.com Fri May 7 17:06:22 2004 From: dkoobs at fcsservices.com (Doug Koobs) Date: Fri, 7 May 2004 13:06:22 -0400 Subject: RH9 Updates Available? In-Reply-To: <200405070852.44363.jkeating@j2solutions.net> Message-ID: <001c01c43455$9f6aaf10$a07ac80a@fcsservices.com> Jesse Keating wrote: > New server is already up. Issues should be resolved. > Official mirrors > have priority access to rsync, public rsync is slightly limited. Does this mean that RH9 is now supported? Doug Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. From drees at greenhydrant.com Fri May 7 17:11:20 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 7 May 2004 10:11:20 -0700 (PDT) Subject: Please Use the Mirrors! In-Reply-To: <1083878596.27730.86.camel@opus> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> <20040506221858.B19354@nsk.no-ip.org> <1083878596.27730.86.camel@opus> Message-ID: <4563.208.48.139.163.1083949880.squirrel@208.48.139.163> seth vidal wrote: >> Better yet, have yum support redirects (I don't know if it doesn't >> already) and have the yum.conf point to a dynamic webpage that >> redirects to a local mirror for the client (using the cpan module for >> country location, or something of the like). > > yum supports http redirects but it doesn't support javascript redirects > or META refresh redirects (nor will it, so don't ask! :) Here's a PHP script that will do it pretty easily with a bit of tweaking for your use: /$releasever/$basearch/os", "/$releasever/$basearch/os", ); } else if ($repo == "updates") { $mirrors = array( "/$releasever/$basearch/updates", "/$releasever/$basearch/updates", ); // Add more repos here if you need them $mirror = $mirrors[rand(0,sizeof($mirrors)-1)]; $path = $_SERVER['PATH_INFO']; header("Location: $mirror$path"); ?> Put the script on your webserver, then point your yum.conf like this to your server: [os] name=Repo Name $releasever - $basearch - Base baseurl=?releasever=$releasever&basearch=$basearch&repo=os [updates] name=Repo Name $releasever - $basearch - Released Updates baseurl=?releasever=$releasever&basearch=$basearch&repo=updates Tweak as necessary to handle legacy as well as any other updates. One php script can be configured to handle, just make up an appropriate repo name. Have retries set to 20 in [main] of yum.conf and away you go! -Dave From kelson at speed.net Fri May 7 17:17:24 2004 From: kelson at speed.net (Kelson Vibber) Date: Fri, 7 May 2004 10:17:24 -0700 Subject: RH9 Updates Available? In-Reply-To: <001c01c43455$9f6aaf10$a07ac80a@fcsservices.com> References: <001c01c43455$9f6aaf10$a07ac80a@fcsservices.com> Message-ID: <200405071017.25003.kelson@speed.net> On Friday 07 May 2004 10:06 am, Doug Koobs wrote: > Jesse Keating wrote: > > New server is already up. Issues should be resolved. > > Official mirrors > > have priority access to rsync, public rsync is slightly limited. > > Does this mean that RH9 is now supported? It looks like it. I just started yum update and it's downloading headers ftom the gatech.edu mirror. Of course, I have no idea whether there's anything *new* there yet... -- Kelson Vibber SpeedGate Communications, From dkoobs at fcsservices.com Fri May 7 17:24:52 2004 From: dkoobs at fcsservices.com (Doug Koobs) Date: Fri, 7 May 2004 13:24:52 -0400 Subject: RH9 Updates Available? In-Reply-To: <200405071017.25003.kelson@speed.net> Message-ID: <001f01c43458$34d49550$a07ac80a@fcsservices.com> > > Does this mean that RH9 is now supported? > > It looks like it. I just started yum update and it's > downloading headers ftom > the gatech.edu mirror. Cool! I can't seem to find any documentation for yum or apt for RH9 at www.fedoralegacy.org. Is it just not up yet? Doug Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. From villegas at math.gatech.edu Fri May 7 17:30:17 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 7 May 2004 13:30:17 -0400 Subject: Please Use the Mirrors! In-Reply-To: <4563.208.48.139.163.1083949880.squirrel@208.48.139.163> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> <20040506221858.B19354@nsk.no-ip.org> <1083878596.27730.86.camel@opus> <4563.208.48.139.163.1083949880.squirrel@208.48.139.163> Message-ID: <20040507173017.GE4976@hemi.math.gatech.edu> On Fri, May 07, 2004 at 10:11:20AM -0700, David Rees wrote: > Here's a PHP script that will do it pretty easily with a bit of tweaking > for your use: Thank you for doing that. However I'm not sure that should be the default yum.conf config, as it forces a single point of failure, while listing all the mirrors gives high availability of updates. So mix them toghether, and make that entry the first one on a failover=priority configuration, followed by a list of the "fat pipe" mirrors. Just my two cents. Carlos From jkeating at j2solutions.net Fri May 7 17:32:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 May 2004 10:32:48 -0700 Subject: RH9 Updates Available? In-Reply-To: <001f01c43458$34d49550$a07ac80a@fcsservices.com> References: <001f01c43458$34d49550$a07ac80a@fcsservices.com> Message-ID: <200405071032.51231.jkeating@j2solutions.net> On Friday 07 May 2004 10:24, Doug Koobs wrote: > Cool! I can't seem to find any documentation for yum or apt for RH9 > at www.fedoralegacy.org. Is it just not up yet? Not up yet. I hope to have yum/apt packages up for updates-testing this weekend. All RH provided updates are currently online though, with full yum/apt headers. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Fri May 7 19:00:58 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 7 May 2004 13:00:58 -0600 Subject: Kernel updates for QA In-Reply-To: <20040507002636.GS960@tirian.magd.ox.ac.uk>; from dom@earth.li on Fri, May 07, 2004 at 01:26:37AM +0100 References: <20040507002636.GS960@tirian.magd.ox.ac.uk> Message-ID: <20040507130058.A16913@mail.harddata.com> On Fri, May 07, 2004 at 01:26:37AM +0100, Dominic Hargreaves wrote: > Hi, > > I've put up some packages for QA at This reminds me. If there is a new kernel "in works" then maybe it should also include a fix for nforce2 boards based on an information recently provided, at last, by Nvidia? See: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=1RUTd-1Ji-5%40gated-at.bofh.it&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dfixup%2Bfor%2BC1%2BHalt%2BDisconnect%2Bproblem%2Bon%2BnForce2%2Bchipsets%26btnG%3DSearch%26meta%3D and the related thread. The patch there is 2.6 but it should be adaptable to 2.4 as well. Actually looking closer Ross Dickson posted that patch rediffed for 2.4.26, and this should fit into other 2.4 kernels as well, but I do not see this on Google yet. Opinions? Michal From fedora at wir-sind-cool.org Fri May 7 19:15:28 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 7 May 2004 21:15:28 +0200 Subject: RH9 Updates Available? In-Reply-To: <001f01c43458$34d49550$a07ac80a@fcsservices.com> References: <200405071017.25003.kelson@speed.net> <001f01c43458$34d49550$a07ac80a@fcsservices.com> Message-ID: <20040507211528.67340a8e.fedora@wir-sind-cool.org> On Fri, 7 May 2004 13:24:52 -0400, Doug Koobs wrote: > > > Does this mean that RH9 is now supported? > > > > It looks like it. I just started yum update and it's > > downloading headers ftom > > the gatech.edu mirror. > > Cool! I can't seem to find any documentation for yum or apt for RH9 at > www.fedoralegacy.org. Is it just not up yet? yum/apt from fedora.us for RHL9 will work fine until something official from Fedora Legacy will be available From rostetter at mail.utexas.edu Fri May 7 19:16:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 7 May 2004 14:16:40 -0500 Subject: Please Use the Mirrors! In-Reply-To: <20040506195527.GD4976@hemi.math.gatech.edu> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> Message-ID: <20040507141640.g6rwowco8gk0ogk4@mail.ph.utexas.edu> Quoting Carlos Villegas : > Along the same lines, there is a "default yum.conf" file in the It isn't a "default" so much as reference for those who use a non-FL version of yum. > download section, which has no mirrors in it, it should probably > have all the mirrors, also I think that file should be automatically > generated with php to contain all the mirrors, in some random > order, and a comment both in the config file and in the web page > asking people to organize the mirrors as appropiate, I'd also At first this sounded like a great idea. But after I think about this a minute, I come up with two problems. 1) This will take up a lot of real estate on the web page as the list of mirrors is not small. This increased size will not only stop people from want to read the page, but potentially cause more confusion, cut/paste errors, etc. 2) It makes it more complex, and if they have to depend on that page for help they are not likely to really know enough to handle editing the file, etc. > force gpg checks in the default config file. Let me know (off > list) if you need help writting that php. I thought this was on in the FL config by default, no? If they use another version of yum or apt, that is their problem to figure out. > Carlos -- Eric Rostetter From dom at earth.li Sat May 8 00:53:56 2004 From: dom at earth.li (Dominic Hargreaves) Date: Sat, 8 May 2004 01:53:56 +0100 Subject: Kernel updates for QA In-Reply-To: <20040507130058.A16913@mail.harddata.com> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507130058.A16913@mail.harddata.com> Message-ID: <20040508005356.GA960@tirian.magd.ox.ac.uk> On Fri, May 07, 2004 at 01:00:58PM -0600, Michal Jaegermann wrote: > This reminds me. If there is a new kernel "in works" then maybe > it should also include a fix for nforce2 boards based on an > information recently provided, at last, by Nvidia? I'm not sure if this qualifies as suffiently mainstream, especially for legacy users. Should we be attempting this sort of bugfix in FL updates? Then again it doesn't look like an especially invasive patch. Thoughts? I'll try and get some updated kernel RPMS to address this (if thought appropriate) plus cpufreq, which I missed, this weekend or early next week. Intial QAing before then still useful to catch any other problems to fix :) Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From michal at harddata.com Sat May 8 04:25:50 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 7 May 2004 22:25:50 -0600 Subject: Kernel updates for QA In-Reply-To: <20040508005356.GA960@tirian.magd.ox.ac.uk>; from dom@earth.li on Sat, May 08, 2004 at 01:53:56AM +0100 References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507130058.A16913@mail.harddata.com> <20040508005356.GA960@tirian.magd.ox.ac.uk> Message-ID: <20040507222550.A31352@mail.harddata.com> On Sat, May 08, 2004 at 01:53:56AM +0100, Dominic Hargreaves wrote: > On Fri, May 07, 2004 at 01:00:58PM -0600, Michal Jaegermann wrote: > > > This reminds me. If there is a new kernel "in works" then maybe > > it should also include a fix for nforce2 boards based on an > > information recently provided, at last, by Nvidia? > > I'm not sure if this qualifies as suffiently mainstream, especially for > legacy users. Should we be attempting this sort of bugfix in FL updates? The thing is that if you have an nforce2 mobo then depending on your BIOS you may not notice anything amiss or you may get assorted crashes, data corruption, etc. If you do not have such board then you are not affected at all - patched or not patched. Personally I am falling in the later category. This fix is indeed a few days old but only now the information on which it is based become available. Michal From raphael at clifford.net Sat May 8 10:59:50 2004 From: raphael at clifford.net (Raphael Clifford) Date: Sat, 08 May 2004 11:59:50 +0100 Subject: yum and redhat 8.0 Message-ID: <409CBDA6.6020804@clifford.net> Hi, I notice that there are no docs for yum and redhat 8.0. It is possible I may have missed them but I am looking at http://www.fedoralegacy.org/docs/ in particular. I have copied and pasted from the redhat 7.x instructions and changed things where necessary. Please take a look and see what needs to be fixed before it can be put up. I have omitted documention on how to use yum 1.x with redhat 8.0 as I don't recommend it. Please add it if you think it is important. Kind regards, Raphael ------------------------------------------------------------------------------------------------------------------------------- Using yum to keep Red Hat Linux 8.0 up to date /yum/ (*Y*ell dog *U*pdater, *M*odified) is an automated package management program which may be used to install, remove, and update packages on an RPM based system. It will help you to keep your system up to date and is used by Fedora Core, the successor to Red Hat Linux. Step 1: Preliminaries Linux prevents ordinary users from installing, removing, or modifying system software, libraries, and important configuration information. So you must have root access to proceed. You may either login as the root user, or use the /su/ (or /sudo/) commands to become the root user on the machine. *Note:* Be careful when running as root! Be sure to logout of the root account as soon as you are done. Running as root is dangerous, and should only be used when needed. Typos or mistakes can destroy your system or your data, so it is important that you be careful when running as root. When you are running as root, your prompt will be changed to the *#* character. In the command examples below, we include this prompt, however you should not type the *#* character when entering a command Step 1: Updating yum and rpm The one complication with configuring yum to work with red hat 8.0 is that you have to have the correct yum version to go with your rpm version. The official chart can be found at http://linux.duke.edu/projects/yum/download.ptml. However, for our purposes we simply recommend updating both to the latest reasonably bug free versions. rpm -Uvh http://ftp.freshrpms.net/pub/freshrpms/redhat/8.0/yum/yum-2.0.3-5.rh.fr.i386.rpm rpm -Uvh http://download.fedora.us/patches/redhat/8.0/i386/RPMS.stable/rpm-4.1.1-1.8x.i386.rpm Step 2: Configuring yum.conf Yum uses a file called yum.conf that can be found in the /etc/ directory to decide where to download updates from. This file needs to be configured to work with fedora legacy. The simplest method is to create such a file containing the following: # See the yum.conf(5) man page for information the syntax of this file, # including failover setup. [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest # Please use nearby mirrors! For a an up to date list of Fedora Legacy mirrors, see # http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php [redhat-os] name=Red Hat Linux $releasever ($basearch) baseurl= http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ gpgcheck=1 failovermethod=priority [redhat-updates] name=Red Hat Linux $releasever ($basearch) updates baseurl= http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ gpgcheck=1 failovermethod=priority [fedora-stable] name=Fedora Linux / stable for Red Hat Linux $releasever ($basearch) baseurl= http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/stable/ gpgcheck=1 failovermethod=priority Step 2.1: Optionally add mirror sites yum will be installed so as to use download.fedora.us as the source of updates. You may want to configure it to use additional mirror sites which are closer to you, faster, or meet your security policy. yum supports automatic fail-over when one or more servers are unavailable, so it is advantageous to use multiple mirror sites to take advantage of this fail-over support. yum will use the sites in the order presented in the /baseurl/ parameters of your configuration file, so you should order them so that the most desirable sites will be tried first before your fail-over mirrors. Again, please note that this step is optional, and it is up to you to decide if you wish to implement it. You can find a list of current Fedora Legacy mirrors at http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php You will need to manually edit the file /etc/yum.conf to set the mirror site(s) should you chose to do so. Step 2.2: Add the GPG (security) keys All Fedora Legacy packages are signed with GPG keys. All packages should be verified using these keys. See http://www.fedoralegacy.org/about/security.php for more information. In order properly to verify the packages, you need to add the appropriate GPG keys to your root user's keyring. To import the keys, use the following command as the root user: rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY Step 3: Update your system Once you have installed the yum package, you should run the following command as the root user on your system to update your system: # yum update This will create a current package list for your system, download the updates for all packages which require updating (and any dependencies for those packages), and install them on your system. Before you do that you may wish to run # yum check-update which will show you all the packages yum thinks need to be updated *Warning:* This may take some time on your first use of yum, depending on how up to date your system is and the speed of your internet connection! Yum is not known for its speed but once you have completed the first update the subsequent ones will be much faster. Step 4: Decide if you want automatic updates yum has the ability to automatically apply (download/verify/install) all updates to your system, but this feature is disabled by default. If you want to enable that functionality, please enter the following command as the root user on your system: # chkconfig yum on # service yum start After that, yum will update your system through the cron job /etc/cron.daily/yum.cron, which will run every night (or later through anacron, if your system isn't running all the time). Step 5: Subscribe to fedora-legacy-announce You may subscribe to the fedora-legacy-announce mailing list to be informed by e-mail when new updates become available. This step is optional, but highly recommended. Step 6: Please help us with our service! The Fedora Legacy project is always in the need of helping hands. Please check the Participate section of our website to see what you can do to help us. As we're a community project, our success will heavily depend on helping hands ? possibly you! If you find a problem with an update published by The Fedora Legacy Project, or in The Fedora Legacy Project documentation, please let us know! Step 7: Optionally learn additional features of yum Below is a summary of some of the more advanced features of yum for those who wish to know more. You do not need to know these commands to keep your system updated; they are simply provided for those who want to learn more about using yum to its fullest. yum list List all available software. yum check-update See if there are updated packages available. yum update Update all installed packages that have a newer version available. yum install // Install specific package(s) (and its dependencies, if missing any). yum search // Search all known packages entries (descriptions etc) for //. yum info // Show basic information about a package. From rok.papez at lugos.si Sun May 2 10:23:47 2004 From: rok.papez at lugos.si (Rok =?utf-8?q?Pape=C5=BE?=) Date: Sun, 2 May 2004 12:23:47 +0200 Subject: sysklogd packages for rhl7.3(7.x?) and rhl9 for memory overrun up for QA In-Reply-To: <1083401013.30914.58.camel@binkley> References: <1083401013.30914.58.camel@binkley> Message-ID: <200405021223.47249.rok.papez@lugos.si> Hello Legacy! Dne sobota 01 maj 2004 10:43 je seth vidal napisal(a): > Sysklogd ackages for rhl7.3(7.x possibly) and rhl9 that correct a memory > overrun in syslogd's crunchlist are up for QA. > > please check them and test them (and of course comment) > > https://bugzilla.fedora.us/show_bug.cgi?id=1553 Bill Notingham provided OWL patches. New RPM packages are available for RH9, others are invited to port to 7.x and 8. -- best regards, Rok Pape? From cz at hykw.tv Tue May 4 05:43:14 2004 From: cz at hykw.tv (HAYAKAWA Hitoshi) Date: Tue, 04 May 2004 14:43:14 +0900 Subject: When Openssl for RHL7.3 will be moved to updates directory? Message-ID: <878yg8wxvx.wl%cz@hykw.tv> Hello, OpenSSL package for RHL7.3 have been in updates-testing directory in a month. Although I don't know the fedora legacy's police around updates-testing and updates, when the packages will be moved to updates? It means the packages aren't be tested or doesn't satisfy QA? Thanks in advance, -- HAYAKAWA, Hitoshi E-mail: cz at hykw.jp From inc at fastmedia.net Fri May 7 01:14:17 2004 From: inc at fastmedia.net (cpaul) Date: Fri, 7 May 2004 11:14:17 +1000 Subject: Please Use the Mirrors! In-Reply-To: <1083878596.27730.86.camel@opus> References: <200405031337.21863.jkeating@j2solutions.net> <1083872037.24024.62.camel@bretsony> <20040506195527.GD4976@hemi.math.gatech.edu> <20040506221858.B19354@nsk.no-ip.org> <1083878596.27730.86.camel@opus> Message-ID: <20040507111417.500cf092.inc@fastmedia.net> On Thu, 06 May 2004 17:23:16 -0400 seth vidal wrote: > > Better yet, have yum support redirects (I don't know if it doesn't > > already) and have the yum.conf point to a dynamic webpage that redirects > > to a local mirror for the client (using the cpan module for country > > location, or something of the like). > > yum supports http redirects but it doesn't support javascript redirects > or META refresh redirects (nor will it, so don't ask! :) > could do something with Geo::IP - which is what php.net and others appear to do with mirrors and downloads. http://search.cpan.org/~tjmather/Geo-IP-1.21/lib/Geo/IP.pm regards -- chris paul From troed at sangberg.se Sat May 8 11:12:55 2004 From: troed at sangberg.se (=?iso-8859-15?Q?Troed_S=E5ngberg?=) Date: Sat, 08 May 2004 13:12:55 +0200 Subject: RH9 user - what should I do? Message-ID: Hi all, I must be blind. I've looked all over the Fedora Legacy project page, read (I think, at least) the available documentation on the web, but I have _no idea_ what to do to get my RH9-machine that previously used up2date for security updates, to start using the packages from the Legacy project. Please - a step-by-step guide that doesn't ask me to choose between yum/apt-whatever since I, as a stupid RH9 user, have only got a very vague idea on the difference and significance of that choice? Thanks in advance for any help, Troed From jkeating at j2solutions.net Sat May 8 16:39:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 May 2004 09:39:40 -0700 Subject: [FLSA-2004:1395] Updated OpenSSL resolves security vulnerability Message-ID: <200405080939.40888.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated OpenSSL resolves security vulnerability Advisory ID: FLSA:1395 Issue date: 2004-05-08 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1395 CVE Names: CAN-2003-0851 CAN-2004-0081 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated OpenSSL packages that fix remote denial of service vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 i686 Red Hat Linux 7.3 - i386 i686 Red Hat Linux 8.0 - i386 i686 3. Problem description: OpenSSL is a toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. Testing performed by the OpenSSL group using the Codenomicon TLS Test Tool uncovered a bug in older versions of OpenSSL 0.9.6 prior to 0.9.6d that can lead to a denial of service attack (infinite loop). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0081 to this issue. Testing performed by Novell using a test suite provided by NISCC uncovered an issue in the ASN.1 parser in versions of OpenSSL 0.9.6 prior to 0.9.6l which could cause large recursion and possibly lead to a denial of service attack if used where stack space is limited. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0851 to this issue. These updated packages contain patches provided by the OpenSSL group that protect against these issues. NOTE: Because server applications are affected by this issue, users are advised to either restart all services using OpenSSL functionality or restart their system after installing these updated packages. Fedora Legacy would like to thank Michal Jaegermann for bringing this issue to our attention. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1395 - openssl vulnerabilties to remote DoS attack 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl-devel-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl-perl-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl096-0.9.6-25.7.legacy.i386.rpm i686: http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssl-0.9.6b-36.7.legacy.i686.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-devel-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-perl-0.9.6b-36.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl096-0.9.6-25.7.legacy.i386.rpm i686: http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-0.9.6b-36.7.legacy.i686.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/openssl095a-0.9.5a-24.8.legacy.src.rpm http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/openssl-0.9.6b-36.8.legacy.src.rpm http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/openssl096-0.9.6-24.8.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl-devel-0.9.6b-36.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl-0.9.6b-36.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl-perl-0.9.6b-36.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl095a-0.9.5a-24.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl096-0.9.6-24.8.legacy.i386.rpm i686: http://download.fedoralegacy.org/redhat/8.0/updates/i386/openssl-0.9.6b-36.8.legacy.i686.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 6125c0171b9bd2c49e2f206fa616c70310262085 7.2/updates/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm 296a86b860209645a73cdd081b03f3fb1d6e437d 7.2/updates/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm 2647596bc3e8d0090af0ea0e9841ba665872a729 7.2/updates/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm fff610245bcd73fce6b78c0e7f4155cf0c627762 7.2/updates/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm f678d1b885a8236301afb4f92da2d451599643ce 7.2/updates/i386/openssl096-0.9.6-25.7.legacy.i386.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.2/updates/i386/openssl-0.9.6b-36.7.legacy.i386.rpm c4403aff66cc3891418f2f4a5fc9632ed87c6f79 7.2/updates/i386/openssl-0.9.6b-36.7.legacy.i686.rpm 8b3fca54a08ae67a3ee5c5b6dfc0a166a31d9a1c 7.2/updates/i386/openssl-devel-0.9.6b-36.7.legacy.i386.rpm bfb7a080b0afe36bba4de6431d68110cd30636aa 7.2/updates/i386/openssl-perl-0.9.6b-36.7.legacy.i386.rpm 6125c0171b9bd2c49e2f206fa616c70310262085 7.3/updates/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm 296a86b860209645a73cdd081b03f3fb1d6e437d 7.3/updates/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm 2647596bc3e8d0090af0ea0e9841ba665872a729 7.3/updates/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm fff610245bcd73fce6b78c0e7f4155cf0c627762 7.3/updates/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm f678d1b885a8236301afb4f92da2d451599643ce 7.3/updates/i386/openssl096-0.9.6-25.7.legacy.i386.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.3/updates/i386/openssl-0.9.6b-36.7.legacy.i386.rpm c4403aff66cc3891418f2f4a5fc9632ed87c6f79 7.3/updates/i386/openssl-0.9.6b-36.7.legacy.i686.rpm 8b3fca54a08ae67a3ee5c5b6dfc0a166a31d9a1c 7.3/updates/i386/openssl-devel-0.9.6b-36.7.legacy.i386.rpm bfb7a080b0afe36bba4de6431d68110cd30636aa 7.3/updates/i386/openssl-perl-0.9.6b-36.7.legacy.i386.rpm 6b789ea67363c4a7f23cc1e1363c32509605d5b4 8.0/updates/SRPMS/openssl095a-0.9.5a-24.8.legacy.src.rpm a13a09ee098c126ab7b452f13ae49cc870e0d5d2 8.0/updates/SRPMS/openssl096-0.9.6-24.8.legacy.src.rpm 95ab8bd7b6e649f3e7995830e8f15c3fd55e83bd 8.0/updates/SRPMS/openssl-0.9.6b-36.8.legacy.src.rpm f15faf931188fcc4991cd692eba88ef4dd3e670e 8.0/updates/i386/openssl095a-0.9.5a-24.8.legacy.i386.rpm 5fad5ab9fdbbf48cd725cb9d7edb853f651b0893 8.0/updates/i386/openssl096-0.9.6-24.8.legacy.i386.rpm bb6c9804df5d4214ca80474f2f3e87ddfe298908 8.0/updates/i386/openssl-0.9.6b-36.8.legacy.i386.rpm d49da33be792303a8ea3295076b3a7e5c7a29ea1 8.0/updates/i386/openssl-0.9.6b-36.8.legacy.i686.rpm 7a2494d638beb99b939480fac7d27885b68137e8 8.0/updates/i386/openssl-devel-0.9.6b-36.8.legacy.i386.rpm 7a01c363409dae773a9b7b678abd5c511a580a62 8.0/updates/i386/openssl-perl-0.9.6b-36.8.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0851 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0081 https://rhn.redhat.com/errata/RHSA-2004-119.html https://bugzilla.fedora.us/show_bug.cgi?id=1395 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAnQ1M4v2HLvE71NURAn5/AJ0VIZVW0sE5bgCtYGuUgQfx1RrcNQCguLPc Ykda1gyXWPnCmEcqzx1IPRw= =4X2Q -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat May 8 16:45:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 May 2004 09:45:33 -0700 Subject: When Openssl for RHL7.3 will be moved to updates directory? In-Reply-To: <878yg8wxvx.wl%cz@hykw.tv> References: <878yg8wxvx.wl%cz@hykw.tv> Message-ID: <200405080945.33633.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 03 May 2004 22:43, HAYAKAWA Hitoshi wrote: > OpenSSL package for RHL7.3 have been in updates-testing directory in a > month. Although I don't know the fedora legacy's police around > updates-testing and updates, when the packages will be moved to updates? > > It means the packages aren't be tested or doesn't satisfy QA? More of a bandwidth issue. I didn't want to move them to testing w/out the ability to have the mirrors get the sync, and for users to download it. They have been moved and released. - -- 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.3 (GNU/Linux) iD8DBQFAnQ6t4v2HLvE71NURAj0hAJ0YfyC2UGrFooWHyZO59xQ///6X1QCgmv4L bmkK9qoRJtxLTsUZTQvPtA8= =o19u -----END PGP SIGNATURE----- From fedora at wir-sind-cool.org Sat May 8 18:02:08 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 8 May 2004 20:02:08 +0200 Subject: sysklogd packages for rhl7.3(7.x?) and rhl9 for memory overrun up for QA In-Reply-To: <200405021223.47249.rok.papez@lugos.si> References: <1083401013.30914.58.camel@binkley> <200405021223.47249.rok.papez@lugos.si> Message-ID: <20040508200208.6ad382e2.fedora@wir-sind-cool.org> On Sun, 2 May 2004 12:23:47 +0200, Rok Pape__ wrote: > > Sysklogd ackages for rhl7.3(7.x possibly) and rhl9 that correct a memory > > overrun in syslogd's crunchlist are up for QA. > > > > please check them and test them (and of course comment) > > > > https://bugzilla.fedora.us/show_bug.cgi?id=1553 > > Bill Notingham provided OWL patches. New RPM packages are available for RH9, > others are invited to port to 7.x and 8. No backporting necessary. The same patch applies to 7.x and 8.0. The rh9 legacy update, which has two signed approvals already and is pushed into updates-testing soon (very soon hopefully!), can be rebuilt for 7.x and 8.0 without modification. 7.2 is the only platform which includes an older sysklogd (which uses a different console log level, for instance), so it is preferred if people with interest in 7.2 decide on how to proceed with the 7.2 legacy update, see: https://bugzilla.fedora.us/show_bug.cgi?id=1553#c16 Btw, it would be much appreciated if people with interest in Red Hat Linux 8.0 post some pre-release reviews and approvals for updates for 8.0. Else something must be done to avoid that one platform delays the release of legacy updates for other platforms. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at wir-sind-cool.org Sat May 8 18:16:09 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 8 May 2004 20:16:09 +0200 Subject: RH9 user - what should I do? In-Reply-To: References: Message-ID: <20040508201609.6e90e433.fedora@wir-sind-cool.org> On Sat, 08 May 2004 13:12:55 +0200, Troed S?ngberg wrote: > I must be blind. I've looked all over the Fedora Legacy project page, read > (I think, at least) the available documentation on the web, but I have _no > idea_ what to do to get my RH9-machine that previously used up2date for > security updates, to start using the packages from the Legacy project. Not enough people preparing the documentation in time. > Please - a step-by-step guide that doesn't ask me to choose between > yum/apt-whatever since I, as a stupid RH9 user, have only got a very vague > idea on the difference and significance of that choice? Let me see. My suggestion: * Run: rpm --import http://www.fedora.us/FEDORA-GPG-KEY * Get http://download.fedora.us/fedora/redhat/9/i386/RPMS.stable/yum-2.0.3-0.fdr.1.rh90.noarch.rpm Install it with "rpm -Uvh yum-2.0.3-0.fdr.1.rh90.noarch.rpm" Or install it directly with "rpm -ivh http://...." of the network. RPM can do that. * Install the Fedora Legacy public key for verifying package signatures. rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY * Choose a mirror of Fedora Legacy for Red Hat Linux 9 from the website, e.g. modify /etc/yum.conf in the section that reads [redhat-updates] name=Red Hat Linux $releasever ($basearch) updates baseurl= http://download.fedora.us/... to use a different baseurl= such as: baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ * If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, disable the [fedora-stable] entry in the lower half of /etc/yum.conf. * Then run "yum update" for the first time to fetch package headers. Note there is a "yum" service which can download updates at night. From rostetter at mail.utexas.edu Sat May 8 21:58:28 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 8 May 2004 16:58:28 -0500 Subject: RH9 user - what should I do? In-Reply-To: References: Message-ID: <20040508165828.ttioscw04ww4oc04@mail.ph.utexas.edu> Quoting Troed S?ngberg : > Hi all, > > I must be blind. No. > I've looked all over the Fedora Legacy project page, read > (I think, at least) the available documentation on the web, but I have _no > idea_ what to do to get my RH9-machine that previously used up2date for > security updates, to start using the packages from the Legacy project. Due to a major infrastructure change with Fedora Legacy, which happended about the same time as the EOL of Red Hat 9, we're a bit behind on the RH 9 docs and support. So, be patient, and it will show up. > Please - a step-by-step guide that doesn't ask me to choose between > yum/apt-whatever since I, as a stupid RH9 user, have only got a very vague > idea on the difference and significance of that choice? If you don't know which to use, use yum. > Thanks in advance for any help, > Troed -- Eric Rostetter From rostetter at mail.utexas.edu Sun May 9 17:31:24 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 9 May 2004 12:31:24 -0500 Subject: yum and redhat 8.0 In-Reply-To: <409CBDA6.6020804@clifford.net> References: <409CBDA6.6020804@clifford.net> Message-ID: <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> Quoting Raphael Clifford : > Hi, > > I notice that there are no docs for yum and redhat 8.0. I'd been putting off docs for apt/yum packages that don't exist yet in Fedora Legacy, but since there has been so little progress getting apt/yum out for these platforms, I'll go ahead and put up some docs using alternative versions. When FL comes out with a version, I'll update the docs to use the FL version. Comments, fixes, etc. appreciated. -- Eric Rostetter From euckew at sierraelectronics.com Sun May 9 18:27:40 2004 From: euckew at sierraelectronics.com (Eucke) Date: Sun, 9 May 2004 11:27:40 -0700 Subject: yum and redhat 8.0 References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> Message-ID: <000a01c435f3$5419f990$0201a8c0@EuckeLap> ----- Original Message ----- From: "Eric Rostetter" To: Sent: Sunday, May 09, 2004 10:31 AM Subject: Re: yum and redhat 8.0 > Quoting Raphael Clifford : > > > Hi, > > > > I notice that there are no docs for yum and redhat 8.0. > > I'd been putting off docs for apt/yum packages that don't exist yet in > Fedora Legacy, but since there has been so little progress getting apt/yum > out for these platforms, I'll go ahead and put up some docs using alternative > versions. When FL comes out with a version, I'll update the docs to use > the FL version. > > Comments, fixes, etc. appreciated. > > -- > Eric Rostetter Hi Eric and Everyone, Ok, I may be a little slow here....perhaps you could save me a great deal of grief. I finally was able to get YUM 1.x installed on my RH8 clean installed server and have been working on getting 2.x installed (latest current off freshrpms.net) but keep failing a dependency check for rpm 4.1.1 and rpm-python 4.1.1. Searching for these keeps me looping in circles. Should I assume that RH8 and YUM 2.x are not ready for prime time? Should I perhaps consider moving to RH9 and doing my build there? Your advice will be taken to heart! Thanks all! Eucke From cra at WPI.EDU Sun May 9 18:30:33 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 9 May 2004 14:30:33 -0400 Subject: yum and redhat 8.0 In-Reply-To: <000a01c435f3$5419f990$0201a8c0@EuckeLap> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> Message-ID: <20040509183033.GB12303@angus.ind.WPI.EDU> On Sun, May 09, 2004 at 11:27:40AM -0700, Eucke wrote: > Ok, I may be a little slow here....perhaps you could save me a great deal of > grief. I finally was able to get YUM 1.x installed on my RH8 clean > installed server and have been working on getting 2.x installed (latest > current off freshrpms.net) but keep failing a dependency check for rpm 4.1.1 > and rpm-python 4.1.1. Searching for these keeps me looping in circles. ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/ From rostetter at mail.utexas.edu Sun May 9 18:48:39 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 9 May 2004 13:48:39 -0500 Subject: yum and redhat 8.0 In-Reply-To: <000a01c435f3$5419f990$0201a8c0@EuckeLap> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> Message-ID: <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> Quoting Eucke : > I finally was able to get YUM 1.x installed on my RH8 clean > installed server and have been working on getting 2.x installed (latest > current off freshrpms.net) but keep failing a dependency check for rpm 4.1.1 > and rpm-python 4.1.1. See http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/ for the key rpms. If you are having other dependencies, like gnome-rpm or something, then let us know. Most likely you would need to uninstall such problematic rpms. You may be able to find some of them from fedora.us or freshrpms.org, but that isn't a sure thing. > Should I assume that RH8 and YUM 2.x are not ready for prime time? Well, not sure. You'll be telling us. > Should I > perhaps consider moving to RH9 and doing my build there? Perhaps. But we can not decide that for you. You could also consider using apt instead, or sticking with yum 1.x instead. > Your advice will be taken to heart! > > Thanks all! > > Eucke > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Eric Rostetter From skvidal at phy.duke.edu Mon May 10 00:22:04 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 May 2004 20:22:04 -0400 Subject: Problem with GPG Key In-Reply-To: <7C582437-A02B-11D8-918D-00039303286A@umn.edu> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> <20040506213437.52a6214a.fedora@wir-sind-cool.org> <7C582437-A02B-11D8-918D-00039303286A@umn.edu> Message-ID: <1084148524.29382.26.camel@binkley> On Fri, 2004-05-07 at 08:36 -0500, Peter Fleck wrote: > > Run > > > > rpm -Kv > > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > > > > and post the output. > > [root at seafish fleck004]# rpm -Kv > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm: > MD5 sum OK: 084e0d35954655739b8d074ac2a4044f > gpg: Signature made Sat 24 Jan 2004 02:01:34 AM CST using DSA key ID > 731002FA > gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA > > you want to mark the key as trusted in your gpg keyring. look up 'editing your keys' or something like that in the gnupg docs -sv From euckew at sierraelectronics.com Mon May 10 22:10:53 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Mon, 10 May 2004 15:10:53 -0700 Subject: Troubleshooting yum and redhat 8.0 References: <409CBDA6.6020804@clifford.net><20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu><000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> Message-ID: <097c01c436db$a9782ea0$3f01a8c0@Eucke> Ok, trying to stick with the RH8 build (for now). I believe that I have installed all of the required packages. However, the install of Yum fails two dependencies. They are as follows: D: Requires: rpm-python >= 0:4.1.1 NO D: package yum-2.0.3-0.fdr.1.rh80 has unsatisfied Requires: rpm-python >= 0:4.1.1 D: read h# 234 Header V3 DSA signature: NOKEY, key ID db42a60e D: Requires: rpm >= 0:4.1.1 NO D: package yum-2.0.3-0.fdr.1.rh80 has unsatisfied Requires: rpm >= 0:4.1.1 D: read h# 721 Header V3 DSA signature: NOKEY, key ID db42a60e However, when I query to see what's installed I see: [root at email savedRPMs]# rpm -q rpm rpm-4.1-1.06 [root at email savedRPMs]# rpm -q rpm-python rpm-python-4.1-1.06 Both packages, for which the dependencies fail, appear to be present. I consider myself to be pretty green with Linux and am trying to struggle through this with the hope of really gaining more insite into Linux functionality. Is there more information I should providing that I have overlooked? Any thoughts? Any thoughts on why the RPM shows that the packages are installed yet the dependency failure remains? Any suggestions on where to look next? Thanks! -Eucke From skvidal at phy.duke.edu Mon May 10 22:09:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 10 May 2004 18:09:47 -0400 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <097c01c436db$a9782ea0$3f01a8c0@Eucke> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> <097c01c436db$a9782ea0$3f01a8c0@Eucke> Message-ID: <1084226986.2785.35.camel@opus> On Mon, 2004-05-10 at 18:10, Eucke Warren wrote: > Ok, trying to stick with the RH8 build (for now). I believe that I have > installed all of the required packages. However, the install of Yum fails > two dependencies. They are as follows: > > D: Requires: rpm-python >= 0:4.1.1 NO Read carefully: rpm-python >= 0:4.1.1 > [root at email savedRPMs]# rpm -q rpm-python > rpm-python-4.1-1.06 You have 0:4.1 4.1.1 is newer and it's in the utils/updates at fedora.us for rhl 8.0. -sv From euckew at sierraelectronics.com Mon May 10 22:49:16 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Mon, 10 May 2004 15:49:16 -0700 Subject: Troubleshooting yum and redhat 8.0 References: <409CBDA6.6020804@clifford.net><20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu><000a01c435f3$5419f990$0201a8c0@EuckeLap><20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu><097c01c436db$a9782ea0$3f01a8c0@Eucke> <1084226986.2785.35.camel@opus> Message-ID: <098701c436e1$05bed330$3f01a8c0@Eucke> ----- Original Message ----- From: "seth vidal" To: "Discussion of the Fedora Legacy Project" Sent: Monday, May 10, 2004 3:09 PM Subject: Re: Troubleshooting yum and redhat 8.0 > On Mon, 2004-05-10 at 18:10, Eucke Warren wrote: > > Ok, trying to stick with the RH8 build (for now). I believe that I have > > installed all of the required packages. However, the install of Yum fails > > two dependencies. They are as follows: > > > > D: Requires: rpm-python >= 0:4.1.1 NO > > Read carefully: > > rpm-python >= 0:4.1.1 > > > [root at email savedRPMs]# rpm -q rpm-python > > rpm-python-4.1-1.06 > > You have 0:4.1 > > 4.1.1 is newer and it's in the utils/updates at fedora.us for rhl 8.0. > > -sv Thank you. I did attempt to install the required packages. Reading the logs more carefully, when I tried to install the 5 packages from the FL site I found the following couple of entries (among many) in the install log: D: ========== +++ rpm-4.1.1-1.8x D: Requires: libc.so.6(GLIBC_2.3.2) NO D: package rpm-4.1.1-1.8x has unsatisfied Requires: libc.so.6(GLIBC_2.3.2) D: read h# 374 Header V3 DSA signature: NOKEY, key ID db42a60e D: Conflicts: patch < 2.5 D: ========== --- rpm-python-4.1-1.06 D: closed db index /var/lib/rpm/Depends error: Failed dependencies: libc.so.6(GLIBC_2.3.2) is needed by rpm-4.1.1-1.8x D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth) D: 0 0 8 0 0 +popt-1.7.1-1.8x D: 1 1 7 0 1 +rpm-4.1.1-1.8x D: ========== successors only (presentation order) D: 2 0 0 1 0 -popt-1.7-1.06 D: 3 2 0 0 2 -rpm-4.1-1.06 D: 4 2 0 0 2 +rpm-build-4.1.1-1.8x D: 5 2 0 0 2 -rpm-build-4.1-1.06 D: 6 2 0 0 2 +rpm-devel-4.1.1-1.8x D: 7 2 0 0 2 -rpm-devel-4.1-1.06 D: 8 2 0 0 2 +rpm-python-4.1.1-1.8x D: 9 2 0 0 2 -rpm-python-4.1-1.06 D: closed db index /var/lib/rpm/Pubkeys D: closed db index /var/lib/rpm/Providename D: closed db index /var/lib/rpm/Requirename D: closed db index /var/lib/rpm/Basenames D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages Checking to see if the needed package was there yielded [root at email temp]# rpm -q glibc glibc-2.3.2-4.80.8 That, to me would seem to indicate that the needed package is there...it must be something else that is failing the dependency check. What am I missing? Thank you! -Eucke From fedora at wir-sind-cool.org Mon May 10 23:02:18 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 11 May 2004 01:02:18 +0200 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <098701c436e1$05bed330$3f01a8c0@Eucke> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> <097c01c436db$a9782ea0$3f01a8c0@Eucke> <1084226986.2785.35.camel@opus> <098701c436e1$05bed330$3f01a8c0@Eucke> Message-ID: <20040511010218.42912630.fedora@wir-sind-cool.org> On Mon, 10 May 2004 15:49:16 -0700, Eucke Warren wrote: > Thank you. I did attempt to install the required packages. Reading the > logs more carefully, when I tried to install the 5 packages from the FL site > I found the following couple of entries (among many) in the install log: > > D: ========== +++ rpm-4.1.1-1.8x > D: Requires: libc.so.6(GLIBC_2.3.2) NO > D: package rpm-4.1.1-1.8x has unsatisfied Requires: libc.so.6(GLIBC_2.3.2) > Checking to see if the needed package was there yielded > [root at email temp]# rpm -q glibc > glibc-2.3.2-4.80.8 > > That, to me would seem to indicate that the needed package is there...it > must be something else that is failing the dependency check. What am I > missing? Thank you! Dig further. What do you get for...? rpm --query --provides glibc | grep libc rpm --query --whatprovides 'libc.so.6(GLIBC_2.3.2)' From euckew at sierraelectronics.com Mon May 10 23:15:08 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Mon, 10 May 2004 16:15:08 -0700 Subject: Troubleshooting yum and redhat 8.0 References: <409CBDA6.6020804@clifford.net><20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu><000a01c435f3$5419f990$0201a8c0@EuckeLap><20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu><097c01c436db$a9782ea0$3f01a8c0@Eucke><1084226986.2785.35.camel@opus><098701c436e1$05bed330$3f01a8c0@Eucke> <20040511010218.42912630.fedora@wir-sind-cool.org> Message-ID: <099801c436e4$a2ab8690$3f01a8c0@Eucke> ----- Original Message ----- From: "Michael Schwendt" To: "Discussion of the Fedora Legacy Project" Sent: Monday, May 10, 2004 4:02 PM Subject: Re: Troubleshooting yum and redhat 8.0 > Dig further. What do you get for...? > > rpm --query --provides glibc | grep libc > rpm --query --whatprovides 'libc.so.6(GLIBC_2.3.2)' Here it is. [root at email root]# rpm --query --provides glibc | grep libc libcrypt.so.1 libcrypt.so.1(GLIBC_2.0) libc.so.6 libc.so.6(GCC_3.0) libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.2.1) libc.so.6(GLIBC_2.2.2) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.2.4) libc.so.6(GLIBC_2.2.6) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.2) libc.so.6(GLIBC_2.3.3) glibc = 2.3.2-4.80.8 [root at email root]# and [root at email root]# [root at email root]# rpm --query --whatprovides 'libc.so.6(GLIBC_2.3.2)' glibc-2.3.2-4.80.8 Does it appear that my glibc needs updating? Or am I starting to run into the wall for RH8? For what it's worth...if I can successfully get to the end of this I'd be happy to do a write up on it if that would be of some help! -Eucke From fedora at wir-sind-cool.org Mon May 10 23:19:21 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 11 May 2004 01:19:21 +0200 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <098701c436e1$05bed330$3f01a8c0@Eucke> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> <097c01c436db$a9782ea0$3f01a8c0@Eucke> <1084226986.2785.35.camel@opus> <098701c436e1$05bed330$3f01a8c0@Eucke> Message-ID: <20040511011921.535df7b8.fedora@wir-sind-cool.org> On Mon, 10 May 2004 15:49:16 -0700, Eucke Warren wrote: > I found the following couple of entries (among many) in the install log: > > D: ========== +++ rpm-4.1.1-1.8x > D: Requires: libc.so.6(GLIBC_2.3.2) NO > D: package rpm-4.1.1-1.8x has unsatisfied Requires: libc.so.6(GLIBC_2.3.2) > > D: read h# 374 Header V3 DSA signature: NOKEY, key ID db42a60e key ID db42a60e is Red Hat's key for security updates. Why is that key listed here? Makes me wonder what you tried to update/install here and what command you used? From fedora at wir-sind-cool.org Mon May 10 23:23:15 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 11 May 2004 01:23:15 +0200 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <099801c436e4$a2ab8690$3f01a8c0@Eucke> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> <097c01c436db$a9782ea0$3f01a8c0@Eucke> <1084226986.2785.35.camel@opus> <098701c436e1$05bed330$3f01a8c0@Eucke> <20040511010218.42912630.fedora@wir-sind-cool.org> <099801c436e4$a2ab8690$3f01a8c0@Eucke> Message-ID: <20040511012315.6a1b7a2d.fedora@wir-sind-cool.org> On Mon, 10 May 2004 16:15:08 -0700, Eucke Warren wrote: > [root at email root]# rpm --query --whatprovides 'libc.so.6(GLIBC_2.3.2)' > glibc-2.3.2-4.80.8 > > Does it appear that my glibc needs updating? No, your glibc provides what your upgrade attempt complained about. I'm puzzled. But it smells like some details are missing. > Or am I starting to run into > the wall for RH8? For what it's worth...if I can successfully get to the > end of this I'd be happy to do a write up on it if that would be of some > help! I've installed the newer RPM before, multiple times, but with the packages provides in the fedora.us for rh80 "patches" repository. From euckew at sierraelectronics.com Mon May 10 23:27:45 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Mon, 10 May 2004 16:27:45 -0700 Subject: Troubleshooting yum and redhat 8.0 References: <409CBDA6.6020804@clifford.net><20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu><000a01c435f3$5419f990$0201a8c0@EuckeLap><20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu><097c01c436db$a9782ea0$3f01a8c0@Eucke><1084226986.2785.35.camel@opus><098701c436e1$05bed330$3f01a8c0@Eucke> <20040511011921.535df7b8.fedora@wir-sind-cool.org> Message-ID: <099d01c436e6$65e2d900$3f01a8c0@Eucke> ----- Original Message ----- From: "Michael Schwendt" To: "Discussion of the Fedora Legacy Project" Sent: Monday, May 10, 2004 4:19 PM Subject: Re: Troubleshooting yum and redhat 8.0 > On Mon, 10 May 2004 15:49:16 -0700, Eucke Warren wrote: > > > I found the following couple of entries (among many) in the install log: > > > > D: ========== +++ rpm-4.1.1-1.8x > > D: Requires: libc.so.6(GLIBC_2.3.2) NO > > D: package rpm-4.1.1-1.8x has unsatisfied Requires: libc.so.6(GLIBC_2.3.2) > > > > D: read h# 374 Header V3 DSA signature: NOKEY, key ID db42a60e > > key ID db42a60e is Red Hat's key for security updates. Why is that key > listed here? Makes me wonder what you tried to update/install here and > what command you used? > I used rpm -Uvvh *.rpm >LOG 2>&1 on the following files from the FL file stores. rpm-4.1.1-1.8x.i386.rpm rpm-devel-4.1.1-1.8x.i386.rpm popt-1.7.1-1.8x.i386.rpm rpm-build-4.1.1-1.8x.i386.rpm rpm-python-4.1.1-1.8x.i386.rpm From fedora at wir-sind-cool.org Tue May 11 00:38:51 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 11 May 2004 02:38:51 +0200 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <099d01c436e6$65e2d900$3f01a8c0@Eucke> References: <409CBDA6.6020804@clifford.net> <20040509123124.ydh7k08g8gwwk8cg@mail.ph.utexas.edu> <000a01c435f3$5419f990$0201a8c0@EuckeLap> <20040509134839.t345sscs0g4w0c4w@mail.ph.utexas.edu> <097c01c436db$a9782ea0$3f01a8c0@Eucke> <1084226986.2785.35.camel@opus> <098701c436e1$05bed330$3f01a8c0@Eucke> <20040511011921.535df7b8.fedora@wir-sind-cool.org> <099d01c436e6$65e2d900$3f01a8c0@Eucke> Message-ID: <20040511023851.6888ac54.fedora@wir-sind-cool.org> On Mon, 10 May 2004 16:27:45 -0700, Eucke Warren wrote: > > > On Mon, 10 May 2004 15:49:16 -0700, Eucke Warren wrote: > > > > > I found the following couple of entries (among many) in the install log: > > > > > > D: ========== +++ rpm-4.1.1-1.8x > > > D: Requires: libc.so.6(GLIBC_2.3.2) NO > > > D: package rpm-4.1.1-1.8x has unsatisfied Requires: > libc.so.6(GLIBC_2.3.2) > > > D: read h# 374 Header V3 DSA signature: NOKEY, key ID db42a60e Above line is from a different package. > > key ID db42a60e is Red Hat's key for security updates. Why is that key > > listed here? Makes me wonder what you tried to update/install here and > > what command you used? > > > > I used > > rpm -Uvvh *.rpm >LOG 2>&1 > > on the following files from the FL file stores. > > rpm-4.1.1-1.8x.i386.rpm > rpm-devel-4.1.1-1.8x.i386.rpm > popt-1.7.1-1.8x.i386.rpm > rpm-build-4.1.1-1.8x.i386.rpm > rpm-python-4.1.1-1.8x.i386.rpm I can install the rpm package just fine: # rpm -Kv rpm-4.1.1-1.8x.i386.rpm rpm-4.1.1-1.8x.i386.rpm: Header V3 DSA signature: NOKEY, key ID 2039b291 Header SHA1 digest: OK (01746a3fe9d53fe63473215b6564ce315ef40cda) MD5 digest: OK (3504db31fd4668c33c6f15dce62151ec) V3 DSA signature: OK, key ID 731002fa (key ID 2039b291 is Jeff Johnson's key) # rpm -Uvh rpm-4.1.1-1.8x.i386.rpm --replacepkgs Preparing... ########################################### [100%] 1:rpm ########################################### [100%] (have to use --replacepkgs, because the same package is installed already) No idea currently what your problem is. The --whatprovides checks were successful. From barryn at pobox.com Tue May 11 23:24:43 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Tue, 11 May 2004 16:24:43 -0700 Subject: Troubleshooting yum and redhat 8.0 In-Reply-To: <099801c436e4$a2ab8690$3f01a8c0@Eucke> References: <20040511010218.42912630.fedora@wir-sind-cool.org> <099801c436e4$a2ab8690$3f01a8c0@Eucke> Message-ID: <20040511232443.GA3976@ip68-4-98-123.oc.oc.cox.net> On Mon, May 10, 2004 at 04:15:08PM -0700, Eucke Warren wrote: > Does it appear that my glibc needs updating? Or am I starting to run into > the wall for RH8? For what it's worth...if I can successfully get to the > end of this I'd be happy to do a write up on it if that would be of some > help! What output (if any) do you get if you run the following command? /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages What happens if you do the following: cp -a /var/lib/rpm /var/lib/rpm.backup rpm --rebuilddb then try again? (The cp command is to back up the RPM database in case something *really* goes wrong.) -Barry K. Nathan From mh at samurajdata.se Wed May 12 09:13:51 2004 From: mh at samurajdata.se (Markus Hakansson) Date: 12 May 2004 11:13:51 +0200 Subject: apt or yum? Message-ID: <1084353230.2314.1176.camel@khc09.samurajdata.se> Are there any arguments for which of these to chose? As I understand it, yum has been chosen as 'the official' up2date-replacement for Fedora Legacy (and Fedora Core), is that correct? Are the yum and apt repositories updated at the same time, or is one the 'master' so the other might lag behind? Personally, I like apt better for its speed but I feel that I don't really know if yum has any technical advantages. Could anybody shed any light on this? Sincerely, Markus Hakansson From dom at earth.li Wed May 12 09:52:46 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 12 May 2004 10:52:46 +0100 Subject: Self-Introduction: Dominic Hargreaves Message-ID: <20040512095246.GQ960@tirian.magd.ox.ac.uk> Hi, A much belated formal self-introduction: 1. Dominic Hargreaves (Full initials JMDH, I don't use the first two) 2. Oxford, UK 3. System administrator 4. Dept. of Astrophysics, University of Oxford 5. - Redhat 7.3 for network of workstations - Yes, time permitting - No special goals at this time 6. - Various experience adminning rh5-7 and debian boxes and building custom RPMs. - No major contributions to publically-visible projects so far (beyond what I've already done for FL). - Already have diverse admin responsibility over various personal, university and society machines with various sets of users (eg college and Computer society-run systems - see . As well as my own pledges and UK law I am bound by the University computer misuse policy. - Personal web page is at . pub 1024D/5178E2A5 1999-11-29 Dominic Hargreaves Key fingerprint = 1176 44DF C579 B6DD 3E71 0CB5 633B 8528 5178 E2A5 uid Dominic Hargreaves uid [revoked] dominic at netcomuk.co.uk sub 2048g/1C8FB44B 1999-11-29 Cheers, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From wipe_out at users.sourceforge.net Wed May 12 09:28:19 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Wed, 12 May 2004 10:28:19 +0100 Subject: apt or yum? In-Reply-To: <1084353230.2314.1176.camel@khc09.samurajdata.se> References: <1084353230.2314.1176.camel@khc09.samurajdata.se> Message-ID: <40A1EE33.6010700@users.sourceforge.net> Markus Hakansson wrote: >Are there any arguments for which of these to chose? >As I understand it, yum has been chosen as 'the official' >up2date-replacement for Fedora Legacy (and Fedora Core), is that >correct? >Are the yum and apt repositories updated at the same time, or is one the >'master' so the other might lag behind? > >Personally, I like apt better for its speed but I feel that I don't >really know if yum has any technical advantages. > >Could anybody shed any light on this? > > > > This has been discussed quite a lot with people defending their own choice quite strongly.. I would say use which ever one you are comfortable with.. Personally I use YUM because I found it simple to use and it did what I needed, so I have never tried APT.. Youe question is like many in the Linux and OSS world.. similar examples are "Should I use Gnome or KDE?", "Which Distro is best?" or "Should I use Netscape, Mozilla or Konqueror?".. These all have the same answer, which ever you prefer.. Later.. From raphael at clifford.net Wed May 12 17:08:46 2004 From: raphael at clifford.net (Raphael Clifford) Date: Wed, 12 May 2004 18:08:46 +0100 Subject: yum/apt-get In-Reply-To: <20040512160008.E9F3575027@hormel.redhat.com> References: <20040512160008.E9F3575027@hormel.redhat.com> Message-ID: <40A25A1E.1050208@clifford.net> >>Are there any arguments for which of these to chose? >>As I understand it, yum has been chosen as 'the official' >>up2date-replacement for Fedora Legacy (and Fedora Core), is that >>correct? >>Are the yum and apt repositories updated at the same time, or is one the >>'master' so the other might lag behind? >> >>Personally, I like apt better for its speed but I feel that I don't >>really know if yum has any technical advantages. >> >>Could anybody shed any light on this? >> >> >> >> >> >> >This has been discussed quite a lot with people defending their own >choice quite strongly.. > >I would say use which ever one you are comfortable with.. Personally I >use YUM because I found it simple to use and it did what I needed, so I >have never tried APT.. > >Youe question is like many in the Linux and OSS world.. similar examples >are "Should I use Gnome or KDE?", "Which Distro is best?" or "Should I >use Netscape, Mozilla or Konqueror?".. These all have the same answer, >which ever you prefer.. > >Later.. > > > As I don't feel strongly about this at all I will attempt to put in my 1/2 cent worth... From a completely practical point of view of the end user you will notice two main differences between yum and apt-get. 1) Yum has very few options. Look at the man page to see what I mean. The only documented (and non-deprecated) yum commands on my system are "install, update, check-update, list, info, provides, search, clean" plus mostly debugging flags. 2) Yum is very slow for any sizeable update and even downloading headers can take a long time (over an hour in some cases) if you haven't done it for a while. If all you want to do is get the latest updates every now and then it makes very little practical difference which one you use apart from the speed issue (which doesn't bother too many people in reality) and any bugs which there might be in one or the other. If you want to do fancier things then apt-get is the way you have to go currently. I hope that helps. Of course, if you simply *prefer* one to the other for some random aesthetic reason that is fine too :) Raphael P.S. I use yum. From kelson at speed.net Wed May 12 17:39:41 2004 From: kelson at speed.net (Kelson Vibber) Date: Wed, 12 May 2004 10:39:41 -0700 Subject: yum/apt-get In-Reply-To: <40A25A1E.1050208@clifford.net> References: <20040512160008.E9F3575027@hormel.redhat.com> <40A25A1E.1050208@clifford.net> Message-ID: <6.1.0.6.0.20040512103618.026bac28@mail.speed.net> At 10:08 AM 5/12/2004, Raphael Clifford wrote: > From a completely practical point of view of the end user you will notice > two main differences between yum and apt-get. > >1) Yum has very few options. Look at the man page to see what I mean. The >only documented (and non-deprecated) yum commands on my system are >"install, update, check-update, list, info, provides, search, clean" plus >mostly debugging flags. >2) Yum is very slow for any sizeable update and even downloading headers >can take a long time (over an hour in some cases) if you haven't done it >for a while I'd like to add: 3) Apt-get has better front-ends. If all you're doing is grabbing updates, yum and apt-get seem about equal. But for finding and installing software, apt-cache and Synaptic (a GUI front-end to apt-get) are hard to beat. FWIW, I've ended up using apt-get and synaptic on desktops (most of which are running Fedora Core) and yum on servers (most of which are running RHL with Fedora Legacy). Hmm... Has anyone considered setting up a Red Carpet repository using the tools at http://opencarpet.org/ ? Kelson Vibber SpeedGate Communications From ral77 at bellsouth.net Thu May 13 03:23:27 2004 From: ral77 at bellsouth.net (ral77) Date: Wed, 12 May 2004 23:23:27 -0400 Subject: RH9 user - what should I do? In-Reply-To: <20040508201609.6e90e433.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> Message-ID: <40A2EA2F.9060406@bellsouth.net> Michael Schwendt wrote: >On Sat, 08 May 2004 13:12:55 +0200, Troed S?ngberg wrote: > > > >>I must be blind. I've looked all over the Fedora Legacy project page, read >>(I think, at least) the available documentation on the web, but I have _no >>idea_ what to do to get my RH9-machine that previously used up2date for >>security updates, to start using the packages from the Legacy project. >> >> > >Not enough people preparing the documentation in time. > > > >>Please - a step-by-step guide that doesn't ask me to choose between >>yum/apt-whatever since I, as a stupid RH9 user, have only got a very vague >>idea on the difference and significance of that choice? >> >> > >Let me see. My suggestion: > >* Run: rpm --import http://www.fedora.us/FEDORA-GPG-KEY > >* Get http://download.fedora.us/fedora/redhat/9/i386/RPMS.stable/yum-2.0.3-0.fdr.1.rh90.noarch.rpm > >Install it with "rpm -Uvh yum-2.0.3-0.fdr.1.rh90.noarch.rpm" >Or install it directly with "rpm -ivh http://...." of the network. >RPM can do that. > >* Install the Fedora Legacy public key for verifying package signatures. > rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY > >* Choose a mirror of Fedora Legacy for Red Hat Linux 9 from the website, > e.g. modify /etc/yum.conf in the section that reads > > [redhat-updates] > name=Red Hat Linux $releasever ($basearch) updates > baseurl= > http://download.fedora.us/... > > to use a different baseurl= such as: > > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ > >* If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, >disable the [fedora-stable] entry in the lower half of /etc/yum.conf. > >* Then run "yum update" for the first time to fetch package headers. Note >there is a "yum" service which can download updates at night. > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > Hello Michael, I just followered the above procedures you posted and it worked flawlessly. Thank you for your very informative post. Best regards, From dom at earth.li Thu May 13 13:49:26 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 13 May 2004 14:49:26 +0100 Subject: Kernel updates for QA In-Reply-To: <20040507222550.A31352@mail.harddata.com> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507130058.A16913@mail.harddata.com> <20040508005356.GA960@tirian.magd.ox.ac.uk> <20040507222550.A31352@mail.harddata.com> Message-ID: <20040513134926.GT960@tirian.magd.ox.ac.uk> On Fri, May 07, 2004 at 10:25:50PM -0600, Michal Jaegermann wrote: > The thing is that if you have an nforce2 mobo then depending on > your BIOS you may not notice anything amiss or you may get assorted > crashes, data corruption, etc. If you do not have such board then > you are not affected at all - patched or not patched. Personally > I am falling in the later category. > > This fix is indeed a few days old but only now the information > on which it is based become available. In the absence of any further comment I've included the patch from http://linux.bkbits.net:8080/linux-2.4/diffs/arch/i386/kernel/pci-pc.c at 1.36?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel|hist/arch/i386/kernel/pci-pc.c and am rebuilding the packages for further testing. If anyone thinks that we definitely shouldn't be putting this fix in please speak now! Cheers, Dominic. From dom at earth.li Thu May 13 14:31:17 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 13 May 2004 15:31:17 +0100 Subject: Kernel updates for QA In-Reply-To: <20040513134926.GT960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507130058.A16913@mail.harddata.com> <20040508005356.GA960@tirian.magd.ox.ac.uk> <20040507222550.A31352@mail.harddata.com> <20040513134926.GT960@tirian.magd.ox.ac.uk> Message-ID: <20040513143117.GU960@tirian.magd.ox.ac.uk> On Thu, May 13, 2004 at 02:49:26PM +0100, Dominic Hargreaves wrote: > In the absence of any further comment I've included the patch from > http://linux.bkbits.net:8080/linux-2.4/diffs/arch/i386/kernel/pci-pc.c at 1.36?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel|hist/arch/i386/kernel/pci-pc.c > and am rebuilding the packages for further testing. If anyone thinks > that we definitely shouldn't be putting this fix in please speak now! P.S. Are the version numbers I'm using at the moment suitable? For example, kernel-2.4.20-31.7.legacy.2. It just occured to me that I can't see any other FL updates with that numbering scheme so maybe kernel-2.4.20-31.7.2.legacy would be better? (or since there won't be any further official Red Hat updates, just kernel-2.4.20-32.7.legacy). I know this isn't a clearcut decision but can anyone comments (Jesse?) Cheers, Dominic. From jkeating at j2solutions.net Thu May 13 14:49:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 07:49:47 -0700 Subject: Kernel updates for QA In-Reply-To: <20040513134926.GT960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507222550.A31352@mail.harddata.com> <20040513134926.GT960@tirian.magd.ox.ac.uk> Message-ID: <200405130749.47757.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 May 2004 06:49, Dominic Hargreaves wrote: > In the absence of any further comment I've included the patch from > http://linux.bkbits.net:8080/linux-2.4/diffs/arch/i386/kernel/pci-pc. >c at 1.36?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel >|hist/arch/i386/kernel/pci-pc.c and am rebuilding the packages for > further testing. If anyone thinks that we definitely shouldn't be > putting this fix in please speak now! Does this patch effect non-nforce2 systems in any way? - -- 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) iD8DBQFAo4sL4v2HLvE71NURAqPUAKCC0sZ/dO84XF/GzskUFHWRtKR0ggCgjBgG Gz3jnxUR/oNovMaxEYQvNbU= =f8Rh -----END PGP SIGNATURE----- From dom at earth.li Thu May 13 14:56:03 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 13 May 2004 15:56:03 +0100 Subject: Kernel updates for QA In-Reply-To: <200405130749.47757.jkeating@j2solutions.net> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507222550.A31352@mail.harddata.com> <20040513134926.GT960@tirian.magd.ox.ac.uk> <200405130749.47757.jkeating@j2solutions.net> Message-ID: <20040513145603.GV960@tirian.magd.ox.ac.uk> On Thu, May 13, 2004 at 07:49:47AM -0700, Jesse Keating wrote: > Does this patch effect non-nforce2 systems in any way? If I read the patch correctly it only affects systems with PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2 so it shouldn't affect anything else. Cheers, Dominic. From fedoraleg_form at mm-vanecek.cc Thu May 13 15:16:22 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 10:16:22 -0500 Subject: RH9 user - what should I do? In-Reply-To: <40A2EA2F.9060406@bellsouth.net> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> Message-ID: <20040513151414.M95390@mm-vanecek.cc> Michael Schwendt wrote: >* If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, >disable the [fedora-stable] entry in the lower half of /etc/yum.conf. What are Fedora.us add-ons for RH 9? Why would I want or not want them? From jkeating at j2solutions.net Thu May 13 15:29:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 08:29:18 -0700 Subject: Kernel updates for QA In-Reply-To: <20040513145603.GV960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405130749.47757.jkeating@j2solutions.net> <20040513145603.GV960@tirian.magd.ox.ac.uk> Message-ID: <200405130829.20871.jkeating@j2solutions.net> On Thursday 13 May 2004 07:56, Dominic Hargreaves wrote: > If I read the patch correctly it only affects systems with > PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2 > > so it shouldn't affect anything else. And just to be sure, this helps nforce2 people out in what way? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dom at earth.li Thu May 13 16:09:36 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 13 May 2004 17:09:36 +0100 Subject: Kernel updates for QA In-Reply-To: <200405130829.20871.jkeating@j2solutions.net> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405130749.47757.jkeating@j2solutions.net> <20040513145603.GV960@tirian.magd.ox.ac.uk> <200405130829.20871.jkeating@j2solutions.net> Message-ID: <20040513160936.GX960@tirian.magd.ox.ac.uk> On Thu, May 13, 2004 at 08:29:18AM -0700, Jesse Keating wrote: > And just to be sure, this helps nforce2 people out in what way? Michael explained it in as much detail as I know in message <20040507222550.A31352 at mail.harddata.com>. It sounds like the bug is a showstopper for people with these boards, but I don't have any further details. We'd need to get some testing in this particular patch to ensure that it does actually fix the issue, but it has been accepted by Marcelo into the mainline 2.4 series. Cheers, Dominic. From jkeating at j2solutions.net Thu May 13 16:22:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 09:22:33 -0700 Subject: Kernel updates for QA In-Reply-To: <20040513160936.GX960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405130829.20871.jkeating@j2solutions.net> <20040513160936.GX960@tirian.magd.ox.ac.uk> Message-ID: <200405130922.35937.jkeating@j2solutions.net> On Thursday 13 May 2004 09:09, Dominic Hargreaves wrote: > Michael explained it in as much detail as I know in message > <20040507222550.A31352 at mail.harddata.com>. It sounds like the bug is > a showstopper for people with these boards, but I don't have any > further details. We'd need to get some testing in this particular > patch to ensure that it does actually fix the issue, but it has been > accepted by Marcelo into the mainline 2.4 series. Ah, if it's in mainline, that makes me feel a bit better. Go ahead and put the patch in and we'll test it during QA phases. Please gather as many nforce2 users you can across 7.2/7.3/8.0/9 to test this. Thanks! -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at wir-sind-cool.org Thu May 13 17:04:18 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 13 May 2004 19:04:18 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513151414.M95390@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> <20040513151414.M95390@mm-vanecek.cc> Message-ID: <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> On Thu, 13 May 2004 10:16:22 -0500, Mike Vanecek wrote: > >* If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, > >disable the [fedora-stable] entry in the lower half of /etc/yum.conf. > > What are Fedora.us add-ons for RH 9? Extras packages not included in Red Hat Linux 9. Browse the redhat/9 repositories at http://fedora.us > Why would I want or not want them? Decide yourself. You would avoid downloading additional headers, for instance. ;) From fedoraleg_form at mm-vanecek.cc Thu May 13 17:05:51 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 12:05:51 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040508201609.6e90e433.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> Message-ID: <20040513170246.M7106@mm-vanecek.cc> On Sat, 8 May 2004 20:16:09 +0200, Michael Schwendt wrote [snip] > * Choose a mirror of Fedora Legacy for Red Hat Linux 9 from the > website, > e.g. modify /etc/yum.conf in the section that reads > > [redhat-updates] > name=Red Hat Linux $releasever ($basearch) updates > baseurl= > http://download.fedora.us/... > > to use a different baseurl= such as: > > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ What is the best baseurl to use for [redhat-os] name=Red Hat Linux $releasever ($basearch) baseurl= ? I want to keep the base os as RH 9, not Fedora. Is there a yum repository for the base RH 9? From fedora at wir-sind-cool.org Thu May 13 17:16:18 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 13 May 2004 19:16:18 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513170246.M7106@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> Message-ID: <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> On Thu, 13 May 2004 12:05:51 -0500, Mike Vanecek wrote: > > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ > > What is the best baseurl to use for > > [redhat-os] > name=Red Hat Linux $releasever ($basearch) > baseurl= ? > > I want to keep the base os as RH 9, not Fedora. Is there a yum repository for > the base RH 9? For instance, this mirror: http://legacy.linux.duke.edu/redhat/9/ baseurl=http://legacy.linux.duke.edu/redhat/$releasever/os/$basearch/ I think you misunderstand a few things about Fedora Legacy, Fedora Core and Fedora.us. The default baseurl in fedora.us' yum package points to a plain mirror of Red Hat Linux 9 (just that it is located on Hawaii, and you should find a more nearby one, unless you are located on Hawaii, too). From B.Smith at bio.gla.ac.uk Thu May 13 17:17:46 2004 From: B.Smith at bio.gla.ac.uk (Brian Smith) Date: Thu, 13 May 2004 18:17:46 +0100 (BST) Subject: yum and redhat 8.0 Message-ID: Hi, I just followed through the yum and 8.0 instructions http://www.fedoralegacy.org/docs/yum-rh8.php and noticed a few things 1/ Might be worth mentioning use of proxies with rpm for people like me who have to use a proxy i.e. rpm -httpproxy yourproxy.host.name -httpport yourproxyport -Uvh .... 2/ Worth pointing people at their local mirrors e.g. in the UK rpm -httpproxy wwwcache.gla.ac.uk -httpport 8080 -Uvh \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/legacy-utils/i386/rpm-4.1.1-1.8x.i386.rpm \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/legacy-utils/i386/rpm-build-4.1.1-1.8x.i386.rpm \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/legacy-utils/i386/rpm-devel-4.1.1-1.8x.i386.rpm \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/legacy-utils/i386/rpm-python-4.1.1-1.8x.i386.rpm \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/legacy-utils/i386/popt-1.7.1-1.8x.i386.rpm \ http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/8.0/updates/i386/gnupg-1.0.7-14.i386.rpm BUT for me rpm would only work on the first package in the list with these long URLs and so I had to download them all with wget (or curl, or web browser) and then everything was OK 3/ I already had python-2.2.1-17 and the python-1.5.2-43.72.i386.rpm doesn't seem to be in the 8.0 tree. 4/ Yum configuration info conflicts with http://fedoralegacy.org/download/ which has blocks that seem more up to date. However it omits the gpgcheck tip. Worth mentioning proxy configuration for yum? declare -x http_proxy='http://yourproxy.host.name:yourproxyport/' Worth encouraging use of mirrors? e.g. [base] name=Red Hat Linux $releasever base baseurl=http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/$releasever/os/$basearch gpgcheck=1 [updates] name=Red Hat Linux $releasever updates baseurl=http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/$releasever/updates/$basearch gpgcheck=1 [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://www.mirror.ac.uk/sites/download.fedoralegacy.org/legacy/redhat/$releasever/legacy-utils/$basearch gpgcheck=1 5/ Annoying of the ac.uk mirror to insert that extra /legacy/, innit? Thanks to everyone on the project. Brian -- Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk From fedoraleg_form at mm-vanecek.cc Thu May 13 18:30:04 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 13:30:04 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> Message-ID: <20040513173648.M32456@mm-vanecek.cc> On Thu, 13 May 2004 19:16:18 +0200, Michael Schwendt wrote > On Thu, 13 May 2004 12:05:51 -0500, Mike Vanecek wrote: > > > > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ > > > > What is the best baseurl to use for > > > > [redhat-os] > > name=Red Hat Linux $releasever ($basearch) > > baseurl= ? > > > > I want to keep the base os as RH 9, not Fedora. Is there a yum repository for > > the base RH 9? > > For instance, this mirror: http://legacy.linux.duke.edu/redhat/9/ > > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/os/$basearch/ > > I think you misunderstand a few things about Fedora Legacy, Fedora Core > and Fedora.us. The default baseurl in fedora.us' yum package points > to a plain mirror of Red Hat Linux 9 (just that it is located on > Hawaii, and you should find a more nearby one, unless you are > located on Hawaii, too). OK. Please correct me if I do not understand things: [redhat-os] name=Red Hat Linux $releasever ($basearch) baseurl= http://download.fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ which basically gets me to http://download.fedora.us/fedora/redhat/9/i386/yum/os/RPMS/ which, as you note, is located in Hawaii. [For me then, http://mirrors.kernel.org/fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ makes sense. BTW, the default config file has it listed as fedora/fedora.] If I can ever connect to ftp://ftp.redhat.com/pub/redhat/linux/9/en/os/i386/RedHat/ the ftp.redhat.com site should contain basically the same files as seen at download.fedora.us or mirros.kernel.org, i.e., the original RH 9 rpms. BTW, a sentence or two on the doco at http://www.fedoralegacy.org/docs/yum-rh9.php explaining that the fedora/redhat site is just the original RH 9 might help others in the future. A link to mirrors http://www.fedora.us/wiki/FedoraMirrorList might help too. The doco says to run yum update as root. Being the cautious type about new things, it might be better to suggest running yum check-update first to create the package list and see if something needs installing. Also, some explanation as to why (exclude=kernel*) kernels are being excluded. Uhm, why are the kernels being excluded? Why is it when one does a yum list, all the mysql rpms are not listed even though they are on the server (both at download.fedora.us and mirrors.kernel.org)? mysql-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 5.0M mysql-devel-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 566K mysql-server-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 1.1M Thanks for the help. As I learn I will try to help others with the basics as well. From fedoraleg_form at mm-vanecek.cc Thu May 13 18:59:02 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 13:59:02 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> <20040513151414.M95390@mm-vanecek.cc> <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> Message-ID: <20040513183930.M22910@mm-vanecek.cc> On Thu, 13 May 2004 19:04:18 +0200, Michael Schwendt wrote > On Thu, 13 May 2004 10:16:22 -0500, Mike Vanecek wrote: > > > >* If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, > > >disable the [fedora-stable] entry in the lower half of /etc/yum.conf. > > > > What are Fedora.us add-ons for RH 9? > > Extras packages not included in Red Hat Linux 9. Browse the redhat/9 > repositories at http://fedora.us > > > Why would I want or not want them? > > Decide yourself. You would avoid downloading additional headers, > for instance. ;) OK. I took a look at http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/stable/RPMS/. Were those packages created for RH 9 or for Fedora XX? I thought all the fedora stuff was to support the fedora core? However, the numbering on the packages could lead one to think that they are created for RH 9. In any event, I think I will leave them out for a while until I get a little better feel for fedora-legacy. I noticed that the rpms for chkrootkit and leafnode are not current. I suspect that will probably be the case for the extras I have installed for original sources. From villegas at math.gatech.edu Thu May 13 19:04:48 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Thu, 13 May 2004 15:04:48 -0400 Subject: Kernel updates for QA In-Reply-To: <20040513143117.GU960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040507130058.A16913@mail.harddata.com> <20040508005356.GA960@tirian.magd.ox.ac.uk> <20040507222550.A31352@mail.harddata.com> <20040513134926.GT960@tirian.magd.ox.ac.uk> <20040513143117.GU960@tirian.magd.ox.ac.uk> Message-ID: <20040513190448.GJ26276@hemi.math.gatech.edu> On Thu, May 13, 2004 at 03:31:17PM +0100, Dominic Hargreaves wrote: > P.S. Are the version numbers I'm using at the moment suitable? > For example, kernel-2.4.20-31.7.legacy.2. Anyone correct me if I'm wrong, but as I understood it (from some discussion recently) the RH release will remain intact, with an appended legacy release, so if the last release from RH was 31.7 then we should use 31.7.0.legacy.7.x (where that 0 will increase as updates are released) and the same for other RHL versions (which goes after the "legacy", so anything for RHL 9 will end in legacy.9). Carlos From jkeating at j2solutions.net Thu May 13 19:03:27 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 12:03:27 -0700 Subject: Kernel updates for QA In-Reply-To: <20040513190448.GJ26276@hemi.math.gatech.edu> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040513143117.GU960@tirian.magd.ox.ac.uk> <20040513190448.GJ26276@hemi.math.gatech.edu> Message-ID: <200405131203.30937.jkeating@j2solutions.net> On Thursday 13 May 2004 12:04, Carlos Villegas wrote: > Anyone correct me if I'm wrong, but as I understood it (from some > discussion recently) the RH release will remain intact, with an > appended legacy release, so if the last release from RH was 31.7 > then we should use 31.7.0.legacy.7.x (where that 0 will increase > as updates are released) and the same for other RHL versions > (which goes after the "legacy", so anything for RHL 9 will end in > legacy.9). Not quite for kernels. We can continue bumping the build version of kernels, as we know that there will be no more 2.4.20 kernels issued by Red Hat, and thus there will be no chance of version collision. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at wir-sind-cool.org Thu May 13 19:19:46 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 13 May 2004 21:19:46 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513183930.M22910@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> <20040513151414.M95390@mm-vanecek.cc> <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> <20040513183930.M22910@mm-vanecek.cc> Message-ID: <20040513211946.709cd035.fedora@wir-sind-cool.org> On Thu, 13 May 2004 13:59:02 -0500, Mike Vanecek wrote: > I took a look at > > http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/stable/RPMS/. > > Were those packages created for RH 9 or for Fedora XX? I thought all the > fedora stuff was to support the fedora core? However, the numbering on the > packages could lead one to think that they are created for RH 9. *Please* take a look at the main page of http://fedora.us and what it says near the top. http://fedora.us was using the name "fedora" _before_ the Fedora Project. It started as "Fedora Linux" an add-ons project for Red Hat Linux. http://www.fedora.us/fedora-merge.html Let's take a closer look at your URL from above (I think there's a table somewhere explaining the structure, too): http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/stable/RPMS/. http://mirrors.kernel.org/ => this is a server mirroring several other serves http://mirrors.kernel.org/fedora.us/ => this is a mirror of http://download.fedora.us http://mirrors.kernel.org/fedora.us/fedora/ => this second "fedora" directory has nothing to do with "Fedora Core" => it is just a top directory at the master site http://mirrors.kernel.org/fedora.us/fedora/redhat/ => this is the root directory of the add-ons for Red Hat Linux The root directory of the add-ons for Fedora Core would be: http://mirrors.kernel.org/fedora.us/fedora/fedora/ http://mirrors.kernel.org/fedora.us/fedora/redhat/9/ => this is the root of the add-ons for Red Hat Linux 9 In it you find RPMS.os : Red Hat Linux 9 RPMS.updates : Red Hat Linux 9 Errata + Fedora Legacy Updates for Red Hat Linux 9 RPMS.updates-testing : -not used with Red Hat Linux - RPMS.stable : Extras for Red Hat Linux 9 RPMS.testing : Extras for Red Hat Linux 9 RPMS.unstable : Extras for Red Hat Linux 9 and the same for source rpms. > In any event, I think I will leave them out for a while until I get a little > better feel for fedora-legacy. I noticed that the rpms for chkrootkit and > leafnode are not current. I suspect that will probably be the case for the > extras I have installed for original sources. leafnode : 1.9.53 is in the publish queue chkrootkit : 0.43 is latest release From fedora at wir-sind-cool.org Thu May 13 19:19:49 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 13 May 2004 21:19:49 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513173648.M32456@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> Message-ID: <20040513211949.790c4032.fedora@wir-sind-cool.org> On Thu, 13 May 2004 13:30:04 -0500, Mike Vanecek wrote: > Uhm, why are the kernels being excluded? Because it's also up2date's default behaviour on Red Hat Linux 9. > Why is it when one does a yum list, all the mysql rpms are not listed even > though they are on the server (both at download.fedora.us and mirrors.kernel.org)? What did you enter? From jgiglio at smythco.com Thu May 13 20:27:50 2004 From: jgiglio at smythco.com (Jason Giglio) Date: Thu, 13 May 2004 16:27:50 -0400 Subject: Kernel updates for QA In-Reply-To: <200405131203.30937.jkeating@j2solutions.net> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <20040513143117.GU960@tirian.magd.ox.ac.uk> <20040513190448.GJ26276@hemi.math.gatech.edu> <200405131203.30937.jkeating@j2solutions.net> Message-ID: <40A3DA46.4050609@smythco.com> Jesse Keating wrote: > Not quite for kernels. We can continue bumping the build version of > kernels, as we know that there will be no more 2.4.20 kernels issued by > Red Hat, and thus there will be no chance of version collision. Are you sure? Didn't Red Hat release a kernel update after EOL once before? What would stop them from doing it again? -Jason From jkeating at j2solutions.net Thu May 13 21:04:27 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 14:04:27 -0700 Subject: Kernel updates for QA In-Reply-To: <40A3DA46.4050609@smythco.com> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405131203.30937.jkeating@j2solutions.net> <40A3DA46.4050609@smythco.com> Message-ID: <200405131404.30562.jkeating@j2solutions.net> On Thursday 13 May 2004 13:27, Jason Giglio wrote: > Are you sure? > > Didn't Red Hat release a kernel update after EOL once before? What > would stop them from doing it again? The one time it was "released" after EOL was because it had already been built, and was going through QA at the time of EOL, so they decided to not waste all the time/effort they had already put in, and go ahead and publish it. We're beyond that point now. Dave, you're not planning on any RH issued updates to 9 are you? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From davej at redhat.com Thu May 13 22:19:42 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 13 May 2004 23:19:42 +0100 Subject: Kernel updates for QA In-Reply-To: <200405131404.30562.jkeating@j2solutions.net> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405131203.30937.jkeating@j2solutions.net> <40A3DA46.4050609@smythco.com> <200405131404.30562.jkeating@j2solutions.net> Message-ID: <20040513221942.GB7602@redhat.com> On Thu, May 13, 2004 at 02:04:27PM -0700, Jesse Keating wrote: Content-Description: signed data > > Didn't Red Hat release a kernel update after EOL once before? What > > would stop them from doing it again? > > The one time it was "released" after EOL was because it had already been > built, and was going through QA at the time of EOL, so they decided to > not waste all the time/effort they had already put in, and go ahead and > publish it. Correct. > We're beyond that point now. Dave, you're not planning on > any RH issued updates to 9 are you? Also correct, and the only stuff I had pending for RHL9 at the time of EOL you guys have now picked up. Dave From fedoraleg_form at mm-vanecek.cc Thu May 13 23:10:36 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 18:10:36 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040513211946.709cd035.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> <20040513151414.M95390@mm-vanecek.cc> <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> <20040513183930.M22910@mm-vanecek.cc> <20040513211946.709cd035.fedora@wir-sind-cool.org> Message-ID: <20040513222132.M62883@mm-vanecek.cc> On Thu, 13 May 2004 21:19:46 +0200, Michael Schwendt wrote > On Thu, 13 May 2004 13:59:02 -0500, Mike Vanecek wrote: > > > I took a look at > > > > http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/stable/RPMS/. > > > > Were those packages created for RH 9 or for Fedora XX? I thought all the > > fedora stuff was to support the fedora core? However, the numbering on the > > packages could lead one to think that they are created for RH 9. > > *Please* take a look at the main page of http://fedora.us and what > it says near the top. http://fedora.us was using the name "fedora" _before_ > the Fedora Project. It started as "Fedora Linux" an add-ons project > for Red Hat Linux. http://www.fedora.us/fedora-merge.html What confused me was at http://www.fedora.us/wiki/FedoraHOWTO where it says, "Warning: fedora.us packages are designed and tested to work smoothly with only Red Hat Linux, *Fedora Core* and other fedora.us packages. Please read RepositoryMixingProblems to understand the compatibility problems of mixing repositories." I missed the Red Hat Linux part. However, for those that might be following this thread and a new to fedora, if one goes to the channels page, http://www.fedora.us/wiki/FedoraChannels, one finds the fedora.us for Red Hat Linux 8.0 and 9 channel table. It may be of use to add a link to those tables on the fedoralegacy pages. > Let's take a closer look at your URL from above (I think there's > a table somewhere explaining the structure, too): http://www.fedora.us/wiki/FedoraChannels Channel Name Description Base Distribution os packages from the original distribution updates updates from Red Hat + updates from FedoraLegacy updates-testing updates from FedoraLegacy currently in testing before publication Extras (add-ons) stable add-ons believed to be stable and wont interfere with other software testing add-ons with known defects or otherwise unproven unstable add-ons with severe known defects or that may interfere with other software Legacy (add-ons) legacy minimal support tools for Legacy servers > > http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/stable/RPMS/. > > http://mirrors.kernel.org/ > => this is a server mirroring several other serves > > http://mirrors.kernel.org/fedora.us/ > => this is a mirror of http://download.fedora.us > > http://mirrors.kernel.org/fedora.us/fedora/ > => this second "fedora" directory has nothing to do with "Fedora > Core" => it is just a top directory at the master site > > http://mirrors.kernel.org/fedora.us/fedora/redhat/ > => this is the root directory of the add-ons for Red Hat Linux > > The root directory of the add-ons for Fedora Core would be: > http://mirrors.kernel.org/fedora.us/fedora/fedora/ > > http://mirrors.kernel.org/fedora.us/fedora/redhat/9/ > => this is the root of the add-ons for Red Hat Linux 9 OK, I see how it fits together http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/ gets us to RPMS.os/ 01-Apr-2003 10:55 - RPMS.stable/ 11-May-2004 12:33 - RPMS.testing/ 08-May-2004 02:19 - RPMS.unstable/ 02-Jan-2004 01:49 - RPMS.updates-testing/ 03-May-2004 15:27 - RPMS.updates/ > In it you find > > RPMS.os : Red Hat Linux 9 > RPMS.updates : Red Hat Linux 9 Errata > + Fedora Legacy Updates for Red Hat > Linux 9 > > RPMS.updates-testing : -not used with Red Hat Linux - > > RPMS.stable : Extras for Red Hat Linux 9 > RPMS.testing : Extras for Red Hat Linux 9 > RPMS.unstable : Extras for Red Hat Linux 9 > > and the same for source rpms. Your explanation is much clearer than the table alone. Then that must mean that http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/ os/ 01-Apr-2003 02:10 - stable/ 12-May-2004 08:53 - testing/ 12-May-2004 08:53 - unstable/ 12-May-2004 08:53 - updates/ 05-May-2004 03:01 - is the same thing, but in yum format. > > In any event, I think I will leave them out for a while until I get a little > > better feel for fedora-legacy. I noticed that the rpms for chkrootkit and > > leafnode are not current. I suspect that will probably be the case for the > > extras I have installed for original sources. > > leafnode : 1.9.53 is in the publish queue > chkrootkit : 0.43 is latest release My mistake on chkrootkit. Somehow I have release 1 instead of 0 installed on my system. I do not remember what or why. Maybe something discussed on the chkrootkit mailing list. Leafnode 1.9.54.rc2 is already out. The version may change before it gets out of the publish queue. Thank you for your patience and very useful comments. From fedoraleg_form at mm-vanecek.cc Thu May 13 23:42:06 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 18:42:06 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040513211949.790c4032.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> Message-ID: <20040513231352.M83785@mm-vanecek.cc> On Thu, 13 May 2004 21:19:49 +0200, Michael Schwendt wrote > On Thu, 13 May 2004 13:30:04 -0500, Mike Vanecek wrote: > > > Uhm, why are the kernels being excluded? > > Because it's also up2date's default behaviour on Red Hat Linux 9. > > > Why is it when one does a yum list, all the mysql rpms are not listed even > > though they are on the server (both at download.fedora.us and mirrors.kernel.org)? > > What did you enter? First, http://download.fedoralegacy.org/redhat/9/os/i386/ has mysql-3.23.54a-11.i386.rpm 24-Feb-2003 01:38 5.0M mysql-devel-3.23.54a-11.i386.rpm 24-Feb-2003 01:38 566K mysql-server-3.23.54a-11.i386.rpm 24-Feb-2003 01:38 1.1M and http://mirrors.kernel.org/fedora.us/fedora/redhat/9/i386/yum/os/RPMS/ mysql-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 5.0M mysql-devel-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 566K mysql-server-3.23.54a-11.i386.rpm 23-Feb-2003 22:38 1.1M ditto on both for these too: mod_auth_mysql-1.11-12.i386.rpm 23-Feb-2003 22:37 11K php-mysql-4.2.2-17.i386.rpm 25-Feb-2003 07:20 37K perl-DBD-MySQL-2.1021-3.i386.rpm 23-Feb-2003 22:44 180K However, they do not show up with yum list: # yum list | grep -i mysql MySQL-python i386 0.9.1-6 redhat-os qt-MySQL i386 1:3.1.1-6 redhat-os ditto yum info, yum list updates, yum list extras, and so on. As you can see, I do have several mysql packages installed: # yum list installed | grep -i mysql libdbi-dbd-mysql i386 0.6.5-5 db mod_auth_mysql i386 1.11-12 db mysql i386 3.23.58-1.9 db mysql-devel i386 3.23.58-1.9 db mysql-server i386 3.23.58-1.9 db perl-DBD-MySQL i386 2.1021-3 db php-mysql i386 4.2.2-17.2 db My yum.conf is [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 exclude=kernel* [redhat-os] name=Red Hat Linux $releasever ($basearch) baseurl= http://mirrors.kernel.org/fedora.us/fedora/redhat/$releasever/$basearch/yum/os/ gpgcheck=1 failovermethod=priority [redhat-updates] name=Red Hat Linux $releasever ($basearch) updates baseurl= http://mirrors.kernel.org/fedora.us/fedora/redhat/$releasever/$basearch/yum/updates/ gpgcheck=1 failovermethod=priority At what else should I look? From jkeating at j2solutions.net Thu May 13 23:38:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 16:38:42 -0700 Subject: RH9 user - what should I do? In-Reply-To: <20040513222132.M62883@mm-vanecek.cc> References: <20040513211946.709cd035.fedora@wir-sind-cool.org> <20040513222132.M62883@mm-vanecek.cc> Message-ID: <200405131638.45120.jkeating@j2solutions.net> On Thursday 13 May 2004 16:10, Mike Vanecek wrote: > I missed the Red Hat Linux part. However, for those that might be > following this thread and a new to fedora, if one goes to the > channels page, http://www.fedora.us/wiki/FedoraChannels, one finds > the fedora.us for Red Hat Linux 8.0 and 9 channel table. It may be of > use to add a link to those tables on the fedoralegacy pages. In the very near future, we'll have Fedora Legacy built yum/apt packages for 8.0 and 9, that include config files that ONLY point to our stuff, not Fedora.us's stuff. This will save a lot of confusion. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at wir-sind-cool.org Thu May 13 23:45:25 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 14 May 2004 01:45:25 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513222132.M62883@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <40A2EA2F.9060406@bellsouth.net> <20040513151414.M95390@mm-vanecek.cc> <20040513190418.4aeb8d32.fedora@wir-sind-cool.org> <20040513183930.M22910@mm-vanecek.cc> <20040513211946.709cd035.fedora@wir-sind-cool.org> <20040513222132.M62883@mm-vanecek.cc> Message-ID: <20040514014525.1a737fa2.fedora@wir-sind-cool.org> On Thu, 13 May 2004 18:10:36 -0500, Mike Vanecek wrote: > Leafnode 1.9.54.rc2 is already out. The version may change before it gets out > of the publish queue. FYI: 1.9.52 was "vetod" by the leafnode maintainer with the comment "please do not package 1.9.52, authentication and texpire bugs were reported. The authentication bug is confirmed as fixed in 1.9.53.rc6, the texpire bug is fixed as well, but pending feedback from the reporter." although it might have worked well for many users as usual. Since leafnode is updated frequently and those updates have introduced new bugs several times before, it's better to be more careful and not publish the most recent release quickly. From jkeating at j2solutions.net Thu May 13 23:57:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 16:57:48 -0700 Subject: RH9 user - what should I do? In-Reply-To: <20040513231352.M83785@mm-vanecek.cc> References: <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> Message-ID: <200405131657.48495.jkeating@j2solutions.net> On Thursday 13 May 2004 16:42, Mike Vanecek wrote: > # yum list | grep -i mysql > MySQL-python i386 0.9.1-6 redhat-os > qt-MySQL i386 1:3.1.1-6 redhat-os > > ditto yum info, yum list updates, yum list extras, and so on. > > As you can see, I do have several mysql packages installed: > > # yum list installed | grep -i mysql > libdbi-dbd-mysql i386 0.6.5-5 db > mod_auth_mysql i386 1.11-12 db > mysql i386 3.23.58-1.9 db > mysql-devel i386 3.23.58-1.9 db > mysql-server i386 3.23.58-1.9 db > perl-DBD-MySQL i386 2.1021-3 db > php-mysql i386 4.2.2-17.2 db I see nothing wrong here. Your installed mysql is newer than what is available from the repot. Try: yum provides mysql -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedoraleg_form at mm-vanecek.cc Fri May 14 00:12:55 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 19:12:55 -0500 Subject: RH9 user - what should I do? In-Reply-To: <200405131657.48495.jkeating@j2solutions.net> References: <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <200405131657.48495.jkeating@j2solutions.net> Message-ID: <20040514000745.M73438@mm-vanecek.cc> On Thu, 13 May 2004 16:57:48 -0700, Jesse Keating wrote > On Thursday 13 May 2004 16:42, Mike Vanecek wrote: > > # yum list | grep -i mysql > > MySQL-python i386 0.9.1-6 redhat-os > > qt-MySQL i386 1:3.1.1-6 redhat-os > > > > ditto yum info, yum list updates, yum list extras, and so on. > > > > As you can see, I do have several mysql packages installed: > > > > # yum list installed | grep -i mysql > > libdbi-dbd-mysql i386 0.6.5-5 db > > mod_auth_mysql i386 1.11-12 db > > mysql i386 3.23.58-1.9 db > > mysql-devel i386 3.23.58-1.9 db > > mysql-server i386 3.23.58-1.9 db > > perl-DBD-MySQL i386 2.1021-3 db > > php-mysql i386 4.2.2-17.2 db > > I see nothing wrong here. Your installed mysql is newer than what > is available from the repot. Yes, but I thought that yum list (or yum list available) would list everything, not just what was needed for update (yum check-update). # yum provides mysql Gathering header information file(s) from server(s) Server: Fedora Linux / stable for Red Hat Linux 9 (i386) Server: Macromedia Flash Player for Red Hat Linux 9 Server: Red Hat Linux 9 (i386) Server: Red Hat Linux 9 (i386) updates Finding updated packages Downloading needed headers Looking in available packages for a providing package No packages found Looking in installed packages for a providing package Installed package: mysql provides mysql 1 results returned No matter what I try, yum is not able to find that the repo has mysql packages. > > Try: yum provides mysql > > -- > 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 fedora at wir-sind-cool.org Fri May 14 00:16:42 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 14 May 2004 02:16:42 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040513231352.M83785@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> Message-ID: <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> On Thu, 13 May 2004 18:42:06 -0500, Mike Vanecek wrote: > > > Why is it when one does a yum list, all the mysql rpms are not listed even > > > though they are on the server (both at download.fedora.us and > mirrors.kernel.org)? > > > > What did you enter? > # yum list | grep -i mysql Use yum list 'mysql*' or even yum list '*mysql*' From fedoraleg_form at mm-vanecek.cc Fri May 14 00:23:55 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Thu, 13 May 2004 19:23:55 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> Message-ID: <20040514002206.M55930@mm-vanecek.cc> On Fri, 14 May 2004 02:16:42 +0200, Michael Schwendt wrote > On Thu, 13 May 2004 18:42:06 -0500, Mike Vanecek wrote: > > > > > Why is it when one does a yum list, all the mysql rpms are not listed even > > > > though they are on the server (both at download.fedora.us and > > mirrors.kernel.org)? > > > > > > What did you enter? > > > # yum list | grep -i mysql > > Use > > yum list 'mysql*' > > or even > > yum list '*mysql*' Nope. It only finds the ones installed, but not in the repo: # yum list '*mysql*' or *mysql* (w/o the quotes) Gathering header information file(s) from server(s) Server: Fedora Linux / stable for Red Hat Linux 9 (i386) Server: Macromedia Flash Player for Red Hat Linux 9 Server: Red Hat Linux 9 (i386) Server: Red Hat Linux 9 (i386) updates Finding updated packages Downloading needed headers Looking in Available Packages: Name Arch Version Repo -------------------------------------------------------------------------------- Looking in Installed Packages: Name Arch Version Repo -------------------------------------------------------------------------------- libdbi-dbd-mysql i386 0.6.5-5 db mod_auth_mysql i386 1.11-12 db mysql i386 3.23.58-1.9 db mysql-devel i386 3.23.58-1.9 db mysql-server i386 3.23.58-1.9 db php-mysql i386 4.2.2-17.2 db It does not find them as available packages. From jkeating at j2solutions.net Fri May 14 00:30:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 17:30:41 -0700 Subject: RH9 user - what should I do? In-Reply-To: <20040514002206.M55930@mm-vanecek.cc> References: <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> <20040514002206.M55930@mm-vanecek.cc> Message-ID: <200405131730.44681.jkeating@j2solutions.net> On Thursday 13 May 2004 17:23, Mike Vanecek wrote: > Nope. It only finds the ones installed, but not in the repo: > > # yum list '*mysql*' or *mysql* (w/o the quotes) yum list seems to NOT show older packages. Even though the older one is in the repo, yum will not list 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at wir-sind-cool.org Fri May 14 00:43:19 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 14 May 2004 02:43:19 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040514002206.M55930@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> <20040514002206.M55930@mm-vanecek.cc> Message-ID: <20040514024319.1a6c4696.fedora@wir-sind-cool.org> On Thu, 13 May 2004 19:23:55 -0500, Mike Vanecek wrote: > > Use > > > > yum list 'mysql*' > > > > or even > > > > yum list '*mysql*' > > Nope. It only finds the ones installed, but not in the repo: According to the manual, that's correct. You can't downgrade packages with Yum anyway, so only what's available or installed does matter. > # yum list '*mysql*' or *mysql* (w/o the quotes) > > Looking in Installed Packages: > Name Arch Version Repo > -------------------------------------------------------------------------------- > libdbi-dbd-mysql i386 0.6.5-5 db > mod_auth_mysql i386 1.11-12 db > mysql i386 3.23.58-1.9 db > mysql-devel i386 3.23.58-1.9 db > mysql-server i386 3.23.58-1.9 db > php-mysql i386 4.2.2-17.2 db > > It does not find them as available packages. If you uninstalled them, they would become available again. ;) yum search '*mysql*' is somewhat rough, but searches _all_ packages. From fedora at wir-sind-cool.org Fri May 14 00:45:25 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 14 May 2004 02:45:25 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040514002206.M55930@mm-vanecek.cc> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> <20040514002206.M55930@mm-vanecek.cc> Message-ID: <20040514024525.1a70af4c.fedora@wir-sind-cool.org> On Thu, 13 May 2004 19:23:55 -0500, Mike Vanecek wrote: > > yum list '*mysql*' > > Nope. It only finds the ones installed, but not in the repo: And if you have doubts that *mysql* is available in the repo, yum list extras to check your installation. From akopps at LS.Berkeley.EDU Fri May 14 00:58:16 2004 From: akopps at LS.Berkeley.EDU (Akop Pogosian) Date: Thu, 13 May 2004 17:58:16 -0700 Subject: Quetion about legacy support for FC1 Message-ID: <20040514005816.GA7892@ls.berkeley.edu> I am trying to find out what will be like the transition to using Fedora Legacy updates once the Fedora project will stop providing updates for FC1. Will we have to change our apt/yum sources lists? We'll we have to import new GPG keys? -akop From skvidal at phy.duke.edu Fri May 14 01:58:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 May 2004 21:58:05 -0400 Subject: RH9 user - what should I do? In-Reply-To: <20040514000745.M73438@mm-vanecek.cc> References: <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <200405131657.48495.jkeating@j2solutions.net> <20040514000745.M73438@mm-vanecek.cc> Message-ID: <1084499885.16881.3.camel@binkley> On Thu, 2004-05-13 at 19:12 -0500, Mike Vanecek wrote: > On Thu, 13 May 2004 16:57:48 -0700, Jesse Keating wrote > > On Thursday 13 May 2004 16:42, Mike Vanecek wrote: > > > # yum list | grep -i mysql > > > MySQL-python i386 0.9.1-6 redhat-os > > > qt-MySQL i386 1:3.1.1-6 redhat-os > > > > > > ditto yum info, yum list updates, yum list extras, and so on. > > > I didn't catch this earlier - what version of yum is this? -sv From jkeating at j2solutions.net Fri May 14 05:38:43 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 May 2004 22:38:43 -0700 Subject: Quetion about legacy support for FC1 In-Reply-To: <20040514005816.GA7892@ls.berkeley.edu> References: <20040514005816.GA7892@ls.berkeley.edu> Message-ID: <200405132238.43781.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 May 2004 17:58, Akop Pogosian wrote: > I am trying to find out what will be like the transition to using > Fedora Legacy updates once the Fedora project will stop providing > updates for FC1. Will we have to change our apt/yum sources lists? > We'll we have to import new GPG keys? Yes, and yes. I'm going to try to work with Red Hat and perhaps issue one last yum update for FC1 before it gets EOLed that will contain config files that point to Fedora Legacy servers. Not sure how well they will take to this idea, I haven't floated it by them yet. - -- 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) iD8DBQFApFtj4v2HLvE71NURAsi0AKCm/hmKvX5jyNUUyj3V6Q8Y27ywRgCfYk0B 6ZZMJJna8BkMAVFnQILLzzc= =d1L5 -----END PGP SIGNATURE----- From ipesin at n-ix.com.ua Fri May 14 06:04:59 2004 From: ipesin at n-ix.com.ua (Ivan Pesin) Date: Fri, 14 May 2004 09:04:59 +0300 Subject: Quetion about legacy support for FC1 In-Reply-To: <200405132238.43781.jkeating@j2solutions.net> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> Message-ID: <40A4618B.6020201@n-ix.com.ua> Jesse Keating wrote: > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > one last yum update for FC1 before it gets EOLed that will contain > config files that point to Fedora Legacy servers. Not sure how well > they will take to this idea, I haven't floated it by them yet. I think it is really good idea! -- Ivan Pesin mailto:ipesin at n-ix.com.ua System administrator N-iX Newcomp Computersysteme GmbH http://www.n-ix.com From skvidal at phy.duke.edu Fri May 14 06:13:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 14 May 2004 02:13:35 -0400 Subject: Quetion about legacy support for FC1 In-Reply-To: <40A4618B.6020201@n-ix.com.ua> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> <40A4618B.6020201@n-ix.com.ua> Message-ID: <1084515214.16881.22.camel@binkley> On Fri, 2004-05-14 at 09:04 +0300, Ivan Pesin wrote: > > Jesse Keating wrote: > > > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > > one last yum update for FC1 before it gets EOLed that will contain > > config files that point to Fedora Legacy servers. Not sure how well > > they will take to this idea, I haven't floated it by them yet. > > I think it is really good idea! > I think, unless people have not modified their yum.conf at all, it won't work. yum.conf is marked config(noreplace) last time I checked. so a new yum will just create a yum.rpmnew -sv From dennis at ausil.us Fri May 14 07:47:47 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 14 May 2004 17:47:47 +1000 Subject: Quetion about legacy support for FC1 In-Reply-To: <1084515214.16881.22.camel@binkley> References: <20040514005816.GA7892@ls.berkeley.edu> <40A4618B.6020201@n-ix.com.ua> <1084515214.16881.22.camel@binkley> Message-ID: <200405141747.47583.dennis@ausil.us> Once upon a time Friday 14 May 2004 4:13 pm, seth vidal wrote: > On Fri, 2004-05-14 at 09:04 +0300, Ivan Pesin wrote: > > Jesse Keating wrote: > > > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > > > one last yum update for FC1 before it gets EOLed that will contain > > > config files that point to Fedora Legacy servers. Not sure how well > > > they will take to this idea, I haven't floated it by them yet. > > > > I think it is really good idea! > > I think, unless people have not modified their yum.conf at all, it won't > work. > > yum.conf is marked config(noreplace) last time I checked. > > so a new yum will just create a yum.rpmnew > > -sv I also think its bad i dont use yum directly much but i do use up2date which would need an update as well. but the first thing i do is point up2date sources to the closest mirror. so if you do get an update for yum aand up2date and you get it to overide my settings ill be mad. what would be nice is a script to add to apt, yum and up2date the neccesary repositories for fedoralegacy. with options to setup to the closest mirror. Which brings me to something ive been thinking about for awhile a dns system for mirrors setup master mirror and have mirrors mirror from there or just go from cuurent master sites but get them to be consitent with what they mirror where i have a domain for it fedoramirror.net im in Australia so i could go with a tree like this server au.fedoramirror.net /pub/fedora/core//RPMS/ /pub/fedora/core//SRPMS/ /pub/fedora/extras//RPMS/ /pub/fedora/extras//SRPMS/ /pub/fedora/legacy//RPMS/ /pub/fedora/legacy//SRPMS/ /pub/fedora/addons/freshrpms//RPMS/ /pub/fedora/addons/freshrpms//SRPMS/ /pub/fedora/addons/livna//RPMS/ /pub/fedora/addons/livna//SRPMS/ /pub/fedora/addons/dag//RPMS/ /pub/fedora/addons/dag//SRPMS/ something like that say theres a mirror in boston we could provide dns of ma.us.fedoramirror.net that way users would be able to use a consistent naming scheme mirrors could leave off addons or parts of addons or extras or legacy as they wanted but prefferablly they would have all the rpms and maybe srpms. well its an idea Dennis p.s ill have to propose this in a few other places as well but please email me your ideas. From Axel.Thimm at ATrpms.net Fri May 14 08:37:10 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 14 May 2004 10:37:10 +0200 Subject: Quetion about legacy support for FC1 In-Reply-To: <1084515214.16881.22.camel@binkley> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> <40A4618B.6020201@n-ix.com.ua> <1084515214.16881.22.camel@binkley> Message-ID: <20040514083710.GE17038@neu.nirvana> On Fri, May 14, 2004 at 02:13:35AM -0400, seth vidal wrote: > On Fri, 2004-05-14 at 09:04 +0300, Ivan Pesin wrote: > > Jesse Keating wrote: > > > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > > > one last yum update for FC1 before it gets EOLed that will contain > > > config files that point to Fedora Legacy servers. Not sure how well > > > they will take to this idea, I haven't floated it by them yet. > > > > I think it is really good idea! > > I think, unless people have not modified their yum.conf at all, it won't > work. > > yum.conf is marked config(noreplace) last time I checked. > > so a new yum will just create a yum.rpmnew Seth is right, almost noone leaves these config files unmodified :) But how about paving the path at the very birth of a release by having the fedoralegacy entries added at the very beginning of the life cycle of FC pointing to an empty folder? People will add repos and so on, and the legacy pointer will wait for fedoralegacy to populate the matching folder at EOL time, e.g. # The following repo will be populated when Fedora Core 2 reaches EOL, # which will be approximately in # see fedoralegacy.org for details. [legacyupdates] name=Fedora Core $releasever legacy updates baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch (and fedoralegacy will have free monitoring/statistics of Fedora deployment ;) -- 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 mikej at primatech.com Fri May 14 13:49:58 2004 From: mikej at primatech.com (Mike Jones) Date: Fri, 14 May 2004 09:49:58 -0400 Subject: Quetion about legacy support for FC1 In-Reply-To: <200405132238.43781.jkeating@j2solutions.net> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> Message-ID: <1084542597.14445.15.camel@mikej.col.primatech.com> On Fri, 2004-05-14 at 01:38, Jesse Keating wrote: > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > one last yum update for FC1 before it gets EOLed that will contain > config files that point to Fedora Legacy servers. Not sure how well > they will take to this idea, I haven't floated it by them yet. Maybe a better solution would be for them to add the legacy updates to their site. This would not require users of FC1 to change anything about how they update. This would also imply that all the Fedora mirrors would pick up the updates and lower the load the legacy servers. The only problem with this would be that we would either have to use the Fedora PGP key or users would have to add our PGP key, but I think that would be an easier problem to solve. Thanks, -- Mike Jones Network & Software Engineer Primatech Inc. Phone: 614-841-9800 x 129 Fax: 614-841-9805 Email: mikej at primatech.com Address: Primatech Inc. 50 Northwoods Blvd. Columbus, Ohio 43235 -------------- 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 dudek at buffalo.edu Fri May 14 13:50:47 2004 From: dudek at buffalo.edu (David Dudek) Date: Fri, 14 May 2004 09:50:47 -0400 (EDT) Subject: fedoralegacy.org download and RHEN Proxy In-Reply-To: <20040514083723.AD06473A5F@hormel.redhat.com> References: <20040514083723.AD06473A5F@hormel.redhat.com> Message-ID: At the University at Buffalo, we purchaced Red Hat Enterprise Network (RHEN) Proxy in August 2003 for the purpose of keeping Red Hat Linux 9 machines up to date. We are migrating to Enterprise Workstation 3 for the Fall semester. During this transition period, I would like to load the fedoralegacy.org updates into our custom child channel of the Red Hat Linux 9 base channel on RHEN. Does anyone know of a good way to do this automagically? I'm assuming that I need to use rsync, but I've never mirrored a site before, so I don't know how to go about doing it. Once I mirror the site, I think I will need some kind of script that will load the files into the channel. Any pointers would be greatly appreciated. -- David Thomas Dudek http://www.buffalo.edu/~dudek/ From harri.haataja at smilehouse.com Fri May 14 13:55:39 2004 From: harri.haataja at smilehouse.com (Harri Haataja) Date: Fri, 14 May 2004 16:55:39 +0300 Subject: apt or yum? In-Reply-To: <40A1EE33.6010700@users.sourceforge.net> References: <1084353230.2314.1176.camel@khc09.samurajdata.se> <40A1EE33.6010700@users.sourceforge.net> Message-ID: <20040514135539.GA27708@mail1.smilehouse.com> On Wed, May 12, 2004 at 10:28:19AM +0100, WipeOut wrote: > Markus Hakansson wrote: > > >Are there any arguments for which of these to chose? > >As I understand it, yum has been chosen as 'the official' > >up2date-replacement for Fedora Legacy (and Fedora Core), is that > >correct? > >Are the yum and apt repositories updated at the same time, or is one > >the 'master' so the other might lag behind? > >Personally, I like apt better for its speed but I feel that I don't > >really know if yum has any technical advantages. > >Could anybody shed any light on this? > This has been discussed quite a lot with people defending their own > choice quite strongly.. > > I would say use which ever one you are comfortable with.. Personally I > use YUM because I found it simple to use and it did what I needed, so > I have never tried APT.. > > Youe question is like many in the Linux and OSS world.. similar examples > are My answers which I believe also show another thing about this kind of questions: > "Should I use Gnome or KDE?" No. > "Which Distro is best?" Mu. > "Should I > use Netscape, Mozilla or Konqueror?" No. > These all have the same answer, which ever you prefer.. Quite so. It is great to have freedom of choice, but it does complicate things if there's no clear default and you haven't already become familiar with any of the options somehow. One thing that could be mentioned in these is that, AFAIK, yum is rpm specific while apt-get is largely common with the dpkg version. This can tip the choice either way, of course (unity and legacy opinoins). From dom at earth.li Fri May 14 14:15:50 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 14 May 2004 15:15:50 +0100 Subject: Kernel updates for QA In-Reply-To: <200405130922.35937.jkeating@j2solutions.net> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405130829.20871.jkeating@j2solutions.net> <20040513160936.GX960@tirian.magd.ox.ac.uk> <200405130922.35937.jkeating@j2solutions.net> Message-ID: <20040514141550.GD960@tirian.magd.ox.ac.uk> On Thu, May 13, 2004 at 09:22:33AM -0700, Jesse Keating wrote: > Ah, if it's in mainline, that makes me feel a bit better. Go ahead and > put the patch in and we'll test it during QA phases. Please gather as > many nforce2 users you can across 7.2/7.3/8.0/9 to test this. Thanks! New packages up for QA. Nforce2 users especially take note! Cheers, Dominic. From guallar at easternrad.com Fri May 14 14:24:59 2004 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Fri, 14 May 2004 10:24:59 -0400 Subject: fedoralegacy.org download and RHEN Proxy In-Reply-To: References: <20040514083723.AD06473A5F@hormel.redhat.com> Message-ID: <200405141025.03161.guallar@easternrad.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 14 May 2004 09:50 am, David Dudek wrote: > I would like to load the > fedoralegacy.org updates into our custom child channel of the Red Hat > Linux 9 base channel on RHEN. Does anyone know of a good way to do this > automagically? I'm assuming that I need to use rsync, but I've never > mirrored a site before, so I don't know how to go about doing it. Once I > mirror the site, I think I will need some kind of script that will load > the files into the channel. Any pointers would be greatly appreciated. You can also use "mirrordir". This is perfect for when there's no rsync support in a ftp site. You can also create a cronjob for a script with mirrordir. Regards, Josep - -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and Network Administration http://www.easternrad.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFApNa+SGQa4/zQ9e8RAkExAJ96tb/UdC33kjreAlldCRxtOLgsgACcDTKS IKIF/N9Cf2YuEVHjyYhoYFU= =i+id -----END PGP SIGNATURE----- From villegas at math.gatech.edu Fri May 14 14:28:25 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 14 May 2004 10:28:25 -0400 Subject: Quetion about legacy support for FC1 In-Reply-To: <200405132238.43781.jkeating@j2solutions.net> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> Message-ID: <20040514142825.GQ26276@hemi.math.gatech.edu> On Thu, May 13, 2004 at 10:38:43PM -0700, Jesse Keating wrote: > Yes, and yes. I'm going to try to work with Red Hat and perhaps issue > one last yum update for FC1 before it gets EOLed that will contain > config files that point to Fedora Legacy servers. Not sure how well > they will take to this idea, I haven't floated it by them yet. I've already read several replies on this thread, and although I can see the benefits, I beleive is a bad idea. People should not transition to FL without noticing. I believe that the fact that they see an "official EOL" by the FC project, and an easy transition to FL is important and should not be hidden, especially considering that there will still be a "real EOL" when FL legacy stops supporting that version. It is important that end users of the OS are aware of this things and take them into consideration in their deployments and when having some spare time/hardware/bandwith to contribute back. I would personally feel very suspicious of anything that either tries to mess around with my configs or tries to add unnecessary "authorized" GPG keys or something else... Especially if I'm unaware of the reasons for this things. Carlos From jkeating at j2solutions.net Fri May 14 14:49:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 May 2004 07:49:44 -0700 Subject: Quetion about legacy support for FC1 In-Reply-To: <1084515214.16881.22.camel@binkley> References: <20040514005816.GA7892@ls.berkeley.edu> <40A4618B.6020201@n-ix.com.ua> <1084515214.16881.22.camel@binkley> Message-ID: <200405140749.44911.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 May 2004 23:13, seth vidal wrote: > I think, unless people have not modified their yum.conf at all, it > won't work. > > yum.conf is marked config(noreplace) last time I checked. > > so a new yum will just create a yum.rpmnew Which is fine by me, all it takes us to do is say "merge in changes from your .rpmnew file". - -- 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) iD8DBQFApNyI4v2HLvE71NURAkrZAJ9DMDedyWvOiL+J2n7dqbYzOaljUACgijIF xGg2tIgCzBKyJSdNCHbh7V4= =qV7d -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri May 14 14:52:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 May 2004 07:52:00 -0700 Subject: Quetion about legacy support for FC1 In-Reply-To: <200405141747.47583.dennis@ausil.us> References: <20040514005816.GA7892@ls.berkeley.edu> <1084515214.16881.22.camel@binkley> <200405141747.47583.dennis@ausil.us> Message-ID: <200405140752.00795.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 14 May 2004 00:47, Dennis Gilmore wrote: > ? I also think its bad i dont use yum directly much ?but i do use > up2date ? which would need an update as well. ?but the first thing i > do is point up2date sources to the closest mirror. so if you do get > an update for yum aand up2date ?and you get it to overide my settings > ill be mad. ?what would be nice is a script to add to apt, yum and > up2date the neccesary repositories for fedoralegacy. ?with options to > setup to the closest mirror. Updates will not overwrite modified config files. The new config file will be there with a .rpmnew file extension, and you can merge in the changes on your own. - -- 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) iD8DBQFApN0Q4v2HLvE71NURAtkWAJ4smbG9AawwfXZ+Swp7YlZ/ekrH9ACgtVYH Ki9tGUaFnN17+1iXIbIRC5w= =PQqx -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri May 14 14:53:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 May 2004 07:53:32 -0700 Subject: Quetion about legacy support for FC1 In-Reply-To: <20040514083710.GE17038@neu.nirvana> References: <20040514005816.GA7892@ls.berkeley.edu> <1084515214.16881.22.camel@binkley> <20040514083710.GE17038@neu.nirvana> Message-ID: <200405140753.32944.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 14 May 2004 01:37, Axel Thimm wrote: > Seth is right, almost noone leaves these config files unmodified :) The goal isn't necessarily to have it dumped into their config automagically, just make it easier for them. Having the config file there, even in .rpmnew is better than nothing. > But how about paving the path at the very birth of a release by > having the fedoralegacy entries added at the very beginning of the > life cycle of FC pointing to an empty folder? ?People will add > repos and so on, and the legacy pointer will wait for fedoralegacy to > populate the matching folder at EOL time, e.g. > > # The following repo will be populated when Fedora Core 2 reaches > EOL, # which will be approximately in > # see fedoralegacy.org for details. > [legacyupdates] > name=Fedora Core $releasever legacy updates > baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$ >basearch > > (and fedoralegacy will have free monitoring/statistics of Fedora > deployment ;) That is a very interesting idea! I will certainly think this over. - -- 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) iD8DBQFApN1s4v2HLvE71NURAv7tAKCJ6woSS1WjkKQnrlEiDpXyXoQp+gCgg8c9 Qseb65DW/zStgOUgOfArgRc= =kwhX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri May 14 14:55:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 May 2004 07:55:07 -0700 Subject: Quetion about legacy support for FC1 In-Reply-To: <1084542597.14445.15.camel@mikej.col.primatech.com> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> <1084542597.14445.15.camel@mikej.col.primatech.com> Message-ID: <200405140755.07122.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 14 May 2004 06:49, Mike Jones wrote: > Maybe a better solution would be for them to add the legacy updates > to their site. ?This would not require users of FC1 to change > anything about how they update. ?This would also imply that all the > Fedora mirrors would pick up the updates and lower the load the > legacy servers. > > The only problem with this would be that we would either have to use > the Fedora PGP key or users would have to add our PGP key, but I > think that would be an easier problem to solve. Not going to happen. This gives the idea that the updates came from Red Hat, not from Fedora Legacy. Red Hat wants to make sure there is a clear idea that Fedora Legacy packages are NOT Red Hat packages. Our mirroring system is growing daily and our load isn't that bad on the servers. We need more packagers and QA people than anything. - -- 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) iD8DBQFApN3L4v2HLvE71NURArgkAKCLyNyDOIyHfeDDS4klTwzQOqhjnwCeN9qq 8uEM+CNFj9IbVuMgWEEAPLU= =xUci -----END PGP SIGNATURE----- From linuxuser at pmbenterprises.com Fri May 14 10:45:02 2004 From: linuxuser at pmbenterprises.com (Paul M. Bucalo) Date: Fri, 14 May 2004 06:45:02 -0400 Subject: Quetion about legacy support for FC1 In-Reply-To: <20040514083710.GE17038@neu.nirvana> References: <20040514005816.GA7892@ls.berkeley.edu> <200405132238.43781.jkeating@j2solutions.net> <40A4618B.6020201@n-ix.com.ua> <1084515214.16881.22.camel@binkley> <20040514083710.GE17038@neu.nirvana> Message-ID: <1084531502.4221.11.camel@pmbnote1> On Fri, 2004-05-14 at 04:37, Axel Thimm wrote: > > I think, unless people have not modified their yum.conf at all, it won't > > work. > >=20 > > yum.conf is marked config(noreplace) last time I checked. > >=20 > > so a new yum will just create a yum.rpmnew > > Seth is right, almost noone leaves these config files unmodified :) > > But how about paving the path at the very birth of a release by having > the fedoralegacy entries added at the very beginning of the life cycle > of FC pointing to an empty folder? People will add repos and so on, > and the legacy pointer will wait for fedoralegacy to populate the > matching folder at EOL time, e.g. > > # The following repo will be populated when Fedora Core 2 reaches EOL, > # which will be approximately in > # see fedoralegacy.org for details. > [legacyupdates] > name=3DFedora Core $releasever legacy updates > baseurl=3Dhttp://download.fedoralegacy.org/fedora/$releasever/updates/$base= > arch=20 > > (and fedoralegacy will have free monitoring/statistics of Fedora > deployment ;) > --=20 > Axel.Thimm at ATrpms.net Definitely not a cure-all or sole remedy, but you could post a notice of the existence of FC1 support, when it happens, in the footer generated by the list server. Something like this: -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list Now supporting Fedora Core 1! For more information, see FAQ at: http://www.fedoralegacy.org/about/faq.php I won't argue that not everyone even knows that they receive a list generated footer with each post, but most of us do. ;0) Just a suggestion to allow the list server to do a small part of the support work. Paul From villegas at math.gatech.edu Fri May 14 16:58:30 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 14 May 2004 12:58:30 -0400 Subject: apt or yum? In-Reply-To: <20040514135539.GA27708@mail1.smilehouse.com> References: <1084353230.2314.1176.camel@khc09.samurajdata.se> <40A1EE33.6010700@users.sourceforge.net> <20040514135539.GA27708@mail1.smilehouse.com> Message-ID: <20040514165830.GA3441@math30192.math.gatech.edu> On Fri, May 14, 2004 at 04:55:39PM +0300, Harri Haataja wrote: > Quite so. It is great to have freedom of choice, but it does complicate > things if there's no clear default and you haven't already become > familiar with any of the options somehow. In Fedora Core there is a default: yum, so if you're looking for what's the default and go with it, then that's your answer. On the other hand if you want to check what are your options, study them and choose from there, then the question about having a default suddenly becomes irrelevant... > One thing that could be mentioned in these is that, AFAIK, yum is rpm > specific while apt-get is largely common with the dpkg version. This can > tip the choice either way, of course (unity and legacy opinoins). I think there is a slight confusion there, yum only works with rpm, that's true and has been so since it's beginning, apt-get was originally created by the debian project, and as such worked with dpkg, it was later ported to work with rpms (of course not for debian) and is heavily used by some distros (as their default). I'm not sure how the history of the tools can help you make up your mind... Personally I believe both tools are great, there is really not much of a difference for most people. Carlos PS: I use yum at work, and apt-get (for debian) at home. PS2: one thing I love about apt-get is the "source" command, but not sure if it's available for the rpm version of apt-get, I also heard rumors that it would eventually appear in yum, but I'm not sure what the status of that is. From tzs at tzs.net Fri May 14 17:44:11 2004 From: tzs at tzs.net (Tim Smith) Date: Fri, 14 May 2004 10:44:11 -0700 (PDT) Subject: apt or yum? In-Reply-To: <20040514165830.GA3441@math30192.math.gatech.edu> Message-ID: Both apt and yum are just acting as front-ends to RPM, right? Is there any reason one cannot use both, rather than choosing one? -- --tzs From kelson at speed.net Fri May 14 17:54:46 2004 From: kelson at speed.net (Kelson Vibber) Date: Fri, 14 May 2004 10:54:46 -0700 Subject: apt or yum? In-Reply-To: References: <20040514165830.GA3441@math30192.math.gatech.edu> Message-ID: <6.1.0.6.0.20040514104928.025ffe18@mail.speed.net> At 10:44 AM 5/14/2004, you wrote: >Both apt and yum are just acting as front-ends to RPM, right? Is there >any reason one cannot use both, rather than choosing one? Well, it's easier to set up one tool than two. Other than that, all I can think of is that it's a bit more efficient. If you install packages through apt, yum still has to grab those headers the next time it runs. If you use yum every time, it already grabbed them. That said, on my Fedora Core systems I run both up2date and apt-get - up2date for system updates, and apt-get (usually through synaptic) for FreshRPMs, Dag, ATRPMs, etc., and I use yum on most of the Red Hat systems that are set up to use Fedora Legacy. Kelson Vibber SpeedGate Communications From villegas at math.gatech.edu Fri May 14 18:03:28 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 14 May 2004 14:03:28 -0400 Subject: Kernel updates for QA In-Reply-To: <20040514141550.GD960@tirian.magd.ox.ac.uk> References: <20040507002636.GS960@tirian.magd.ox.ac.uk> <200405130829.20871.jkeating@j2solutions.net> <20040513160936.GX960@tirian.magd.ox.ac.uk> <200405130922.35937.jkeating@j2solutions.net> <20040514141550.GD960@tirian.magd.ox.ac.uk> Message-ID: <20040514180328.GB3441@math30192.math.gatech.edu> On Fri, May 14, 2004 at 03:15:50PM +0100, Dominic Hargreaves wrote: > On Thu, May 13, 2004 at 09:22:33AM -0700, Jesse Keating wrote: > > > Ah, if it's in mainline, that makes me feel a bit better. Go ahead and > > put the patch in and we'll test it during QA phases. Please gather as > > many nforce2 users you can across 7.2/7.3/8.0/9 to test this. Thanks! > > New packages up for QA. Nforce2 users especially take note! I noticed that the keywords are missing on this bug (LEGACY, as well as the version keywords) so I added the LEGACY, QA and version keywords to it. Please verify if there is any other one missing or if I added too many :). I hope to do some QA on this soon. Carlos From fedoraleg_form at mm-vanecek.cc Fri May 14 23:24:37 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Fri, 14 May 2004 18:24:37 -0500 Subject: RH9 user - what should I do? In-Reply-To: <1084499885.16881.3.camel@binkley> References: <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <200405131657.48495.jkeating@j2solutions.net> <20040514000745.M73438@mm-vanecek.cc> <1084499885.16881.3.camel@binkley> Message-ID: <20040514232409.M20740@mm-vanecek.cc> On Thu, 13 May 2004 21:58:05 -0400, seth vidal wrote > On Thu, 2004-05-13 at 19:12 -0500, Mike Vanecek wrote: > > On Thu, 13 May 2004 16:57:48 -0700, Jesse Keating wrote > > > On Thursday 13 May 2004 16:42, Mike Vanecek wrote: > > > > # yum list | grep -i mysql > > > > MySQL-python i386 0.9.1-6 redhat-os > > > > qt-MySQL i386 1:3.1.1-6 redhat-os > > > > > > > > ditto yum info, yum list updates, yum list extras, and so on. > > > > > > I didn't catch this earlier - what version of yum is this? # rpm -q yum yum-2.0.3-0.fdr.1.rh90 From fedoraleg_form at mm-vanecek.cc Fri May 14 23:44:30 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Fri, 14 May 2004 18:44:30 -0500 Subject: RH9 user - what should I do? In-Reply-To: <200405131730.44681.jkeating@j2solutions.net> References: <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> <20040514002206.M55930@mm-vanecek.cc> <200405131730.44681.jkeating@j2solutions.net> Message-ID: <20040514234019.M27127@mm-vanecek.cc> On Thu, 13 May 2004 17:30:41 -0700, Jesse Keating wrote > On Thursday 13 May 2004 17:23, Mike Vanecek wrote: > > Nope. It only finds the ones installed, but not in the repo: > > > > # yum list '*mysql*' or *mysql* (w/o the quotes) > > yum list seems to NOT show older packages. Even though the older > one is in the repo, yum will not list it. Yes, quite. My apologies for being rather thick ... yum list [available] list all packages in the yum repositories available to be installed. If a package is already installed, then it is not available to be installed. As you said, since I already have the latest version installed # rpm -qa | grep mysql mysql-devel-3.23.58-1.9 mysql-server-3.23.58-1.9 mysql-3.23.58-1.9 ftp://updates.redhat.com/9/en/os/i386/ mysql-3.23.58-1.9.i386.rpm 5832 KB 10/08/2003 12:00:00 AM mysql-devel-3.23.58-1.9.i386.rpm 568 KB 10/08/2003 12:00:00 AM mysql-server-3.23.58-1.9.i386.rpm 1098 KB 10/08/2003 12:00:00 AM http://download.fedoralegacy.org/redhat/9/updates/i386/ mysql-3.23.58-1.9.i386.rpm 08-Oct-2003 12:01 5.7M mysql-devel-3.23.58-1.9.i386.rpm 08-Oct-2003 12:01 567K mysql-server-3.23.58-1.9.i386.rpm 08-Oct-2003 12:01 1.1M those packages are not available to be installed by Yum. Thank you for the learning lesson. Maybe I can help others on this topic later on. From fedoraleg_form at mm-vanecek.cc Fri May 14 23:47:47 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Fri, 14 May 2004 18:47:47 -0500 Subject: RH9 user - what should I do? In-Reply-To: <20040514024319.1a6c4696.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> <20040513170246.M7106@mm-vanecek.cc> <20040513191618.6cf56d3d.fedora@wir-sind-cool.org> <20040513173648.M32456@mm-vanecek.cc> <20040513211949.790c4032.fedora@wir-sind-cool.org> <20040513231352.M83785@mm-vanecek.cc> <20040514021642.3b3f8caa.fedora@wir-sind-cool.org> <20040514002206.M55930@mm-vanecek.cc> <20040514024319.1a6c4696.fedora@wir-sind-cool.org> Message-ID: <20040514234545.M17714@mm-vanecek.cc> On Fri, 14 May 2004 02:43:19 +0200, Michael Schwendt wrote > > It does not find them as available packages. > > If you uninstalled them, they would become available again. ;) > > yum search '*mysql*' is somewhat rough, but searches _all_ packages. OK. I guess the version of yum recommended to be installed yum-2.0.3-0.fdr.1.rh90 on list and the doco page does not have the search option. A later version perhaps? From fedoraleg_form at mm-vanecek.cc Sat May 15 00:19:51 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Fri, 14 May 2004 19:19:51 -0500 Subject: Security Notices Message-ID: <20040515001900.M97006@mm-vanecek.cc> I noticed the following security notifications have come out and I already have two of them installed on my RH 9 system. [SECURITY] Fedora Update Notification: iproute-2.4.7-13.2 # rpm -q iproute iproute-2.4.7-7.90.1 SECURITY] Fedora Core 1 Update: lha-1.14i-12.1 # rpm -q lha lha-1.14i-9.1 [SECURITY] Fedora Core 1 Update: libpng-1.2.2-20 ]# rpm -q libpng libpng-1.2.2-20 [SECURITY] Fedora Core 1 Update: libpng10-1.0.13-11 ]# rpm -q libpng10 libpng10-1.0.13-11 Will iproute and lha updates eventually get into the FL repo for RH 9? From fedoraleg_form at mm-vanecek.cc Sat May 15 13:42:25 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Sat, 15 May 2004 08:42:25 -0500 Subject: Security SRPMS Message-ID: <20040515133600.M91139@mm-vanecek.cc> RH 9 system with all up2date and yum updates applied. I downloaded lha-1.14i-12.1.src.rpm and iproute-2.4.7-13.2.src.rpm from from http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/ The rpmbuild --rebuild of lha went fine, but the iproute had several errors: glibc/glibc-bugs.h -I/usr/include -I../include -DRESOLVE_HOSTNAMES -c -o ll_types.o ll_types.c In file included from ll_types.c:23: /usr/include/netinet/in.h:261: parse error before '(' token /usr/include/netinet/in.h:261: parse error before "__u32" /usr/include/netinet/in.h:262: parse error before '(' token /usr/include/netinet/in.h:262: parse error before "__u16" /usr/include/netinet/in.h:264: parse error before '(' token /usr/include/netinet/in.h:264: parse error before "__u32" /usr/include/netinet/in.h:266: parse error before '(' token /usr/include/netinet/in.h:266: parse error before "__u16" make[1]: *** [ll_types.o] Error 1 make[1]: Leaving directory `/home/admin/rpms/BUILD/iproute2/lib' make: *** [all] Error 2 error: Bad exit status from /home/admin/rpms/tmp/rpm-tmp.79460 (%build) RPM build errors: Bad exit status from /home/admin/rpms/tmp/rpm-tmp.79460 (%build) Will the lha binary be of use to the project? The error on iproute is beyond my expertise. However, if someone can help resolve it, I would build a RH 9 version of it as well. From pmatilai at welho.com Sat May 15 15:59:05 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 15 May 2004 18:59:05 +0300 (EEST) Subject: apt or yum? In-Reply-To: <20040514165830.GA3441@math30192.math.gatech.edu> References: <1084353230.2314.1176.camel@khc09.samurajdata.se> <40A1EE33.6010700@users.sourceforge.net> <20040514135539.GA27708@mail1.smilehouse.com> <20040514165830.GA3441@math30192.math.gatech.edu> Message-ID: On Fri, 14 May 2004, Carlos Villegas wrote: > > PS: I use yum at work, and apt-get (for debian) at home. > PS2: one thing I love about apt-get is the "source" command, but > not sure if it's available for the rpm version of > apt-get, I also heard rumors that it would eventually > appear in yum, but I'm not sure what the status of that > is. Sure "source" and "build-dep" and such work in apt-rpm as well. In fact apt-rpm is in many ways far more advanced than "Debian apt". See http://lwn.net/Articles/60650/ for a list of some killer features (IMHO) in apt-rpm which are not present in Debian version. - Panu - From mattdm at mattdm.org Sat May 15 16:20:05 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 15 May 2004 12:20:05 -0400 Subject: apt or yum? In-Reply-To: References: <1084353230.2314.1176.camel@khc09.samurajdata.se> <40A1EE33.6010700@users.sourceforge.net> <20040514135539.GA27708@mail1.smilehouse.com> <20040514165830.GA3441@math30192.math.gatech.edu> Message-ID: <20040515162005.GA27553@jadzia.bu.edu> On Sat, May 15, 2004 at 06:59:05PM +0300, Panu Matilainen wrote: > Sure "source" and "build-dep" and such work in apt-rpm as well. In fact > apt-rpm is in many ways far more advanced than "Debian apt". See > http://lwn.net/Articles/60650/ for a list of some killer features (IMHO) > in apt-rpm which are not present in Debian version. My favorite one is installing packages by filename. That's so useful. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pmatilai at welho.com Sat May 15 16:29:25 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 15 May 2004 19:29:25 +0300 (EEST) Subject: apt or yum? In-Reply-To: <20040515162005.GA27553@jadzia.bu.edu> References: <1084353230.2314.1176.camel@khc09.samurajdata.se> <40A1EE33.6010700@users.sourceforge.net> <20040514135539.GA27708@mail1.smilehouse.com> <20040514165830.GA3441@math30192.math.gatech.edu> <20040515162005.GA27553@jadzia.bu.edu> Message-ID: On Sat, 15 May 2004, Matthew Miller wrote: > On Sat, May 15, 2004 at 06:59:05PM +0300, Panu Matilainen wrote: > > Sure "source" and "build-dep" and such work in apt-rpm as well. In fact > > apt-rpm is in many ways far more advanced than "Debian apt". See > > http://lwn.net/Articles/60650/ for a list of some killer features (IMHO) > > in apt-rpm which are not present in Debian version. > > My favorite one is installing packages by filename. That's so useful. Indeed (and dont forget installing by an arbitrary URL either :) AFAIK apt is the only one of the depsolvers which supports that, or at least that was the case last I checked. I know Adrian wants to add that support to up2date (there is/was a comment in up2date source about that being "unnecessarily difficult to do at the moment"), dunno if Seth is considering adding that to yum. - Panu - From jkeating at j2solutions.net Sun May 16 19:14:27 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 16 May 2004 12:14:27 -0700 Subject: yum for RHL9 Message-ID: <200405161214.31043.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please QA my yum package for RHL9 https://bugzilla.fedora.us/show_bug.cgi?id=1604 - -- 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) iD8DBQFAp72W4v2HLvE71NURAtWrAKCip+Dy8D05f7O3JenkQ9rGMrGJ6ACfe3Ft owrTMaizl9gcuLCpXLdl8pg= =EDnb -----END PGP SIGNATURE----- From fedoraleg_form at mm-vanecek.cc Mon May 17 00:44:24 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Sun, 16 May 2004 19:44:24 -0500 Subject: yum for RHL9 In-Reply-To: <200405161214.31043.jkeating@j2solutions.net> References: <200405161214.31043.jkeating@j2solutions.net> Message-ID: <20040517001723.M66995@mm-vanecek.cc> On Sun, 16 May 2004 12:14:27 -0700, Jesse Keating wrote > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Please QA my yum package for RHL9 > > https://bugzilla.fedora.us/show_bug.cgi?id=1604 > Done. Found no errors with basic testing. However, since my system was current, no updates were installed. Minor: When loading headers, it would be nice if the width of the field for the header name were just a bit longer so that the package name is not trucated. XFree86-ISO8859-2-75dpi-f 100% |=========================| 65 kB 00:00 Wish that list were sorted as well ... piped it to sort, but that eliminates the need for the completion info =====. Man yum -- does not show the search command even though it is listed in the detailed discussion. DESCRIPTION yum is an interactive, automated update program which can be used for maintaining systems using rpm command is one of: * install package1 [package2] [...] * update [package1] [package2] [...] * check-update * upgrade [package1] [package2] [...] *deprecated* this command may be removed in the future. * remove [package1] [package2] [...] * list [...] * info [...] * provides [...] * clean [ packages | headers | oldheaders | all ] * groupinstall [...] * groupupdate [...] * grouplist [...] I also do not run with kernel excluded. Anything specific you would like me to test? From john at chattanooga.net Mon May 17 01:12:53 2004 From: john at chattanooga.net (John Aldrich) Date: Sun, 16 May 2004 21:12:53 -0400 Subject: HELP!!! Yum runs and runs and runs and... Message-ID: <200405162112.53070.john@chattanooga.net> I tried to do a "yum update" Saturday night and Sunday it was still running with no apparent activity. So, I killed the process (and apparently related processes) and do a "yum check-updates" and it just sits there and sits there and doesn't appear to do anything. What's wrong? I know I've got my config file right because I was able to check updates earlier, but now nothing seems to happen when I try to run yum. My *guess* would be that everyone is checking for and downloading updates, but there ought to be something printed out on the console, but there isn't anything... Running RH 9 here. Thanks... John From fedora at wir-sind-cool.org Mon May 17 01:27:12 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 17 May 2004 03:27:12 +0200 Subject: HELP!!! Yum runs and runs and runs and... In-Reply-To: <200405162112.53070.john@chattanooga.net> References: <200405162112.53070.john@chattanooga.net> Message-ID: <20040517032712.5416b35d.fedora@wir-sind-cool.org> On Sun, 16 May 2004 21:12:53 -0400 John Aldrich wrote: > I tried to do a "yum update" Saturday night and Sunday it was still running > with no apparent activity. So, I killed the process (and apparently related > processes) and do a "yum check-updates" and it just sits there and sits there > and doesn't appear to do anything. What's wrong? I know I've got my config > file right because I was able to check updates earlier, but now nothing seems > to happen when I try to run yum. My *guess* would be that everyone is > checking for and downloading updates, but there ought to be something printed > out on the console, but there isn't anything... Running RH 9 here. Sounds like the usual "stale locks" issue with RPM since Red Hat Linux 8.0. Erase the temporary files in /var/lib/rpm after you terminated yum (and what you refer to as "related processes"): rm -f /var/lib/rpm/__db.* rpm -vv --rebuilddb If that doesn't fix it, post your yum.conf, so we know what servers you tried to access. -- Fedora Core release 2 (Tettnang) - Linux 2.6.5-1.358 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From john at chattanooga.net Mon May 17 13:37:11 2004 From: john at chattanooga.net (John Aldrich) Date: Mon, 17 May 2004 09:37:11 -0400 Subject: HELP!!! Yum runs and runs and runs and... In-Reply-To: <20040517032712.5416b35d.fedora@wir-sind-cool.org> References: <200405162112.53070.john@chattanooga.net> <20040517032712.5416b35d.fedora@wir-sind-cool.org> Message-ID: <200405170937.11401.john@chattanooga.net> On Sunday 16 May 2004 09:27 pm, you wrote: > Sounds like the usual "stale locks" issue with RPM since Red Hat Linux > 8.0. Erase the temporary files in /var/lib/rpm after you terminated > yum (and what you refer to as "related processes"): > > rm -f /var/lib/rpm/__db.* > rpm -vv --rebuilddb > > If that doesn't fix it, post your yum.conf, so we know what servers > you tried to access. > Thanks, Michael... That almost fixed it. Apparently I didn't kill enough processes, etc as I had to reboot to do this. I still don't have any updates for RH9, but I guess that means there aren't any. I hope. :-) From fedora at wir-sind-cool.org Mon May 17 15:43:04 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 17 May 2004 17:43:04 +0200 Subject: Good bye, Fedora Legacy! Message-ID: <20040517174304.6aa9c469.fedora@wir-sind-cool.org> After having slept on it, for me it's time to unsubscribe and discontinue any Fedora Legacy activities. Hence I wave "Good bye!" to the few people involved so far. If I were enough of a geek and found myself interesting enough to run my own blog, I would bitch about it in there. But I'm not. And so I post a few impressions here. It just doesn't work, when even trivial fixes or patches ripped off of Red Hat Enterprise Linux errata don't receive proper attention and the update packages sit in the queue for months without anyone posting clearsigned reviews or approvals, respectively. Future fixes won't be as easy as taking patches from RHEL without modification and applying them to Red Hat Linux 7.3. It may be necessary to do real backporting and prepare and test upgrades as a last resort. No, it's not that updates are prioritized and more important updates occupy all available resources. It's not hardware and server maintenance induced delays either, because the bugzilla system is available and the packages can be prepared meanwhile independently of mirror/server logistics. It's that the Fedora Legacy community has not decided on publish criteria and minimal formalism on how to review and approve packages (in particular the good bits of the fedora.us policies and guidelines). Therefore, neither packagers or reviewers know what exactly is required to get a package published _in time_. It's not even known how to get a package into "updates-testing" and how long it will be kept in there. Additionally, non-existing updates for less popular distributions (e.g. rh80) hold up reviewed and approved updates for popular distributions, e.g. rh73. A developer, who looks into security advisories and patches today, doesn't want to repeat the same work 2-3 months later -- when finally it's decided the time has come to push out another update which has been neglected for several weeks or when the next weakness must be dealt with and the fix for the previous one has not been approved yet. Developers and reviewers want to finish something and move on. The early support for rh73 has been an opportunity to practice doing legacy updates, in particular with official patches from RHEL which make that a lot easier. This chance has not been taken. So long, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hbo at egbok.com Mon May 17 18:35:46 2004 From: hbo at egbok.com (Howard Owen) Date: Mon, 17 May 2004 11:35:46 -0700 (PDT) Subject: Good bye, Fedora Legacy! In-Reply-To: <20040517174304.6aa9c469.fedora@wir-sind-cool.org> Message-ID: All good points. It's hard to criticise a volunteer effort, particularly since I haven't found a way to be useful yet (though not from lack of offering,) but I have to get fixes out a *lot* quicker than I've seen them appear here. Now, I have the advantage of an internal QA process that backstops my work, but those guys have procedures they follow, and they get the job done reasonably quickly. How can I help in addressing some of Michael's criticisms? My expertise is in analyzing and integrating patches. But it seems that what is needed is some minimal amount of formalism and process. I say "minimal" because projects can get bogged down in discussions over that sort of thing. I vote for a bare-bones release process that can be effective. Off the top of my head: 1 Vulnerabilty Analysis. Watch the lists, the vendor patches and other sources. Determine quickly if a particular problem applies to the relevant distros. That part of the process doesn't seem to be broken, though it's informal. 2 Remediation. Leverage the vendors. State schedules. Publish status. As Michael notes, this will become increasingly difficult as the supported distributions drift farther from the mainstream. That's unavoidable, but the critical thing is frequent status updates so that others can see where help is needed. 3 QA. This seems to be where the most trouble is. Is the problem due to lack of testers? What are the criterea for calling QA adequate? Where is the status pubished? If we don't have testers for a particular distribution, perhaps we should consider dropping support for that distro. That's harsh, but if folks don't like it, they can pitch in. Or can they? 4 Release. What are the criterea? Are there infrastructure issues? What's the schedule? Apologies if these questions are answered elsewhere. Also, I'm not unappreciative of the effort shown here. The triage has been very helpful to me, and I'm grateful. I'd like to offer help where I can, but I'm concerned that it could be wasted without a bit more formal approach. On Mon, 17 May 2004, Michael Schwendt wrote: > After having slept on it, for me it's time to unsubscribe and discontinue > any Fedora Legacy activities. Hence I wave "Good bye!" to the few people > involved so far. > > If I were enough of a geek and found myself interesting enough to run my > own blog, I would bitch about it in there. But I'm not. And so I post a > few impressions here. > > It just doesn't work, when even trivial fixes or patches ripped off of Red > Hat Enterprise Linux errata don't receive proper attention and the update > packages sit in the queue for months without anyone posting clearsigned > reviews or approvals, respectively. > > Future fixes won't be as easy as taking patches from RHEL without > modification and applying them to Red Hat Linux 7.3. It may be necessary > to do real backporting and prepare and test upgrades as a last resort. > > No, it's not that updates are prioritized and more important updates > occupy all available resources. It's not hardware and server maintenance > induced delays either, because the bugzilla system is available and the > packages can be prepared meanwhile independently of mirror/server > logistics. > > It's that the Fedora Legacy community has not decided on publish criteria > and minimal formalism on how to review and approve packages (in particular > the good bits of the fedora.us policies and guidelines). Therefore, > neither packagers or reviewers know what exactly is required to get a > package published _in time_. > > It's not even known how to get a package into "updates-testing" and how > long it will be kept in there. Additionally, non-existing updates for less > popular distributions (e.g. rh80) hold up reviewed and approved updates > for popular distributions, e.g. rh73. A developer, who looks into security > advisories and patches today, doesn't want to repeat the same work 2-3 > months later -- when finally it's decided the time has come to push out > another update which has been neglected for several weeks or when the next > weakness must be dealt with and the fix for the previous one has not been > approved yet. Developers and reviewers want to finish something and move on. > > The early support for rh73 has been an opportunity to practice doing > legacy updates, in particular with official patches from RHEL which make > that a lot easier. This chance has not been taken. > > So long, > Michael > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From hbo at egbok.com Mon May 17 18:45:02 2004 From: hbo at egbok.com (Howard Owen) Date: Mon, 17 May 2004 11:45:02 -0700 (PDT) Subject: Good bye, Fedora Legacy! In-Reply-To: Message-ID: By the way, I have a postgresql schema and a bunch of Perl that help me track problems and fixes in 7.3. It could be easily extended to cover other distributions. It would need to be altered to fit whatever process the project comes up with. But it would enable ad-hoc query of status at various stages. On Mon, 17 May 2004, Howard Owen wrote: > > All good points. It's hard to criticise a volunteer effort, particularly > since I haven't found a way to be useful yet (though not from lack of > offering,) but I have to get fixes out a *lot* quicker than I've seen them > appear here. Now, I have the advantage of an internal QA process that > backstops my work, but those guys have procedures they follow, and they > get the job done reasonably quickly. > > How can I help in addressing some of Michael's criticisms? My expertise is > in analyzing and integrating patches. But it seems that what is needed is > some minimal amount of formalism and process. I say "minimal" because > projects can get bogged down in discussions over that sort of thing. I > vote for a bare-bones release process that can be effective. Off the top > of my head: > > 1 Vulnerabilty Analysis. > Watch the lists, the vendor patches and other sources. Determine > quickly if a particular problem applies to the relevant distros. > That part of the process doesn't seem to be broken, though it's > informal. > 2 Remediation. > Leverage the vendors. State schedules. Publish status. As > Michael notes, this will become increasingly difficult as the > supported distributions drift farther from the mainstream. > That's unavoidable, but the critical thing is frequent status > updates so that others can see where help is needed. > 3 QA. > This seems to be where the most trouble is. Is the problem > due to lack of testers? What are the criterea for calling > QA adequate? Where is the status pubished? If we don't have > testers for a particular distribution, perhaps we should > consider dropping support for that distro. That's harsh, but > if folks don't like it, they can pitch in. Or can they? > 4 Release. > What are the criterea? Are there infrastructure issues? What's > the schedule? > > Apologies if these questions are answered elsewhere. Also, I'm not > unappreciative of the effort shown here. The triage has been very helpful > to me, and I'm grateful. I'd like to offer help where I can, but I'm > concerned that it could be wasted without a bit more formal approach. > > On Mon, 17 May 2004, Michael Schwendt wrote: > > > After having slept on it, for me it's time to unsubscribe and discontinue > > any Fedora Legacy activities. Hence I wave "Good bye!" to the few people > > involved so far. > > > > If I were enough of a geek and found myself interesting enough to run my > > own blog, I would bitch about it in there. But I'm not. And so I post a > > few impressions here. > > > > It just doesn't work, when even trivial fixes or patches ripped off of Red > > Hat Enterprise Linux errata don't receive proper attention and the update > > packages sit in the queue for months without anyone posting clearsigned > > reviews or approvals, respectively. > > > > Future fixes won't be as easy as taking patches from RHEL without > > modification and applying them to Red Hat Linux 7.3. It may be necessary > > to do real backporting and prepare and test upgrades as a last resort. > > > > No, it's not that updates are prioritized and more important updates > > occupy all available resources. It's not hardware and server maintenance > > induced delays either, because the bugzilla system is available and the > > packages can be prepared meanwhile independently of mirror/server > > logistics. > > > > It's that the Fedora Legacy community has not decided on publish criteria > > and minimal formalism on how to review and approve packages (in particular > > the good bits of the fedora.us policies and guidelines). Therefore, > > neither packagers or reviewers know what exactly is required to get a > > package published _in time_. > > > > It's not even known how to get a package into "updates-testing" and how > > long it will be kept in there. Additionally, non-existing updates for less > > popular distributions (e.g. rh80) hold up reviewed and approved updates > > for popular distributions, e.g. rh73. A developer, who looks into security > > advisories and patches today, doesn't want to repeat the same work 2-3 > > months later -- when finally it's decided the time has come to push out > > another update which has been neglected for several weeks or when the next > > weakness must be dealt with and the fix for the previous one has not been > > approved yet. Developers and reviewers want to finish something and move on. > > > > The early support for rh73 has been an opportunity to practice doing > > legacy updates, in particular with official patches from RHEL which make > > that a lot easier. This chance has not been taken. > > > > So long, > > Michael > > > > > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From jkeating at j2solutions.net Tue May 18 02:19:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 17 May 2004 19:19:32 -0700 Subject: Proposed change for file locations on download server Message-ID: <200405171919.35267.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been thinking over the way we have files on the server, and I've thought of a solution to a problem. Problem: legacy-utils provided may not install cleanly to a freshly installed legacy OS. Some packages may have to be updated. Proposed Solution: legacy-utils will contain utilities that are built against a non-updated OS install (fresh from the CDs). Updates to these utilities will be provided in the updates/ tree for the release. The only drawback is that non-original packages will be placed into the updates/ tree. After some thought, I'm comfortable with this, as individuals that do not have these packages installed will not be effected by this. Are there any objections to transitioning our download server to this method? - -- 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.3 (GNU/Linux) iD8DBQFAqXK34v2HLvE71NURAt33AKCYnT3/i5x9x0AJ5IKXmy8GbpPfHQCdFG5s TFzSyMrFgivDxq1FIhjYwoM= =Yq2f -----END PGP SIGNATURE----- From dennis at ausil.us Tue May 18 02:22:39 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 18 May 2004 12:22:39 +1000 Subject: Proposed change for file locations on download server In-Reply-To: <200405171919.35267.jkeating@j2solutions.net> References: <200405171919.35267.jkeating@j2solutions.net> Message-ID: <200405181222.39170.dennis@ausil.us> Once upon a time Tuesday 18 May 2004 12:19 pm, Jesse Keating wrote: > I've been thinking over the way we have files on the server, and I've > thought of a solution to a problem. > > Problem: legacy-utils provided may not install cleanly to a freshly > installed legacy OS. Some packages may have to be updated. > > Proposed Solution: legacy-utils will contain utilities that are built > against a non-updated OS install (fresh from the CDs). Updates to these > utilities will be provided in the updates/ tree for the release. > > The only drawback is that non-original packages will be placed into the > updates/ tree. After some thought, I'm comfortable with this, as > individuals that do not have these packages installed will not be effected > by this. > > Are there any objections to transitioning our download server to this > method? i think we should keep legacy-utils separate but perhaps we have a tree for updated os and one for clean os to get to update with just yum or apt or both so updates can be gotten From genii at hushmail.com Sun May 9 13:39:20 2004 From: genii at hushmail.com (genii at hushmail.com) Date: Sun, 9 May 2004 06:39:20 -0700 Subject: Instructions how to setup support for Redhat 9? Message-ID: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> Hi, First of all I would like to thank you about support for Redhat 9. However there appears to be no instructions how to setup apt for Redhat 9 in the "Documentation\Getting Started" page. Are you going to publish the instructions soon? Br. genii Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From troed at sangberg.se Sun May 9 19:26:17 2004 From: troed at sangberg.se (=?iso-8859-15?Q?Troed_S=E5ngberg?=) Date: Sun, 09 May 2004 21:26:17 +0200 Subject: RH9 user - what should I do? In-Reply-To: <20040508201609.6e90e433.fedora@wir-sind-cool.org> References: <20040508201609.6e90e433.fedora@wir-sind-cool.org> Message-ID: On Sat, 8 May 2004 20:16:09 +0200, Michael Schwendt wrote: > Let me see. My suggestion: > > * Run: rpm --import http://www.fedora.us/FEDORA-GPG-KEY > > * Get > http://download.fedora.us/fedora/redhat/9/i386/RPMS.stable/yum-2.0.3-0.fdr.1.rh90.noarch.rpm > > Install it with "rpm -Uvh yum-2.0.3-0.fdr.1.rh90.noarch.rpm" > Or install it directly with "rpm -ivh http://...." of the network. > RPM can do that. > > * Install the Fedora Legacy public key for verifying package signatures. > rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY > > * Choose a mirror of Fedora Legacy for Red Hat Linux 9 from the website, > e.g. modify /etc/yum.conf in the section that reads > > [redhat-updates] > name=Red Hat Linux $releasever ($basearch) updates > baseurl= > http://download.fedora.us/... > > to use a different baseurl= such as: > baseurl=http://legacy.linux.duke.edu/redhat/$releasever/updates/$basearch/ > > * If you don't want any of the Fedora.us add-ons for Red Hat Linux 9, > disable the [fedora-stable] entry in the lower half of /etc/yum.conf. > > * Then run "yum update" for the first time to fetch package headers. Note > there is a "yum" service which can download updates at night. Many thanks - I followed your suggestions and it updated two packages which means everything is working correctly, I believe. I'd vote for having your mail above published as a guide on the website :) regards, Troed From HansPeter.Bigl at ge.com Mon May 17 14:41:44 2004 From: HansPeter.Bigl at ge.com (Bigl, Hans Peter (GE Consumer Finance)) Date: Mon, 17 May 2004 15:41:44 +0100 Subject: Update policy Message-ID: Hi all Thanxs for your great service. Only a few question related to it as of course security is a critical area. Whats your average or policy to have security patches available after a new vulnarability is announced. Regards HansPeter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailarchive at webbedmail.com Tue May 18 04:14:53 2004 From: mailarchive at webbedmail.com (mailarchive at webbedmail.com) Date: Tue, 18 May 2004 05:14:53 +0100 Subject: Good bye, Fedora Legacy! In-Reply-To: References: Message-ID: <1084853693.40a98dbd9d929@192.168.40.40> Sorry to see Michael go.. Quoting Howard Owen : > > By the way, I have a postgresql schema and a bunch of Perl that help me > track problems and fixes in 7.3. It could be easily extended to cover > other distributions. It would need to be altered to fit whatever process > the project comes up with. But it would enable ad-hoc query of status at > various stages. I stopped relying on Fedora Legacy project a long time ago as it was a hobbyist project that didnt seem to have a clue about Security. I remembered a guy called Dag who had worked for a company we acquired in Belgium when I headed up VA Linux technical services in Europe, pre me starting Smoothwall (so please I do have a clue). He has been doing exactly what Fedora Legacy does - on his own - without support - far quicker - far more efficiently and far far more succintly than Fedora Legacy has been. This includes support for all major versions of RH. In fact he's the reason I haven't ditched 69 RH servers and gone to Debian. More info ?? Get yourself down to http://dag.wieers.com/home-made/ and http://dag.wieers.com/home-made/apt/ Richard Morrell Founder SmoothWall From pekkas at netcore.fi Tue May 18 05:13:22 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 18 May 2004 08:13:22 +0300 (EEST) Subject: Good bye, Fedora Legacy! In-Reply-To: <1084853693.40a98dbd9d929@192.168.40.40> Message-ID: On Tue, 18 May 2004 mailarchive at webbedmail.com wrote: > I remembered a guy called Dag who had worked for a company we acquired in > Belgium when I headed up VA Linux technical services in Europe, pre me starting > Smoothwall (so please I do have a clue). He has been doing exactly what Fedora > Legacy does - on his own - without support - far quicker - far more efficiently > and far far more succintly than Fedora Legacy has been. Actually, doing everything by yourself, or by a well-trusted inner circle is *much* easier than distributing the work, as you don't have to worry about the process issues. At the moment, it seems just a way too big pain in the ass to e.g., appropriately test an update -- and thus the updates do appear, but will stay in limbo. Not many bother to go through the painful & manual steps. If you could just trust the one who provided the update to fix the bugs and not backdoor you, this would be much simpler. I've a gut feeling that we need to make this easier. For example, add an automatic tool which diffs the contents of .src.rpm, and shows them on the web / send them via email for perusal. Then the binaries would be built by the trusted buildsystem out of those. Or something. Fetching the source RPMs, unpacking them, going through the files just seems to be something that would take that 10-20 minutes per update, and folks probably don't have time for that.. -- 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 jonny.strom at netikka.fi Tue May 18 11:42:09 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 18 May 2004 14:42:09 +0300 Subject: Good bye, Fedora Legacy! In-Reply-To: <1084853693.40a98dbd9d929@192.168.40.40> References: <1084853693.40a98dbd9d929@192.168.40.40> Message-ID: <40A9F691.8020204@netikka.fi> mailarchive at webbedmail.com wrote: > Sorry to see Michael go.. > > Quoting Howard Owen : > > >>By the way, I have a postgresql schema and a bunch of Perl that help me >>track problems and fixes in 7.3. It could be easily extended to cover >>other distributions. It would need to be altered to fit whatever process >>the project comes up with. But it would enable ad-hoc query of status at >>various stages. > > > I stopped relying on Fedora Legacy project a long time ago as it was a hobbyist > project that didnt seem to have a clue about Security. > > I remembered a guy called Dag who had worked for a company we acquired in > Belgium when I headed up VA Linux technical services in Europe, pre me starting > Smoothwall (so please I do have a clue). He has been doing exactly what Fedora > Legacy does - on his own - without support - far quicker - far more efficiently > and far far more succintly than Fedora Legacy has been. > > This includes support for all major versions of RH. In fact he's the reason I > haven't ditched 69 RH servers and gone to Debian. > Well Dag dose not provide security uppdates for old RH relases like RH 9 I asked him about that and he pointed me to Fedora Legacy. > More info ?? > > Get yourself down to http://dag.wieers.com/home-made/ and > http://dag.wieers.com/home-made/apt/ > > Richard Morrell > Founder > SmoothWall > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From fedoraleg_form at mm-vanecek.cc Tue May 18 14:22:02 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Tue, 18 May 2004 09:22:02 -0500 Subject: Instructions how to setup support for Redhat 9? In-Reply-To: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> References: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> Message-ID: <20040518142126.M20909@mm-vanecek.cc> On Sun, 9 May 2004 06:39:20 -0700, genii wrote > Hi, > > First of all I would like to thank you about support for Redhat 9. > > However there appears to be no instructions how to setup apt for Redhat > 9 in the "Documentation\Getting Started" page. Are you going to publish > the instructions soon? Is this what you are looking for http://www.fedoralegacy.org/docs/apt-rh9.php From fedoraleg_form at mm-vanecek.cc Tue May 18 14:23:24 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Tue, 18 May 2004 09:23:24 -0500 Subject: Instructions how to setup support for Redhat 9? In-Reply-To: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> References: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> Message-ID: <20040518142254.M59922@mm-vanecek.cc> PS YUM is really easy to setup and use as well. From bvermeul at blackstar.nl Tue May 18 14:41:31 2004 From: bvermeul at blackstar.nl (Bas Vermeulen) Date: Tue, 18 May 2004 16:41:31 +0200 Subject: Is the apt setup working for RedHat 8.0? In-Reply-To: <20040518142126.M20909@mm-vanecek.cc> References: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> <20040518142126.M20909@mm-vanecek.cc> Message-ID: <1084891291.15152.4.camel@laptop.blackstar.nl> Hi, I've configured my RedHat 8.0 to work with apt (had it working as well), but currently I can't seem to update my package lists. I'm not sure what's causing this, but I have tried a different mirror already, but that didn't work either. I get 503 errors on the apt packages. Any help/insight on this issue? Thanks, Bas Vermeulen From rostetter at mail.utexas.edu Tue May 18 15:56:05 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 18 May 2004 10:56:05 -0500 Subject: Instructions how to setup support for Redhat 9? In-Reply-To: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> References: <200405091339.i49DdLdw045501@mailserver3.hushmail.com> Message-ID: <20040518105605.x5w00g40kw4c4484@mail.ph.utexas.edu> Quoting genii at hushmail.com: > However there appears to be no instructions how to setup apt for Redhat > 9 in the "Documentation\Getting Started" page. Are you going to publish > the instructions soon? Yes, there are unofficial instructions there since May 9th. Official instructions will be given when there is an official apt version for FL RH 9 use. > Br. genii -- Eric Rostetter From rostetter at mail.utexas.edu Tue May 18 15:57:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 18 May 2004 10:57:40 -0500 Subject: Update policy In-Reply-To: References: Message-ID: <20040518105740.3c0cks8cgkw0w0wk@mail.ph.utexas.edu> Quoting "Bigl, Hans Peter (GE Consumer Finance)" : > Only a few question related to it as of course security is a critical > area. Whats your average or policy to have security patches available > after a new vulnarability is announced. How about: "As soon as possible." Seriously, I don't think there is any way to know how fast a patch can be available. It depends on so many factors. > Regards > > HansPeter -- Eric Rostetter From fleck004 at umn.edu Tue May 18 20:48:04 2004 From: fleck004 at umn.edu (Peter Fleck) Date: Tue, 18 May 2004 15:48:04 -0500 Subject: Problem with GPG Key In-Reply-To: <1084148524.29382.26.camel@binkley> References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> <20040506213437.52a6214a.fedora@wir-sind-cool.org> <7C582437-A02B-11D8-918D-00039303286A@umn.edu> <1084148524.29382.26.camel@binkley> Message-ID: Still unable to get yum to work on my RH 7.2 system. When I last posted, the output of: rpm -Kv /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm gave me: MD5 sum OK: 084e0d35954655739b8d074ac2a4044f gpg: Signature made Sat 24 Jan 2004 02:01:34 AM CST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA I edited the trust level on the key in gpg and now I get the following, which seems better: /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm: MD5 sum OK: 084e0d35954655739b8d074ac2a4044f gpg: Signature made Sat 24 Jan 2004 02:01:34 AM CST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) " But when I try to use yum to update a package, it still says: Error: GPG Signature check failed for /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm You may also want to check to make sure you have the right gpg keys Exiting. Any idea on what to try next? Thanks. ======================================================== Peter Fleck Webmaster | University of Minnesota Cancer Center Dinnaken Office Bldg. 925 Delaware St. SE Minneapolis, MN 55414 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu Campus Mail: MMC 806 From jkeating at j2solutions.net Wed May 19 02:20:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 19:20:41 -0700 Subject: [FLSA-2004:1268] Updated libtool resolves security vulnerability Message-ID: <200405181920.44659.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated libtool resolves security vulnerability Advisory ID: FLSA:1268 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1268 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated libtool packages that fix local tmp vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: The libtool package contains the GNU libtool, a set of shell scripts which automatically configure UNIX and UNIX-like architectures to generically build shared libraries. Libtool provides a consistent, portable interface which simplifies the process of using shared libraries. If you are developing programs which will use shared libraries, you should install libtool. The chmod utility has a race (that access to the temporary directory could be gained after it is created but before it is chmoded) Fedora Legacy would like to thank Seth Vidal for bringing this issue to our attention. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1268 - Symlink Vulnerability in GNU libtool <1.5.2 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/libtool-1.4-9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/libtool-1.4-9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/libtool-libs-1.4-9.legacy.i386.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/libtool-1.4.2-13.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/libtool-1.4.2-13.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libtool-libs-1.4.2-13.legacy.i386.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/libtool-1.4.2-14.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/libtool-1.4.2-14.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/libtool-libs-1.4.2-14.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 13e868d1a6e24f185e747b62e11819971c441da5 7.2/updates/SRPMS/libtool-1.4-9.legacy.src.rpm 2732828598e0be48ed39f54e7cc42370c662d9cd 7.2/updates/i386/libtool-1.4-9.legacy.i386.rpm 34fdec6bd3246b51dc2993f7b01194952717f145 7.2/updates/i386/libtool-libs-1.4-9.legacy.i386.rpm 94580dd2607afce8ab7e615b937234977a2345c5 7.3/updates/SRPMS/libtool-1.4.2-13.legacy.src.rpm 705a844d64e11e4c7d13d70e2b7957bbb403a33f 7.3/updates/i386/libtool-1.4.2-13.legacy.i386.rpm 815821f416de6969939854dfa1a9215a93408040 7.3/updates/i386/libtool-libs-1.4.2-13.legacy.i386.rpm 6b9c3e628278b0fc5966dd4f4911ad1edae438ef 8.0/updates/SRPMS/libtool-1.4.2-14.legacy.src.rpm 96d900b337cab85040da9062593a43fee24849c1 8.0/updates/i386/libtool-1.4.2-14.legacy.i386.rpm e39aa95f8a3a643bb9d5ea707b11b65868a2e3b7 8.0/updates/i386/libtool-libs-1.4.2-14.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://www.redhat.com/archives/fedora-legacy-list/2004-February/msg00109.html https://bugzilla.fedora.us/show_bug.cgi?id=1268 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQFAqsR84v2HLvE71NURAq6NAKCALCDNpcfQKZMLuS8yz1Ft5gdtPQCYyXmL xn4MeJY8/nUfF0WT2ZkKGw== =E5rA -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 02:36:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 19:36:30 -0700 Subject: [FLSA-2004:1224] Updated mc resolves security vulnerability Message-ID: <200405181936.31002.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mc resolves security vulnerability Advisory ID: FLSA:1224 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1224 CVE Names: CAN-2003-1023 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated mc packages that fix remote buffer overflow vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Midnight Commander is a visual shell much like a file manager, only with many more features. It is a text mode application, but it also includes mouse support if you are running GPM. Midnight Commander's best features are its ability to FTP, view tar and zip files, and to poke into RPMs for specific files. There exists a stack-based buffer overflow in vfs_s_resolve_symlink of vfs/direntry.c for Midnight Commander (mc) 4.6.0 and earlier, and possibly later versions, allowing remote attackers to execute arbitrary code during symlink conversion. Fedora Legacy would like to thank Seth Vidal for bringing this issue to our attention. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1224 - bug in mc - gnu midnight commander 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/mc-4.5.51-37.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/mc-4.5.51-37.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/mcserv-4.5.51-37.legacy.i386.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mc-4.5.55-6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mc-4.5.55-6.legacy.i386.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/mc-4.5.55-13.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/mc-4.5.55-13.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 9f8a003f130fa1f9a97c77bb481791445885f1b5 7.2/updates/SRPMS/mc-4.5.51-37.legacy.src.rpm b9a4452ffc5d1aaf99fcc2eff940dd6252c24446 7.2/updates/i386/mc-4.5.51-37.legacy.i386.rpm 8c3ff32790268aa8d38e3b0c2a63da6c8b603363 7.2/updates/i386/mcserv-4.5.51-37.legacy.i386.rpm 045b05e94d3971759110bf6e5faf3797e8c771f1 7.3/updates/SRPMS/mc-4.5.55-6.legacy.src.rpm d56d82b210636fe30c09d0ce09b38cf8572e4ab5 7.3/updates/i386/mc-4.5.55-6.legacy.i386.rpm be63f46bf7e3b003b9d07a731ee158ec33215ff6 8.0/updates/SRPMS/mc-4.5.55-13.legacy.src.rpm 34cfea3816c76dba42e3fb1ac4f15c6b48704b2d 8.0/updates/i386/mc-4.5.55-13.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1023 https://bugzilla.fedora.us/show_bug.cgi?id=1224 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAqsgu4v2HLvE71NURAlydAJ9nDojXInDCY0pDPwuwRRqS4Xr7YwCfaT0n un47GSmWgUwTk8bnAzCPP68= =4Mje -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 03:01:34 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 20:01:34 -0700 Subject: [FLSA-2004:1305] Updated metamail resolves security vulnerability Message-ID: <200405182001.34924.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated metamail resolves security vulnerability Advisory ID: FLSA:1305 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1305 CVE Names: CAN-2004-0104 CAN-2004-0105 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated metamail packages that fix a number of vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 3. Problem description: Metamail is a system for handling multimedia mail. Ulf Harnhammar discovered two integer overflow bugs and two buffer overflow bugs in versions of Metamail up to and including 2.7. An attacker could create a carefully-crafted message such that when it is opened by a victim and parsed through Metamail, it runs arbitrary code as the victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0104 and CAN-2004-0105 to these issues. Users of Red Hat Linux 7.2 and 7.3 are advised to upgrade to these erratum packages, which contain a backported security patch and are not vulnerable to these issues. Please note that Red Hat Linux 8 or newer does not contain Metamail and is therefore not vulnerable to these issues. Red Hat would like to thank Michal Jaegermann for notification of this issue, and Ulf Harnhammar for the patch for these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1305 - buffer and integer overflows in metamail 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/metamail-2.7-29.7.x.legacy.i386.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/metamail-2.7-29.7.x.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 280751e83a0abb7513c9317fd1f6f5eb5ce493f5 7.2/updates/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm a27699e22525617ba294320adaa58838bb7a6535 7.2/updates/i386/metamail-2.7-29.7.x.legacy.i386.rpm 280751e83a0abb7513c9317fd1f6f5eb5ce493f5 7.3/updates/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm a27699e22525617ba294320adaa58838bb7a6535 7.3/updates/i386/metamail-2.7-29.7.x.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0104 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0105 http://www.redhat.com/support/errata/RHSA-2004-073.html https://bugzilla.fedora.us/show_bug.cgi?id=1305 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAqs4O4v2HLvE71NURAl9sAJ9iw/e0r2BlKkAf7BYeelFklWySlACeMys4 rQaifRJ1k0mDexLtbg2jpfU= =QCAn -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 03:25:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 20:25:40 -0700 Subject: [FLSA-2004:1546] Updated utempter resolves security vulnerability Message-ID: <200405182025.40869.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated utempter resolves security vulnerability Advisory ID: FLSA:1546 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1546 CVE Names: CAN-2004-0233 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: An updated utempter package that fixes a potential symlink vulnerability is now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Utempter is a utility that allows terminal applications such as xterm and screen to update utmp and wtmp without requiring root privileges. Steve Grubb discovered a flaw in Utempter which allowed device names containing directory traversal sequences such as '/../'. In combination with an application that trusts the utmp or wtmp files, this could allow a local attacker the ability to overwrite privileged files using a symlink. Users should upgrade to this new version of utempter, which fixes this vulnerability. Fedora Legacy would like to thank Barry K. Nathan for notification of this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1546 - utempter symlink vulnerability 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/utempter-0.5.2-6.8.0.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/utempter-0.5.2-6.8.0.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 739587d500bf401d83a5f2b01195ca8b5c81bed7 7.2/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm 021ec30fe6404f2eb74eee160a339fbd003c1b97 7.2/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm 739587d500bf401d83a5f2b01195ca8b5c81bed7 7.3/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm 021ec30fe6404f2eb74eee160a339fbd003c1b97 7.3/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm 2a3e5d030205551ffbf4460ff0dbabdac91e41d0 8.0/updates/SRPMS/utempter-0.5.2-6.8.0.1.legacy.src.rpm 1c6109fa9254052a2948e1999bab966ed86c68d1 8.0/updates/i386/utempter-0.5.2-6.8.0.1.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0233 https://rhn.redhat.com/errata/RHSA-2004-175.html https://bugzilla.fedora.us/show_bug.cgi?id=1546 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAqtO04v2HLvE71NURAosYAJsEdEa8dfVsZkvwmw3CrORNHqiODgCglygQ Ri2cgC80i3x7nHlc29O/ioE= =J2Ln -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 03:58:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 20:58:52 -0700 Subject: [FLSA-2004:1285] Updated mutt resolves security vulnerability Message-ID: <200405182058.52187.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mutt resolves security vulnerability Advisory ID: FLSA:1285 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1285 CVE Names: CAN-2004-0078 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: New mutt packages that fix a remotely-triggerable crash in the menu drawing code are now available. 2. Relevent releases/architectures: Red Hat Linux 8.0 - i386 3. Problem description: Mutt is a text-mode mail user agent. A bug was found in the index menu code in versions of mutt. A remoteattacker could send a carefully crafted mail message that can cause mutt to segfault and possibly execute arbitrary code as the victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0078 to this issue. It is recommended that all mutt users upgrade to these updated packages, which contain a backported security patch and are not vulnerable to this issue. Fedora Legacy would like to thank Johnny Strom for notification of this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1285 - Remotely-triggerable crash in the menu drawing in mutt. 6. RPMs required: Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/mutt-1.4.1-0.8.x.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/mutt-1.4.1-0.8.x.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- b7e95c02951c5b412d3c08abd90fbd03db89e1dd 8.0/updates/SRPMS/mutt-1.4.1-0.8.x.1.legacy.src.rpm 3d2b3c5631252abc13959f87a164bf3f96459997 8.0/updates/i386/mutt-1.4.1-0.8.x.1.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0078 https://rhn.redhat.com/errata/RHSA-2004-051.html https://bugzilla.fedora.us/show_bug.cgi?id=1285 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAqtt84v2HLvE71NURAhbiAJ48PvUUvUzOYN3u/OKhNGevyVc1uQCeKQ1w UMycXRbejoI/jeZjm6u/GFM= =r9wl -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 04:11:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 21:11:48 -0700 Subject: [FLSA-2004:1296] Updated libtool resolves security vulnerability Message-ID: <200405182111.48879.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated pwlib resolves security vulnerability Advisory ID: FLSA:1296 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1296 CVE Names: CAN-2004-0097 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated PWLib packages that contain fixes for security issues found during protocol testing by the NISCC are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: PWLib is a cross-platform class library designed to support the OpenH323 project. OpenH323 provides an implementation of the ITU H.323 teleconferencing protocol, used by packages such as Gnome Meeting. A test suite for the H.225 protocol (part of the H.323 family) provided by the NISCC uncovered bugs in PWLib prior to version 1.6.0. An attacker could trigger these bugs by sending carefully crafted messages to an application. The effects of such an attack can vary depending on the application, but would usually result in a Denial of Service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0097 to this issue. Users are advised to upgrade to the erratum packages, which contain backported security fixes and are not vulnerable to these issues. Fedora Legacy would like to thank Johnny Strom for notification of this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1296 - PWLib: Carefully crafted messages can cause a Denial of Service on a application. 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/pwlib-1.2.12-4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/pwlib-1.2.12-4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/pwlib-devel-1.2.12-4.legacy.i386.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/pwlib-1.3.3-6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/pwlib-1.3.3-6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/pwlib-devel-1.3.3-6.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 083f52e7339aabe4b123506b37d6638fd6ff0114 7.3/updates/SRPMS/pwlib-1.2.12-4.legacy.src.rpm bfccb74ebed5ae978ca99efe0e33504a27efcb66 7.3/updates/i386/pwlib-1.2.12-4.legacy.i386.rpm 4540e6e0cb3cf8d388dda9616d5ca6d0818afc7f 7.3/updates/i386/pwlib-devel-1.2.12-4.legacy.i386.rpm 798cc21e3741fd7a984ba8f8287f1ceaac84a3ae 8.0/updates/SRPMS/pwlib-1.3.3-6.legacy.src.rpm 5b7f740057678c6d0ce83a7aefec56a7cc69a0eb 8.0/updates/i386/pwlib-1.3.3-6.legacy.i386.rpm 6c35dd204c72d5ffb114d63dcc1fce733050b511 8.0/updates/i386/pwlib-devel-1.3.3-6.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0097 https://rhn.redhat.com/errata/RHSA-2004-048.html https://bugzilla.fedora.us/show_bug.cgi?id=1296 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAqt6E4v2HLvE71NURAo9LAKCRbUe/+4S+RfGIqMbzZkUJolP8GgCdEEVU I8o8PPfTnIPBP/graBgWrOI= =awh4 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed May 19 04:18:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 May 2004 21:18:59 -0700 Subject: [FLSA-2004:1296] Updated pwlib resolves security vulnerability In-Reply-To: <200405182111.48879.jkeating@j2solutions.net> References: <200405182111.48879.jkeating@j2solutions.net> Message-ID: <200405182118.59606.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 May 2004 21:11, Jesse Keating wrote: > ----------------------------------------------------------------------- > Fedora Legacy Update Advisory > > Synopsis: Updated pwlib resolves security vulnerability > Advisory ID: FLSA:1296 > Issue date: 2004-05-18 > Product: Red Hat Linux > Keywords: Security > Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1296 > CVE Names: CAN-2004-0097 > ------------------------------------------ Subject was supposed to say "pwlib" not "libtool". - -- 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.3 (GNU/Linux) iD8DBQFAquAz4v2HLvE71NURArI4AKCp4oXcFugv0sF/cYw3ga1Esw1aWwCgxeXN domMEdwxuuOE805WK7bsMFE= =V8La -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Wed May 19 04:39:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 18 May 2004 23:39:40 -0500 Subject: Problem with GPG Key In-Reply-To: References: <20040503071416.GC1544@batman.gotham.krass.com> <1083568577.19508.3.camel@binkley> <19C68939-9D36-11D8-84A1-00039303286A@umn.edu> <200405031214.04274.jkeating@j2solutions.net> <138E9880-9F81-11D8-ABAC-00039303286A@umn.edu> <20040506213437.52a6214a.fedora@wir-sind-cool.org> <7C582437-A02B-11D8-918D-00039303286A@umn.edu> <1084148524.29382.26.camel@binkley> Message-ID: <20040518233940.w3p2kskgg4k48s0w@mail.ph.utexas.edu> Quoting Peter Fleck : > But when I try to use yum to update a package, it still says: > > Error: GPG Signature check failed for > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > You may want to run yum clean or remove the file: > /var/cache/yum/updates/packages/cvs-1.11.1p1-9.7.legacy.i386.rpm > You may also want to check to make sure you have the right gpg keys > Exiting. Did you try removing the file as stated, and run it again? I only see this error when: * The FL key isn't imported correctly * The file is corrupted (happened a lot when the bandwidth limit was in effect on download.fedoralegacy.org, could also be something like out of disk space, etc) In the first case, importing the key fixed it. In the second case, removing the file and trying again until I get a good download fixed it. > Any idea on what to try next? No ideas other than the above. I've seen this many times, but installing the key and/or removing the bad file and retrying (sometimes a few times) always fixed it for me. > Thanks. > ======================================================== > Peter Fleck > Webmaster | University of Minnesota Cancer Center > Dinnaken Office Bldg. > 925 Delaware St. SE > Minneapolis, MN 55414 > 612-625-8668 | fleck004 at umn.edu | www.cancer.umn.edu > Campus Mail: MMC 806 -- Eric Rostetter From skvidal at phy.duke.edu Wed May 19 05:29:54 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 19 May 2004 01:29:54 -0400 Subject: yum for RHL9 In-Reply-To: <20040517001723.M66995@mm-vanecek.cc> References: <200405161214.31043.jkeating@j2solutions.net> <20040517001723.M66995@mm-vanecek.cc> Message-ID: <1084944593.15924.6.camel@binkley> On Sun, 2004-05-16 at 19:44 -0500, Mike Vanecek wrote: > On Sun, 16 May 2004 12:14:27 -0700, Jesse Keating wrote > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Please QA my yum package for RHL9 > > > > https://bugzilla.fedora.us/show_bug.cgi?id=1604 > > > > Done. Found no errors with basic testing. However, since my system was > current, no updates were installed. > > Minor: > File these in yum bugzilla - they're not something that will be fixed in a fedora legacy yum release. -sv From jkeating at j2solutions.net Wed May 19 14:55:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 07:55:04 -0700 Subject: [FLSA-2004:1546] Updated utempter resolves security vulnerability -- Reissue: updated 8.0 version numbers Message-ID: <200405190755.04533.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated utempter resolves security vulnerability Advisory ID: FLSA:1546 Issue date: 2004-05-18 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1546 CVE Names: CAN-2004-0233 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: An updated utempter package that fixes a potential symlink vulnerability is now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Utempter is a utility that allows terminal applications such as xterm and screen to update utmp and wtmp without requiring root privileges. Steve Grubb discovered a flaw in Utempter which allowed device names containing directory traversal sequences such as '/../'. In combination with an application that trusts the utmp or wtmp files, this could allow a local attacker the ability to overwrite privileged files using a symlink. Users should upgrade to this new version of utempter, which fixes this vulnerability. Fedora Legacy would like to thank Barry K. Nathan for notification of this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1546 - utempter symlink vulnerability 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/utempter-0.5.2-10.8.0.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/utempter-0.5.2-10.8.0.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 739587d500bf401d83a5f2b01195ca8b5c81bed7 7.2/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm 021ec30fe6404f2eb74eee160a339fbd003c1b97 7.2/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm 739587d500bf401d83a5f2b01195ca8b5c81bed7 7.3/updates/SRPMS/utempter-0.5.2-6.7.x.1.legacy.src.rpm 021ec30fe6404f2eb74eee160a339fbd003c1b97 7.3/updates/i386/utempter-0.5.2-6.7.x.1.legacy.i386.rpm afc6bf313598d51e6a1ab9f83a8c1a0b244d167b 8.0/updates/SRPMS/utempter-0.5.2-10.8.0.1.legacy.src.rpm de4579faebfb0a5981be4ed2d1cf4b4ade396f41 8.0/updates/i386/utempter-0.5.2-10.8.0.1.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0233 https://rhn.redhat.com/errata/RHSA-2004-175.html https://bugzilla.fedora.us/show_bug.cgi?id=1546 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAq3VI4v2HLvE71NURAt7zAKCugdWczF79uzQXoHrIov+L2om4ZQCcCKZ+ 28f4UchcWnUiy6NAWyZsgv8= =IERI -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Wed May 19 17:39:06 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 19 May 2004 13:39:06 -0400 Subject: wu-ftpd Message-ID: <40AB9BBA.3040606@ysu.edu> I wouldn't mind seeing two bugfixes added to the wu-ftpd package. The first bugfix calls openlog() after PAM processing to reset the log name and facility in case PAM modules logged warnings or errors. This causes the syslogs to have just "ftpd" in the name instead of "ftpd LIST" or whatever. The second bugfix fixes SSL processing for active (PORT) data connections. The existing code tries to set up SSL on the passive data connection which doesn't exist. Does anyone mind if I include these bugfixes when I build wu-ftpd? Thanks, John Dalbec From francis.stevens at bristow.co.uk Wed May 19 17:39:31 2004 From: francis.stevens at bristow.co.uk (Francis Stevens) Date: Wed, 19 May 2004 18:39:31 +0100 (BST) Subject: wu-ftpd Message-ID: <20040519173931.79256580471@skirnir.bristow.co.uk> I am on leave until Tuesday 1st June, if you require urgent assistance please contact techsupport at bristow.co.uk FAS From jpdalbec at ysu.edu Wed May 19 17:43:59 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 19 May 2004 13:43:59 -0400 Subject: XFree86 Message-ID: <40AB9CDF.2030702@ysu.edu> I am working on new XFree86 packages. Unfortunately the RHL 8.0 mach build errored out on the new Xft1 fontconfig because it expected xmkmf to be in the PATH. I've changed the .spec file to give the full path to the installed copy of xmkmf in the buildroot. Hopefully this will finish building tomorrow and not error out on something else. John From jkeating at j2solutions.net Wed May 19 17:53:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 10:53:37 -0700 Subject: wu-ftpd In-Reply-To: <40AB9BBA.3040606@ysu.edu> References: <40AB9BBA.3040606@ysu.edu> Message-ID: <200405191053.40748.jkeating@j2solutions.net> On Wednesday 19 May 2004 10:39, John Dalbec wrote: > I wouldn't mind seeing two bugfixes added to the wu-ftpd package. > The first bugfix calls openlog() after PAM processing to reset the > log name and facility in case PAM modules logged warnings or errors. > This causes the syslogs to have just "ftpd" in the name instead of > "ftpd LIST" or whatever. > The second bugfix fixes SSL processing for active (PORT) data > connections. The existing code tries to set up SSL on the passive > data connection which doesn't exist. > Does anyone mind if I include these bugfixes when I build wu-ftpd? I don't see a problem with this. Are there that many people out there still using wu-ftpd? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dmongrain at chantrynetworks.com Wed May 19 21:20:31 2004 From: dmongrain at chantrynetworks.com (Dan Mongrain) Date: Wed, 19 May 2004 17:20:31 -0400 Subject: Apache/SSL security issue Message-ID: <016901c43de7$1d6cdd30$c901a8c0@toronto.chantrynetworks.com> Is there an update on this vulnerability for RedHat 8.0? Is this just a 9.0 issue? On Fri, 30 Apr 2004, Dan Mongrain wrote: > There has been an alert issued by RedHat on 9.0 > https://rhn.redhat.com/errata/RHSA-2004-182.html regarding Apache and > SSL. Will there be an update to address this issue in 8.0? Dan Mongrain dmongrain at chantrynetworks.com Team Lead - Sustain Engineering (905) 567-6900 x269 Chantry Networks (905) 567-0099 (fax) 1900 Minnesota Court, Suite 125 Mississauga, ON L5N 3C9 It's not that life is short, it's that you're dead for so long! From jkeating at j2solutions.net Wed May 19 21:19:09 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 14:19:09 -0700 Subject: Apache/SSL security issue In-Reply-To: <016901c43de7$1d6cdd30$c901a8c0@toronto.chantrynetworks.com> References: <016901c43de7$1d6cdd30$c901a8c0@toronto.chantrynetworks.com> Message-ID: <200405191419.10002.jkeating@j2solutions.net> On Wednesday 19 May 2004 14:20, Dan Mongrain wrote: > Is there an update on this vulnerability for RedHat 8.0? Is this > just a 9.0 issue? It's a RHL8 issue as well. I will be building packages tonight for QA and possible updates-testing submission. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From hbo at egbok.com Wed May 19 23:38:19 2004 From: hbo at egbok.com (Howard Owen) Date: Wed, 19 May 2004 16:38:19 -0700 (PDT) Subject: Kudos! And an Introduction Message-ID: Well, you obviously took my whining to heart. 8) Other than taking credit for something other people have done (as above, apply humor filter,) is there anything else I can do to help out the fedora-legacy project? I can analyze fixes, apply patches and sling SRPMs around. I can also write documentation. If there's a need for QA, I can consider converting a server over to an unpopular release. (7.[12]? 8.0?). I imagine you have enough 7.3 capacity, though if that's not the case, I have one server running that release. I can't remember if I gave a "self introduction" or not, so here goes. I have 18 years systems administration experience, starting on VAX/VMS in 1986. I put my first Unix system, a Sun 4/110, together in 1989. I loaded Linux for the first time on a home PC in 1993 (Slackware with kernel 0.9something, IIRC.). Linux has become increasingly important in my professional life since then, of course. I switched over to Red Hat at 5.2, and I've pretty well stuck with them since. I'm currently supporting a large multinational's 7.3 based legacy Linux distro with security patches, working for another large multinational as a contractor to the first. I also do quite a bit of other work in the Linux line on the same project. My core specialty is systems administration tools. For many years, I maintained "op", which is a sudo-like program. I recently wrote sudoscript (http://egbok.com/sudoscript) which is a system for auditing activity in a root shell using sudo(8) and script(1). The first program is in C, and the second in Perl. I have lots of experience in both, though my Perl is much more current. I'm a Linux enthusiast, as well as a Linux professional. I believe in Free Software, but I'm not a fanatic. Systems Administrators have to be practical about most things, mainly because they rarely have a choice about what their users will throw at them. 8) If anyone took offense to my earlier postings, then I apologize. The flood of new fixes is impressive. I do think large lag times in releasing fixes is a problem for users depending on a service like this. But I'm volunteering to help out all I can to reduce turnaround. I can probably give five to ten hours a week. Thanks for the useful service. As I've said before, the triage has been particularly helpful to me. Keep up the good work! -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From jkeating at j2solutions.net Thu May 20 02:57:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 19:57:17 -0700 Subject: Kudos! And an Introduction In-Reply-To: References: Message-ID: <200405191957.20420.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 19 May 2004 16:38, Howard Owen wrote: > Well, you obviously took my whining to heart. 8) Actually I just decided to let the project's actions speak for themselves rather than directly address previous emails. Certian things in my private life have cleared up and allowed me some (much needed) cycles to spend on Fedora Legacy. > Other than taking credit for something other people have done (as above, > apply humor filter,) is there anything else I can do to help out the > fedora-legacy project? I can analyze fixes, apply patches and sling > SRPMs around. I can also write documentation. If there's a need for QA, > I can consider converting a server over to an unpopular release. > (7.[12]? 8.0?). I imagine you have enough 7.3 capacity, though if that's > not the case, I have one server running that release. One of the things we need most is QA of current packages. This does include 7.2/8.0 for now, but watch for a mail soon about this. Pretty much all aspects is needed. Troll through the bugs at fedora.us/LEGACY to see my comments on them and what is needed for them. > If anyone took offense to my earlier postings, then I apologize. The > flood of new fixes is impressive. I do think large lag times in > releasing fixes is a problem for users depending on a service like this. > But I'm volunteering to help out all I can to reduce turnaround. I can > probably give five to ten hours a week. I didn't take offense at all. In fact I was rather ashamed that things too long as they have. I have not accepted any more extra work (even though the money would be nice) so that I can dedicate time to Legacy. I really appreciate your offers to help out and we could sure use them. > Thanks for the useful service. As I've said before, the triage has been > particularly helpful to me. Keep up the good work! Thanks! - -- 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.3 (GNU/Linux) iD8DBQFArB6Q4v2HLvE71NURAtNRAKDHnmdJ1zMZKPdN3tZRX7dOAYIcNgCfTmhc 0lnRyNBPHKUAcKTykuf83Ac= =NrPj -----END PGP SIGNATURE----- From mattdm at mattdm.org Thu May 20 05:14:19 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 May 2004 01:14:19 -0400 Subject: bugzilla components Message-ID: <20040520051419.GA15870@jadzia.bu.edu> Is there a reason I'm not grokking for the way the bugzilla is set up for Fedora Legacy? Right now, there's only two components: General, and Package Request. This is very different from the main fedora.us bugzilla usage (and that of Red Hat), where there's a component for each src.rpm..... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Thu May 20 05:21:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 22:21:05 -0700 Subject: bugzilla components In-Reply-To: <20040520051419.GA15870@jadzia.bu.edu> References: <20040520051419.GA15870@jadzia.bu.edu> Message-ID: <200405192221.09864.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 19 May 2004 22:14, Matthew Miller wrote: > Is there a reason I'm not grokking for the way the bugzilla is set up > for Fedora Legacy? Right now, there's only two components: General, > and Package Request. This is very different from the main fedora.us > bugzilla usage (and that of Red Hat), where there's a component for > each src.rpm..... Well, package request is for indicating a package that needs updating for one reason or another, general could be for a bug with one of the packages we touched, or something else regarding Fedora Legacy (like our website or something). - -- 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) iD8DBQFArEBF4v2HLvE71NURApJ1AJsFHE4aLpDGW4BKqZnHpK531LAf3QCfTZtR fVvcytNeWEm6I+s8rZ4rmt8= =U9OI -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu May 20 05:26:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 May 2004 22:26:36 -0700 Subject: State of 7.2/8.0 in Fedora Legacy Message-ID: <200405192226.36522.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With the recent addition of Red Hat Linux 9, and the nearing end of life of Fedora Core 1, it's becoming apparent that the Fedora Legacy project lacks the man power to properly support all these releases. After trolling through bugzilla last night, it was quickly apparent that many of the packages in limbo were waiting on RHL 7.2/8.0 builds/QA. I've made noise before about dropping 7.2/8.0 and there has always been people making noise that they didn't want to see it dropped. However I have not seen much (if any) community support for these releases. For these reasons I am more inclined than ever to drop these releases. For the most part, RHL 7.3 packages (and RHEL2.1 packages) can be rebuilt to run on 7.2, and RHL9 (RHEL3) packages can be rebuilt to run on 8.0. However without proper testing and engineering by the Fedora Legacy community it would be irresponsible for us to just do these simple steps. As we move forward, streamlining updates is absolutely necessary. In order to streamline, the bottlenecks need to be addressed, and today these road blocks (aside from me and my personal time management issues) are RHL 7.2 and RHL 8.0. So again, I broach the subject of removing these releases from official Fedora Legacy supported releases. We will still be supporting the overwhelming majority of users and it is the best use of the limited resources of the Fedora Legacy project. Please provide your (relevant) feedback. Thanks. - -- 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) iD8DBQFArEGM4v2HLvE71NURAqKEAJ45+KXrLhNugL7Vl2YJqIi/xYWShQCdGLNA wGUAnWma2/xHibppGUFDXAQ= =3FCo -----END PGP SIGNATURE----- From bluebell at bribieisland.net Thu May 20 05:34:36 2004 From: bluebell at bribieisland.net (glm) Date: Thu, 20 May 2004 15:34:36 +1000 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <40AC436C.80406@bribieisland.net> Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >With the recent addition of Red Hat Linux 9, and the nearing end of life >of Fedora Core 1, it's becoming apparent that the Fedora Legacy project >lacks the man power to properly support all these releases. > >After trolling through bugzilla last night, it was quickly apparent that >many of the packages in limbo were waiting on RHL 7.2/8.0 builds/QA. >I've made noise before about dropping 7.2/8.0 and there has always been >people making noise that they didn't want to see it dropped. However I >have not seen much (if any) community support for these releases. For >these reasons I am more inclined than ever to drop these releases. > >For the most part, RHL 7.3 packages (and RHEL2.1 packages) can be >rebuilt to run on 7.2, and RHL9 (RHEL3) packages can be rebuilt to run >on 8.0. However without proper testing and engineering by the Fedora >Legacy community it would be irresponsible for us to just do these >simple steps. > >As we move forward, streamlining updates is absolutely necessary. In >order to streamline, the bottlenecks need to be addressed, and today >these road blocks (aside from me and my personal time management >issues) are RHL 7.2 and RHL 8.0. > >So again, I broach the subject of removing these releases from official >Fedora Legacy supported releases. We will still be supporting the >overwhelming majority of users and it is the best use of the limited >resources of the Fedora Legacy project. > >Please provide your (relevant) feedback. Thanks. > >- -- >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) > >iD8DBQFArEGM4v2HLvE71NURAqKEAJ45+KXrLhNugL7Vl2YJqIi/xYWShQCdGLNA >wGUAnWma2/xHibppGUFDXAQ= >=3FCo >-----END PGP SIGNATURE----- > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > Hi Jesse, I agree with the above proposal. Thank you, glm. From stuart at serverpeak.com Thu May 20 05:42:32 2004 From: stuart at serverpeak.com (Stuart Low) Date: Thu, 20 May 2004 15:42:32 +1000 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <1085031752.3328.2.camel@localhost.localdomain> > So again, I broach the subject of removing these releases from official > Fedora Legacy supported releases. We will still be supporting the > overwhelming majority of users and it is the best use of the limited > resources of the Fedora Legacy project. Likewise, I agree with the proposal. Personally, I've upgraded any RH7.1 -> 7.2 machines through to 7.3. That process itself is fairly painless and 7.3 & 9 are the most supported legacy distros. As for RH8.. :) Why anyone would run it is beyond me and upgrading to RH9 is painless too (even remotely). :) Stuart From mkratz at internode.com.au Thu May 20 10:09:48 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Thu, 20 May 2004 19:39:48 +0930 Subject: State of 7.2/8.0 in Fedora Legacy References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> Message-ID: <002301c43e52$98cf9d80$6401a8c0@internode.com.au> > Likewise, I agree with the proposal. Personally, I've upgraded any RH7.1 > -> 7.2 machines through to 7.3. That process itself is fairly painless > and 7.3 & 9 are the most supported legacy distros. > > As for RH8.. :) Why anyone would run it is beyond me and upgrading to > RH9 is painless too (even remotely). :) I've personally got a Redhat 7.1 box and a Redhat 8 box both of which I've considered upgrading, however I'm very skeptical about doing it for fear of it stuffing up. (these boxen are in production!) :) How well does the upgrade happen? does it keep config files and so forth? -- michael From stuart at serverpeak.com Thu May 20 10:40:30 2004 From: stuart at serverpeak.com (Stuart Low) Date: Thu, 20 May 2004 20:40:30 +1000 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <002301c43e52$98cf9d80$6401a8c0@internode.com.au> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <002301c43e52$98cf9d80$6401a8c0@internode.com.au> Message-ID: <1085049629.3292.8.camel@localhost.localdomain> > I've personally got a Redhat 7.1 box and a Redhat 8 box both of which I've > considered upgrading, however I'm very skeptical about doing it for fear of > it stuffing up. (these boxen are in production!) :) > How well does the upgrade happen? does it keep config files and so forth? *nods* Obviously you SHOULD do a full system backup but yes. The Redhat RPMs use the NoConfigReplace tag to avoid overwriting machine specific configs. My experience is that they are flawless. I've even done a jump from RH7.1 -> RH9 and only had to work for about 2hrs to get all the services up and running (Apache jump from 1.3 -> 2 was the main problem). Stuart From dom at earth.li Thu May 20 11:20:23 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 20 May 2004 12:20:23 +0100 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <20040520112023.GU960@tirian.magd.ox.ac.uk> On Wed, May 19, 2004 at 10:26:36PM -0700, Jesse Keating wrote: > As we move forward, streamlining updates is absolutely necessary. In > order to streamline, the bottlenecks need to be addressed, and today > these road blocks (aside from me and my personal time management > issues) are RHL 7.2 and RHL 8.0. > > So again, I broach the subject of removing these releases from official > Fedora Legacy supported releases. We will still be supporting the > overwhelming majority of users and it is the best use of the limited > resources of the Fedora Legacy project. > > Please provide your (relevant) feedback. Thanks. I advocate removing RHL 7.2, certainly (since as people have pointed out the upgrade to 7.3 shouldn't be too painful); 8.0 I'd be less keen on removing in principle, but obviously it cannot stay in the present situation, so we should probably remove this. My personal interest in the project lies in 7.3 alone. If these products are desupported by us and there is a real demand to have updates, hopefully more people will come out of the woodwork and play an active role in the FL project. Do we have any download statistics for redhat 7.2 and 8.0 packages? In the end we have to be somewhat ruthless about this. The issue is going to come up time and time again as the older systems fall out of the limelight, and each time it will be a trade-off between supporting the older systems and getting prompt updates out for the more recent ones. In an ideal world FL would now be supporting my Redhat 5.2 box :-) Cheers, Dominic. From john.pybus at zoology.oxford.ac.uk Thu May 20 12:40:25 2004 From: john.pybus at zoology.oxford.ac.uk (John Pybus) Date: Thu, 20 May 2004 13:40:25 +0100 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <002301c43e52$98cf9d80$6401a8c0@internode.com.au> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <002301c43e52$98cf9d80$6401a8c0@internode.com.au> Message-ID: <40ACA739.2020506@zoology.oxford.ac.uk> Michael Kratz wrote: >>Likewise, I agree with the proposal. Personally, I've upgraded any RH7.1 >>-> 7.2 machines through to 7.3. That process itself is fairly painless >>and 7.3 & 9 are the most supported legacy distros. >> >>As for RH8.. :) Why anyone would run it is beyond me and upgrading to >>RH9 is painless too (even remotely). :) > > > I've personally got a Redhat 7.1 box and a Redhat 8 box both of which I've > considered upgrading, however I'm very skeptical about doing it for fear of > it stuffing up. (these boxen are in production!) :) > > How well does the upgrade happen? does it keep config files and so forth? I'd be very confident of a 7.1 -> 7.3 upgrade going without problems. Not so sure of a 7.1 -> 9 (will need some config work), and somewhere in between for an 8 -> 9 (I never put any RH8 into production, and have no real experience). Yours, John From brian.t.brunner at gai-tronics.com Thu May 20 12:48:23 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Thu, 20 May 2004 08:48:23 -0400 Subject: State of 7.2/8.0 in Fedora Legacy Message-ID: I think your idea is sound. 7.3, 9, and FC as it unfolds. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> jkeating at j2solutions.net 05/20/04 01:26AM >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With the recent addition of Red Hat Linux 9, and the nearing end of life of Fedora Core 1, it's becoming apparent that the Fedora Legacy project lacks the man power to properly support all these releases. After trolling through bugzilla last night, it was quickly apparent that many of the packages in limbo were waiting on RHL 7.2/8.0 builds/QA. I've made noise before about dropping 7.2/8.0 and there has always been people making noise that they didn't want to see it dropped. However I have not seen much (if any) community support for these releases. For these reasons I am more inclined than ever to drop these releases. http://www.redhat.com/mailman/listinfo/fedora-legacy-list ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From raphael at clifford.net Thu May 20 13:03:55 2004 From: raphael at clifford.net (Raphael Clifford) Date: Thu, 20 May 2004 14:03:55 +0100 Subject: redhat 8.0 support In-Reply-To: <20040520124043.97FCB7466E@hormel.redhat.com> References: <20040520124043.97FCB7466E@hormel.redhat.com> Message-ID: <40ACACBB.4020500@clifford.net> Hi, I would be very sad to see Redhat 8.0 support go. I am not sure my vote counts for much but I am responsible for a few redhat 8.0 sytems that are not in the same town as me so it would be tricky/dangerous for me to upgrade the whole distribution currently I feel. If Legacy suport went I would be almost entirely relying on whatever dag produces and he does not officially do security updates as far as I can tell... although that is often the effect of his upgraded packages. As I can only dedicate about an hour a week to looking after these machines your work is invaluable to me. Kind regards, Raphael From mapopa at reea.net Thu May 20 13:12:11 2004 From: mapopa at reea.net (marius popa) Date: Thu, 20 May 2004 16:12:11 +0300 Subject: redhat 8.0 support In-Reply-To: <40ACACBB.4020500@clifford.net> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40ACACBB.4020500@clifford.net> Message-ID: <40ACAEAB.2000403@reea.net> Raphael Clifford wrote: > Hi, > > I would be very sad to see Redhat 8.0 support go. I am not sure my vote > counts for much but I am responsible for a few redhat 8.0 sytems that > are not in the same town as me so it would be tricky/dangerous for me to > upgrade the whole distribution currently I feel. If Legacy suport went I > would be almost entirely relying on whatever dag produces and he does > not officially do security updates as far as I can tell... although that > is often the effect of his upgraded packages. > > As I can only dedicate about an hour a week to looking after these > machines your work is invaluable to me. Maybe for RedHat 8.0 should be left to volunteers (call it 8.0 Legancy 2) I use *old* versions 9 and 7.3 for servers Upgrade from 8.0 -> 9.0 is painless and you could choose what packages need to be left untouched (mysql,apache...) From steve at math.upatras.gr Thu May 20 13:31:57 2004 From: steve at math.upatras.gr (Steve Stavropoulos) Date: Thu, 20 May 2004 16:31:57 +0300 (EEST) Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> Message-ID: On Wed, 19 May 2004, Jesse Keating wrote: > For the most part, RHL 7.3 packages (and RHEL2.1 packages) can be > rebuilt to run on 7.2, and RHL9 (RHEL3) packages can be rebuilt to run > on 8.0. However without proper testing and engineering by the Fedora > Legacy community it would be irresponsible for us to just do these > simple steps. > Maybe you could move redhat 7.2 to an unsupported/ folder and put there the rebuilded packages which were for 7.3. I think that in 99.999% of the cases there will be no problems at all and this service will be invaluable to many. For the remaining 0.001%, well... they have been warned and I'm sure they will warn the others so the package in question will get fixed pretty quickly :) The extra time needed for this is not very much and in that way we could have several other distros (8.0 maybe?) in an almost fully supported state. I will appreciate very much such a move, as I still have a very importand server with 7.2 and I'm too afraid to upgrade (it runs far too many services and has some hacks in some places to make the upgrade more difficult). I think I'm not the only one in this state... From dom at earth.li Thu May 20 13:39:27 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 20 May 2004 14:39:27 +0100 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <20040520133927.GX960@tirian.magd.ox.ac.uk> On Thu, May 20, 2004 at 04:31:57PM +0300, Steve Stavropoulos wrote: > Maybe you could move redhat 7.2 to an unsupported/ folder and put there > the rebuilded packages which were for 7.3. I think that in 99.999% of the > cases there will be no problems at all and this service will be invaluable > to many. For the remaining 0.001%, well... they have been warned and I'm > sure they will warn the others so the package in question will get fixed > pretty quickly :) > The extra time needed for this is not very much and in that way we could > have several other distros (8.0 maybe?) in an almost fully supported > state. A better way of doing this would be to offer some unofficial advice that people should use 7.3 packages if they want to risk it. But this /will/ break stuff somewhere along the line, which means that they are worse of than if they had upgraded to redhat 7.3 or done their own packages development for their machines. Another option might be to call 7.2 and 8.0 unsupported, continue to support the uploading and QA of packages for those releases, but *not* to delay releases for 7.3 and 9. That way the really important stuff can get fixed by those who care, and it doesn't greatly affect the rest of the project (beyond the extra admin work required to rebuild and issue extra advisories) Dominic. From guallar at easternrad.com Thu May 20 13:55:43 2004 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Thu, 20 May 2004 09:55:43 -0400 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <200405200955.43596.guallar@easternrad.com> On Thursday 20 May 2004 01:26 am, Jesse Keating wrote: > With the recent addition of Red Hat Linux 9, and the nearing end of life > of Fedora Core 1, it's becoming apparent that the Fedora Legacy project > lacks the man power to properly support all these releases. > After trolling through bugzilla last night, it was quickly apparent that > many of the packages in limbo were waiting on RHL 7.2/8.0 builds/QA. > I've made noise before about dropping 7.2/8.0 and there has always been > people making noise that they didn't want to see it dropped. However I > have not seen much (if any) community support for these releases. For > these reasons I am more inclined than ever to drop these releases. > As we move forward, streamlining updates is absolutely necessary. In > order to streamline, the bottlenecks need to be addressed, and today > these road blocks (aside from me and my personal time management > issues) are RHL 7.2 and RHL 8.0. > Please provide your (relevant) feedback. Thanks. Hello, In my opinion, at least RHL 7.2 should be dropped. RHL 7.3 is just a point-release away from 7.2. No major changes are found between 7.2 and 7.3, thus providing an easy upgrade path to 7.3 RHL 7.3 is a very nice Linux release, which is widely run. So, again, in my opinion, let 7.3 be the only RHL 7.x supported by Fedora Legacy. As for RHL 8.0, I don't run it, so I will not comment on this one. Regards, Josep -- Josep L. Guallar-Esteve System and Network Administration From jkeating at j2solutions.net Thu May 20 14:19:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 07:19:05 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520112023.GU960@tirian.magd.ox.ac.uk> References: <200405192226.36522.jkeating@j2solutions.net> <20040520112023.GU960@tirian.magd.ox.ac.uk> Message-ID: <200405200719.05309.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 May 2004 04:20, Dominic Hargreaves wrote: > If these products are desupported by us and there is a real demand to > have updates, hopefully more people will come out of the woodwork and > play an active role in the FL project. Do we have any download > statistics for redhat 7.2 and 8.0 packages? I'm trying to gather some stats from our old download 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.3 (GNU/Linux) iD8DBQFArL5Z4v2HLvE71NURAiLVAJ4owY03HxTYRer7H8/TYkJxaM64lQCdH0yT Rf+U1Hz7eL6TU7oVNYkN5tM= =b/Zb -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu May 20 14:21:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 07:21:47 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: References: Message-ID: <200405200721.47540.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 May 2004 06:31, Steve Stavropoulos wrote: > Maybe you could move redhat 7.2 to an unsupported/ folder and put there > the rebuilded packages which were for 7.3. I think that in 99.999% of > the cases there will be no problems at all and this service will be > invaluable to many. For the remaining 0.001%, well... they have been > warned and I'm sure they will warn the others so the package in question > will get fixed pretty quickly :) > The extra time needed for this is not very much and in that way we > could have several other distros (8.0 maybe?) in an almost fully > supported state. This still sucks developer time to backport fixes (for things that don't really rebuild) and even though it's "unsupported" it's still coming from Fedora Legacy and thus expected to be good. Also we can't hit every update, so I would feel not so good about missing some security stuff. If we're going to turn off 7.2/8.0 it's going to be complete. I'd leave the directory trees up there, but nothingmore would be added. - -- 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.3 (GNU/Linux) iD8DBQFArL774v2HLvE71NURAn3aAJ0ePANaM9HCK2sL/8ZyUyi94NAu+wCfXg2O 80pAJQkyGS/Gn30V6n671UY= =BZ9a -----END PGP SIGNATURE----- From brian.t.brunner at gai-tronics.com Thu May 20 14:34:27 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Thu, 20 May 2004 10:34:27 -0400 Subject: State of 7.2/8.0 in Fedora Legacy Message-ID: I think Jesse points and yours have a point of harmony: If volunteers will support 7.2, then support for 7.2 remains. If we want support for 7.2 but are unwilling to do the gritty work to make this happen, then dropping 7.2 is the right thing to do. Would you rather do the 7.2 work, upgrade, or live unsupported? I think that's the 7.2/8 state. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> steve at math.upatras.gr 05/20/04 09:31AM >>> On Wed, 19 May 2004, Jesse Keating wrote: I will appreciate very much such a move, as I still have a very importand server with 7.2 and I'm too afraid to upgrade ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From villegas at math.gatech.edu Thu May 20 15:05:33 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Thu, 20 May 2004 11:05:33 -0400 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <20040520150533.GI6899@math30192.math.gatech.edu> I agree this releases have to be dropped if no one is really willing to put the time and energy required, so if we're voting this is my vote. Carlos PS: My interest is only in 9 and FC releases, so this might seem a little selfish, but I do agree that resources are limited and should not be wasted. From barryn at pobox.com Thu May 20 15:31:21 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 20 May 2004 08:31:21 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <20040520153121.GA2350@ip68-4-98-123.oc.oc.cox.net> On Wed, May 19, 2004 at 10:26:36PM -0700, Jesse Keating wrote: [snip...] > As we move forward, streamlining updates is absolutely necessary. In > order to streamline, the bottlenecks need to be addressed, and today > these road blocks (aside from me and my personal time management > issues) are RHL 7.2 and RHL 8.0. [snip] > Please provide your (relevant) feedback. Thanks. IME it's possible to "upgrade" a machine from RHL 7.2 to recompiled RHEL 2.1 clones (such as CentOS-2) relatively easily. This is not the case for RHL 7.3; many major RHL 7.3 components are newer than what shipped with RHL 7.2 and RHEL 2.1 (e.g. KDE 3.0 vs. 2.2, glibc 2.2.5 vs. 2.2.4). However, it's better to support a few releases well than many releases poorly, and it seems like many more people are running 7.3 than 7.2, so dropping 7.2 might be a good idea. FWIW, I don't yet know whether I'll need support for RHL 8.0. I know that at work, some people had various software compatibility problems due to NPTL in RHL 9. I don't remember the exact details, except that LD_ASSUME_KERNEL worked for some software, but not all (even booting into an NPTL-incapable kernel didn't fix all problems); vendors had to provide updates for the rest of the software. I *assume* there are now updates available for everything that can't be fixed with LD_ASSUME_KERNEL, but I won't know for a fact until I find and upgrade all the 8.0 boxes... However, I can't justify spending time on build or QA work for RHL 8.0 until I find a box that absolutely cannot be upgraded -- if such a box even exists -- so if there aren't many other people who need 8.0 for glibc-related reasons, then I have no problem with 8.0 being dropped. -Barry K. Nathan From barryn at pobox.com Thu May 20 15:47:38 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 20 May 2004 08:47:38 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520153121.GA2350@ip68-4-98-123.oc.oc.cox.net> References: <200405192226.36522.jkeating@j2solutions.net> <20040520153121.GA2350@ip68-4-98-123.oc.oc.cox.net> Message-ID: <20040520154738.GB2350@ip68-4-98-123.oc.oc.cox.net> On Thu, May 20, 2004 at 08:31:21AM -0700, Barry K. Nathan wrote: > However, I can't justify spending time on build or QA work for RHL > 8.0 until I find a box that absolutely cannot be upgraded -- if such a > box even exists -- so if there aren't many other people who need 8.0 for > glibc-related reasons, then I have no problem with 8.0 being dropped. (Sorry about replying to myself) Ugh, I just realized I forgot about the Progeny service. So, even if FL drops 8.0, Progeny is still there for anyone who *really* needs it for some mission-critical reason. Given how limited the FL resources are, dropping 8.0 might be a really good idea. -Barry K. Nathan From rostetter at mail.utexas.edu Thu May 20 16:33:57 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 11:33:57 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405192226.36522.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> Message-ID: <20040520113357.vx00c4kg0wos0sgw@mail.ph.utexas.edu> Quoting Jesse Keating : > With the recent addition of Red Hat Linux 9, and the nearing end of life > of Fedora Core 1, it's becoming apparent that the Fedora Legacy project > lacks the man power to properly support all these releases. With the EOL of RHL 9, and nearing EOL of FC1, we should expect to pick up more man power. But it may still not be aimed at the needed areas, so it may not help much with the question at hand. > After trolling through bugzilla last night, it was quickly apparent that > many of the packages in limbo were waiting on RHL 7.2/8.0 builds/QA. Mostly QA IMHO. > I've made noise before about dropping 7.2/8.0 and there has always been > people making noise that they didn't want to see it dropped. Of course I don't want to see it dropped. But that doesn't mean it shouldn't be dropped. Just because it is useful to 10% of the community doesn't mean it should hold up the other 90% of the community. But as part of the 10% of course I don't want to see it dropped. That doesn't mean I would fight to stop it, as I can see the reality of the situation. > However I > have not seen much (if any) community support for these releases. For > these reasons I am more inclined than ever to drop these releases. I understand that, in particular for RH 8.0. 7.2 support is easier than 8.0 support, so I think they may need to be discussed seperately. > For the most part, RHL 7.3 packages (and RHEL2.1 packages) can be > rebuilt to run on 7.2, and RHL9 (RHEL3) packages can be rebuilt to run > on 8.0. However without proper testing and engineering by the Fedora > Legacy community it would be irresponsible for us to just do these > simple steps. Yes, we at least need a large amount of QA testing of the rebuilds or it would indeed be irresponsible to do so (since the goals are security and stability). > As we move forward, streamlining updates is absolutely necessary. In > order to streamline, the bottlenecks need to be addressed, and today > these road blocks (aside from me and my personal time management > issues) are RHL 7.2 and RHL 8.0. Agreed, though I'm not sure if we need to address them now, or later. But they do need to be addressed as we move forward. > So again, I broach the subject of removing these releases from official > Fedora Legacy supported releases. We will still be supporting the > overwhelming majority of users and it is the best use of the limited > resources of the Fedora Legacy project. I would be sad to see RH 8.0 dropped, but I understand why you want to do so, and I would accept such a decision by the FL community. Truth is I only have 1 RH 8.0 server, so it isn't a real big deal to me. (I do have a handful of RH 8.0 laptops/desktops, but I can upgrade them to 9 without any problem, so that isn't even a consideration). I'd have a hard time telling FL to support my single RH 8.0 server, which I could easily do myself based on the 7.3 and 9 updates being provided. > Please provide your (relevant) feedback. Thanks. I'll let others address the 7.2 issues. I think they really differ from the 8.0 issues in many ways. But given the limited release of 8.0, and the lack of QA testers for it, I'd have to say I'm okay with it being dropped. I'd consider it a failure of the community to support FL, and not a failure of the FL core team/community which does exist, if this came to pass. > - -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > GPG Public Key > (http://geek.j2solutions.net/jkeating.j2solutions.pub) -- Eric Rostetter From jjasen at realityfailure.org Thu May 20 17:04:24 2004 From: jjasen at realityfailure.org (John Jasen) Date: Thu, 20 May 2004 13:04:24 -0400 (EDT) Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <1085049629.3292.8.camel@localhost.localdomain> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <002301c43e52$98cf9d80$6401a8c0@internode.com.au> <1085049629.3292.8.camel@localhost.localdomain> Message-ID: On Thu, 20 May 2004, Stuart Low wrote: > > I've personally got a Redhat 7.1 box and a Redhat 8 box both of which I've > > considered upgrading, however I'm very skeptical about doing it for fear of > > it stuffing up. (these boxen are in production!) :) > > How well does the upgrade happen? does it keep config files and so forth? > > *nods* Obviously you SHOULD do a full system backup but yes. The Redhat > RPMs use the NoConfigReplace tag to avoid overwriting machine specific > configs. I have done live upgrades from 7.1 to 7.3 using apt-get and a little rpm --nodeps --force. It's a bit scary from that perspective, but a general upgrade should be much less heart-wrenching. :) rh 6.2 to 9 ... now _that_ was gut-wrenching ... -- -- John E. Jasen (jjasen at realityfailure.org) -- No one will sorrow for me when I die, because those who would -- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring From mattdm at mattdm.org Thu May 20 17:21:40 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 May 2004 13:21:40 -0400 Subject: bugzilla components In-Reply-To: <200405192221.09864.jkeating@j2solutions.net> References: <20040520051419.GA15870@jadzia.bu.edu> <200405192221.09864.jkeating@j2solutions.net> Message-ID: <20040520172140.GA31611@jadzia.bu.edu> On Wed, May 19, 2004 at 10:21:05PM -0700, Jesse Keating wrote: > Well, package request is for indicating a package that needs updating > for one reason or another, general could be for a bug with one of the > packages we touched, or something else regarding Fedora Legacy (like > our website or something). :) Yeah, I understand that. But why isn't there a component for each source RPM? I find that to be the most helpful way to track things. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kelson at speed.net Thu May 20 17:15:31 2004 From: kelson at speed.net (Kelson Vibber) Date: Thu, 20 May 2004 10:15:31 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520113357.vx00c4kg0wos0sgw@mail.ph.utexas.edu> References: <200405192226.36522.jkeating@j2solutions.net> <20040520113357.vx00c4kg0wos0sgw@mail.ph.utexas.edu> Message-ID: <6.1.0.6.0.20040520095345.02537ec8@mail.speed.net> At 09:33 AM 5/20/2004, Eric Rostetter wrote: >Of course I don't want to see it dropped. But that doesn't mean it shouldn't >be dropped. Just because it is useful to 10% of the community doesn't mean >it should hold up the other 90% of the community. But as part of the 10% >of course I don't want to see it dropped. That doesn't mean I would fight >to stop it, as I can see the reality of the situation. If the choice is between a poor release schedule for all four RHL versions, or a good release schedule for 7.3 and 9, I'd pick the good release schedule. As has been mentioned before, upgrading from 7.2 to 7.3 or from 8.0 to 9 is generally simple, the only real pain for most people being that of taking the system offline to upgrade. (Disclaimer: all our RHL systems are running 7.3 and 9, so the decision doesn't affect us either way.) I don't know what the success rate is for upgrading 7.2->7.3 or 8.0->9 using yum or apt-get dist-upgrade, but if it's high enough, perhaps posting directions on doing so would be valuable. That would eliminate most of the downtime (since it could be done on a live system and require only a reboot). Others have suggested an "unsupported" tree for 7.2 and 8.0 - basically dispensing with the QA. How about a two-tiered QA? Set up a plan so that if packages for the first-tier releases are done, but packages for second-tier releases aren't after X days, release all the ones that *are* finished with a note that "RHL 8.0 is also vulnerable, but updates are still being tested." Then once the remaining packages *are* done, release the new package and re-release the advisory. On the other hand, this idea may turn out to be more work than doing the QA in the first place. Kelson Vibber SpeedGate Communications From rostetter at mail.utexas.edu Thu May 20 18:06:20 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 13:06:20 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <1085031752.3328.2.camel@localhost.localdomain> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> Message-ID: <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> Quoting Stuart Low : > As for RH8.. :) Why anyone would run it is beyond me and upgrading to > RH9 is painless too (even remotely). :) I run it on a server. I had a need for the functionality in it that wasn't available in RHL 7.x, and RHL 9 wasn't out yet, and RH had not yet revealed their EOL scheme. Because I can't take it down in the school year, I've been stuck with it. Now that the school year is coming to a close, I can think about moving it to RH 9 finally. If RH had provided an upgrade (rather than migration) to RHEL I'd do it. It is the fact that you need to do a fresh install to move to RHEL that really makes a lot of us stay with RHL instead. Our upgrade windows can be too small, our pool of additional test hardware to limited, and the servers too customized over time, to make a re-install from scratch feasible. Besides, it is stable, and I've heard a lot of complaints about RHEL 3.0 not being stable on this particular machine model. I don't think I'll have any problems moving to RHL 9 on it though, and will try to do so sometime this summer (probably sometime in the next 3 weeks). This will be even more pressing if FL drops RHL 8.0 support. > Stuart -- Eric Rostetter From jkeating at j2solutions.net Thu May 20 18:16:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 11:16:02 -0700 Subject: bugzilla components In-Reply-To: <20040520172140.GA31611@jadzia.bu.edu> References: <20040520051419.GA15870@jadzia.bu.edu> <200405192221.09864.jkeating@j2solutions.net> <20040520172140.GA31611@jadzia.bu.edu> Message-ID: <200405201116.02316.jkeating@j2solutions.net> On Thursday 20 May 2004 10:21, Matthew Miller wrote: > :) Yeah, I understand that. > > But why isn't there a component for each source RPM? I find that to > be the most helpful way to track things. Because I don't have access to add components, and this is very tedious work. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mattdm at mattdm.org Thu May 20 18:26:20 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 May 2004 14:26:20 -0400 Subject: bugzilla components In-Reply-To: <200405201116.02316.jkeating@j2solutions.net> References: <20040520051419.GA15870@jadzia.bu.edu> <200405192221.09864.jkeating@j2solutions.net> <20040520172140.GA31611@jadzia.bu.edu> <200405201116.02316.jkeating@j2solutions.net> Message-ID: <20040520182620.GA1098@jadzia.bu.edu> On Thu, May 20, 2004 at 11:16:02AM -0700, Jesse Keating wrote: > > But why isn't there a component for each source RPM? I find that to > > be the most helpful way to track things. > Because I don't have access to add components, and this is very tedious > work. If it would help, I have a quick kludgy perl script that adds components from a file. (Run it on the bugzilla server, of course.) Adding them all by hand definitely would be incredibly tedious! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From heinlein at cse.ogi.edu Thu May 20 18:55:39 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Thu, 20 May 2004 11:55:39 -0700 (PDT) Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> Message-ID: On Thu, 20 May 2004, Eric Rostetter wrote: > Quoting Stuart Low : > >> As for RH8.. :) Why anyone would run it is beyond me and upgrading >> to RH9 is painless too (even remotely). :) > > I run it on a server. I do, too. It provides Mailman, SquirrelMail, LDAP, NTP, and Squid services for a few hundred users. I've got it slated for a summertime upgrade, but it's a nonstarter to suggest bringing it down during the academic year. --Paul Heinlein From jcrowe at sagesys.net Thu May 20 21:09:25 2004 From: jcrowe at sagesys.net (Jonathan Crowe) Date: Thu, 20 May 2004 14:09:25 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040520124043.97FCB7466E@hormel.redhat.com> References: <20040520124043.97FCB7466E@hormel.redhat.com> Message-ID: <40AD1E85.5080500@sagesys.net> I have five servers running RedHat 7.3 and two running RedHat 9. I also have a three desktop machines running FC1. I think that the Fedora Legacy project should support 7.3 and 9.0 before worrying about FC1. Even though it would be nice to not have to upgrade the FC1 machines until FC2 has been around for a while (and through several rounds of bug fixes), they are, after all, not servers. Even through it has been solid for me on the desktop, when it came out FC1 was billed as an unstable release. I suspect that for the most part people have not installed it on servers. Jesse Keating wrote: >So again, I broach the subject of removing these releases from official >Fedora Legacy supported releases. We will still be supporting the >overwhelming majority of users and it is the best use of the limited >resources of the Fedora Legacy project. > >Please provide your (relevant) feedback. Thanks. -- Jonathan Crowe System Administrator for Sage Systems, Inc. 425-451-2484 x 3025 From rostetter at mail.utexas.edu Thu May 20 21:23:37 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 16:23:37 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <002301c43e52$98cf9d80$6401a8c0@internode.com.au> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <002301c43e52$98cf9d80$6401a8c0@internode.com.au> Message-ID: <20040520162337.lkl5w0sc0kc0w0w4@mail.ph.utexas.edu> Quoting Michael Kratz : > I've personally got a Redhat 7.1 box and a Redhat 8 box both of which I've > considered upgrading, however I'm very skeptical about doing it for fear of > it stuffing up. (these boxen are in production!) :) It is going to depend on the services you run, etc. > How well does the upgrade happen? does it keep config files and so forth? Depends on your services, etc. 7.1 to 7.3 shouldn't be a big deal. 7.x to 8.x has some things to watch for (wu-ftp -> vsftp, apache 1.x to apache 2.x come to mind) which can cause upgrade problems for you if you use those services. For me, it is more of a customization issue than a technical issue. I've got lots of custom software that I need to keep intact. > -- > michael -- Eric Rostetter From howen at cisco.com Thu May 20 22:03:37 2004 From: howen at cisco.com (Howard B Owen) Date: Thu, 20 May 2004 15:03:37 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> Message-ID: <1085090617.20034.29.camel@quirk.cisco.com> There are very economical commercial patch services for legacy systems. If it's one server, five bucks a month (six month minimum) will get you Progeny Transition Service support. (http://transition.progeny.com) If you are planning to upgrade after the spring quarter, it sounds like all you would need would be sixty bucks. That's another thing to consider when thinking about support by Fedora Legacy for less popular releases. There are commercial services at very reasonable prices that can take up the slack. Where it gets unreasonable for an organization with limited resources is when there are hundreds of servers. If the budget is there, Progenys price of $2500/month for unlimited servers is pretty reasonable. But academic departments, or medium to large organizations outside Europe/Asia/North America probably can't even consider a quarter of that cost. The point is, the more popular releases are more likely to be deployed on a larger number of servers. Apart from the project resource issues, concentrating on the releases with a greater installed base may provide most of the value in places where money is tight. On Thu, 2004-05-20 at 11:55, Paul Heinlein wrote: > On Thu, 20 May 2004, Eric Rostetter wrote: > > > Quoting Stuart Low : > > > >> As for RH8.. :) Why anyone would run it is beyond me and upgrading > >> to RH9 is painless too (even remotely). :) > > > > I run it on a server. > > I do, too. It provides Mailman, SquirrelMail, LDAP, NTP, and Squid > services for a few hundred users. I've got it slated for a summertime > upgrade, but it's a nonstarter to suggest bringing it down during the > academic year. > > --Paul Heinlein > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Howard Owen - Linux Architect "Even if you are on the right IBM Global Services - Cisco Linux track, you'll get run over if you howen at cisco.com +1-408-853-1381 just sit there." - Will Rogers From dwb7 at ccmr.cornell.edu Thu May 20 22:08:52 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 20 May 2004 18:08:52 -0400 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <1085090617.20034.29.camel@quirk.cisco.com> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> <1085090617.20034.29.camel@quirk.cisco.com> Message-ID: <20040520220852.GA18802@ccmr.cornell.edu> So, what are some of these other services? We would certainly like to know. We're one of the places where keeping all our stuff up at either Progeny's $5/machine/month or their $2500/month unlimited is just too much money (and they were absolutely unwilling to negotiate any type of academic rate). For my home systems, I definitely might consider them, however. On Thu, May 20, 2004 at 03:03:37PM -0700, Howard B Owen wrote: > There are very economical commercial patch services for legacy systems. > If it's one server, five bucks a month (six month minimum) will get you > Progeny Transition Service support. (http://transition.progeny.com) If > you are planning to upgrade after the spring quarter, it sounds like all > you would need would be sixty bucks. > > That's another thing to consider when thinking about support by Fedora > Legacy for less popular releases. There are commercial services at very > reasonable prices that can take up the slack. Where it gets unreasonable > for an organization with limited resources is when there are hundreds of > servers. If the budget is there, Progenys price of $2500/month for > unlimited servers is pretty reasonable. But academic departments, or > medium to large organizations outside Europe/Asia/North America probably > can't even consider a quarter of that cost. > > The point is, the more popular releases are more likely to be deployed > on a larger number of servers. Apart from the project resource issues, > concentrating on the releases with a greater installed base may provide > most of the value in places where money is tight. > > On Thu, 2004-05-20 at 11:55, Paul Heinlein wrote: > > On Thu, 20 May 2004, Eric Rostetter wrote: > > > > > Quoting Stuart Low : > > > > > >> As for RH8.. :) Why anyone would run it is beyond me and upgrading > > >> to RH9 is painless too (even remotely). :) > > > > > > I run it on a server. > > > > I do, too. It provides Mailman, SquirrelMail, LDAP, NTP, and Squid > > services for a few hundred users. I've got it slated for a summertime > > upgrade, but it's a nonstarter to suggest bringing it down during the > > academic year. > > > > --Paul Heinlein > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- > Howard Owen - Linux Architect "Even if you are on the right > IBM Global Services - Cisco Linux track, you'll get run over if you > howen at cisco.com +1-408-853-1381 just sit there." - Will Rogers > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From marcdeslauriers at videotron.ca Thu May 20 22:23:50 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 20 May 2004 18:23:50 -0400 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <40AD1E85.5080500@sagesys.net> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40AD1E85.5080500@sagesys.net> Message-ID: <1085091830.12795.1.camel@mdlinux> On Thu, 2004-05-20 at 17:09, Jonathan Crowe wrote: > Even though it would be nice to not have to upgrade the FC1 machines > until FC2 has been around for a while (and through several rounds of bug > fixes), they are, after all, not servers. > > Even through it has been solid for me on the desktop, when it came out > FC1 was billed as an unstable release. I suspect that for the most > part people have not installed it on servers. Unstable release? I know a _bunch_ of people running FC1 on servers depending on FL to get patches out when RH stops. Marc. From hbo at egbok.com Thu May 20 22:30:28 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 15:30:28 -0700 (PDT) Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520220852.GA18802@ccmr.cornell.edu> Message-ID: Right. At $2500/month you could hire a couple of gradual students to comb the lists for for you. 8) My point is that Fedora Legacy can fill the gap. It needs to be more timely, though. One of the ways to make it so is to drop releases for which there are fewer installed systems. Do you run a lot of 7.2 or 8.0 systems? How many? I'm hypothesizing on the basis of a couple of givens: that there are fewer 7.2 and 8.0 systems in use than 7.3 and 9, and that the installed base ratio is similar among organizations that have too many servers to be able to afford Progeny. If that's true, then the hypothesis is that dropping 7.2 and 8.0 will save more of those organizations money than if the project bogs down and can't deliver timely support for *any* distribution. On Thu, 20 May 2004, David Botsch wrote: > So, what are some of these other services? We would certainly like to know. > > We're one of the places where keeping all our stuff up at either Progeny's > $5/machine/month or their $2500/month unlimited is just too much money > (and they were absolutely unwilling to negotiate any type of academic rate). > > For my home systems, I definitely might consider them, however. > > On Thu, May 20, 2004 at 03:03:37PM -0700, Howard B Owen wrote: > > There are very economical commercial patch services for legacy systems. > > If it's one server, five bucks a month (six month minimum) will get you > > Progeny Transition Service support. (http://transition.progeny.com) If > > you are planning to upgrade after the spring quarter, it sounds like all > > you would need would be sixty bucks. > > > > That's another thing to consider when thinking about support by Fedora > > Legacy for less popular releases. There are commercial services at very > > reasonable prices that can take up the slack. Where it gets unreasonable > > for an organization with limited resources is when there are hundreds of > > servers. If the budget is there, Progenys price of $2500/month for > > unlimited servers is pretty reasonable. But academic departments, or > > medium to large organizations outside Europe/Asia/North America probably > > can't even consider a quarter of that cost. > > > > The point is, the more popular releases are more likely to be deployed > > on a larger number of servers. Apart from the project resource issues, > > concentrating on the releases with a greater installed base may provide > > most of the value in places where money is tight. > > > > On Thu, 2004-05-20 at 11:55, Paul Heinlein wrote: > > > On Thu, 20 May 2004, Eric Rostetter wrote: > > > > > > > Quoting Stuart Low : > > > > > > > >> As for RH8.. :) Why anyone would run it is beyond me and upgrading > > > >> to RH9 is painless too (even remotely). :) > > > > > > > > I run it on a server. > > > > > > I do, too. It provides Mailman, SquirrelMail, LDAP, NTP, and Squid > > > services for a few hundred users. I've got it slated for a summertime > > > upgrade, but it's a nonstarter to suggest bringing it down during the > > > academic year. > > > > > > --Paul Heinlein > > > > > > > > > -- > > > fedora-legacy-list mailing list > > > fedora-legacy-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- > > Howard Owen - Linux Architect "Even if you are on the right > > IBM Global Services - Cisco Linux track, you'll get run over if you > > howen at cisco.com +1-408-853-1381 just sit there." - Will Rogers > > > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From rostetter at mail.utexas.edu Thu May 20 22:38:09 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 17:38:09 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: References: Message-ID: <20040520173809.5m4o4448k0k0c488@mail.ph.utexas.edu> Quoting Steve Stavropoulos : > Maybe you could move redhat 7.2 to an unsupported/ folder and put there > the rebuilded packages which were for 7.3. That is a subject worth discussion. Also for RH 8.0. We'd need a large disclaimer for it though... -- Eric Rostetter From rostetter at mail.utexas.edu Thu May 20 22:41:07 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 17:41:07 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520133927.GX960@tirian.magd.ox.ac.uk> References: <200405192226.36522.jkeating@j2solutions.net> <20040520133927.GX960@tirian.magd.ox.ac.uk> Message-ID: <20040520174107.4k6osgcs84kkk0g4@mail.ph.utexas.edu> Quoting Dominic Hargreaves : > A better way of doing this would be to offer some unofficial advice that > people should use 7.3 packages if they want to risk it. I don't think that is better. And it would have to be advice to rebuild the src rpm packages, not to use the binary rpm packages. > Another option might be to call 7.2 and 8.0 unsupported, continue to > support the uploading and QA of packages for those releases, but *not* > to delay releases for 7.3 and 9. I kind of see that as really what the first proposal was about, though it didn't say it exactly/explicitely. > That way the really important stuff can > get fixed by those who care, and it doesn't greatly affect the rest of > the project (beyond the extra admin work required to rebuild and issue > extra advisories) It's certainly worth discussion. > Dominic. -- Eric Rostetter From rostetter at mail.utexas.edu Thu May 20 22:47:45 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 17:47:45 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405200721.47540.jkeating@j2solutions.net> References: <200405200721.47540.jkeating@j2solutions.net> Message-ID: <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> Quoting Jesse Keating : > This still sucks developer time to backport fixes (for things that don't > really rebuild) and even though it's "unsupported" it's still coming from > Fedora Legacy and thus expected to be good. Wasn't AS 2.1 built off RHL 7.2? So wouldn't the patches be fairly easy to come by in most cases? I think that was the argument before... No such argument for RHL 8.0 though. It is different enough that backporting patches is non-trivial. > Also we can't hit every > update, so I would feel not so good about missing some security stuff. Why not? I don't think there is anything in 7.2 that isn't in 7.3, is there? And if 7.2 does follow AS 2.1, then it should be pretty easy to track... > If we're going to turn off 7.2/8.0 it's going to be complete. I'd leave > the directory trees up there, but nothingmore would be added. Not arguing that, just think we should discuss both options before we decide. My memory is a little vague as to the AS 2.1 tracking though, so correct me if I'm wrong... -- Eric Rostetter From jkeating at j2solutions.net Thu May 20 22:44:28 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 15:44:28 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520173809.5m4o4448k0k0c488@mail.ph.utexas.edu> References: <20040520173809.5m4o4448k0k0c488@mail.ph.utexas.edu> Message-ID: <200405201544.31287.jkeating@j2solutions.net> On Thursday 20 May 2004 15:38, Eric Rostetter wrote: > Quoting Steve Stavropoulos : > > Maybe you could move redhat 7.2 to an unsupported/ folder and put > > there the rebuilded packages which were for 7.3. > > That is a subject worth discussion. Also for RH 8.0. We'd need a > large disclaimer for it though... rebuilding/building packages still takes developer resources. My stance is all or nothing. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pmatilai at welho.com Thu May 20 22:52:46 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 21 May 2004 01:52:46 +0300 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> References: <200405200721.47540.jkeating@j2solutions.net> <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> Message-ID: <1085093566.5103.6.camel@weasel.net.laiskiainen.org> On Fri, 2004-05-21 at 01:47, Eric Rostetter wrote: > Quoting Jesse Keating : > > > This still sucks developer time to backport fixes (for things that don't > > really rebuild) and even though it's "unsupported" it's still coming from > > Fedora Legacy and thus expected to be good. > > Wasn't AS 2.1 built off RHL 7.2? So wouldn't the patches be fairly easy > to come by in most cases? I think that was the argument before... Indeed it's based on RHL 7.2 so for most packages supporting 7.2 should be quite easy using AS 2.1 updates. - Panu - From hbo at egbok.com Thu May 20 22:53:10 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 15:53:10 -0700 (PDT) Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <1085091830.12795.1.camel@mdlinux> Message-ID: Point three of the Fedora objectives (http://fedora.redhat.com/about/objectives) says: "3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages." This is less conservative than a distribution designed to run for years performing a particular workload. The word "unstable" isn't mentioned in the objectives, but point one of the "non-objectives" is: "1. Slow rate of change." OTOH, point seven of the objectives is: "7. Promote rapid adoption of new releases by maintaining easy upgradeability, with minimal disturbances to configuration changes." I can attest that the FC1-FC2 upgrade worked extremely well for me. I had to turn off acpi because of my old SMP hardware, but other than that change to grub.conf, I made no configuration changes at all, and it Just Worked(tm). For the leap in kernel technology the upgrade represented, I think that's remarkable. Businesses I have knowledge of have shied away from Fedora Core because of the rapid rate of change issue. In my opinion, folks who have taken the plunge with FC1 on production machines really need to seriously consider upgrading to FC2. This is in line with the objectives quoted above. Red Hat and the volunteers at the Fedora project seem to have tried awfully hard to make that as smooth as possible. (c.f. *not turning on SELinux by default.) On Thu, 20 May 2004, Marc Deslauriers wrote: > > On Thu, 2004-05-20 at 17:09, Jonathan Crowe wrote: > > Even though it would be nice to not have to upgrade the FC1 machines > > until FC2 has been around for a while (and through several rounds of bug > > fixes), they are, after all, not servers. > > > > Even through it has been solid for me on the desktop, when it came out > > FC1 was billed as an unstable release. I suspect that for the most > > part people have not installed it on servers. > > Unstable release? > > I know a _bunch_ of people running FC1 on servers depending on FL to get > patches out when RH stops. > > Marc. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From marcdeslauriers at videotron.ca Thu May 20 22:55:27 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 20 May 2004 18:55:27 -0400 Subject: Self-Introduction: Marc Deslauriers Message-ID: <1085093727.12795.14.camel@mdlinux> Hi all. 1- Marc Deslauriers 2- Qu?bec, Canada 3- Computer Security Consultant 4- Informatique Strat?gique IS 5- I am interested in creating packages with security fixes for mostly RH9 and FC1 (in the future). I may also be interested in making packages for RH7.3. I think Fedora Legacy is great and am using packages from it to upgrade some of our customers servers. I've decided to volunteer my help as there seems to be a need for a few more people. 6- As far as projects I've been involved in, I have submitted a few patches here and there. I have been making custom packages for our customers for the past six years. I can program in C/C++, Perl, PHP, shell scripting, etc. I have working knowledge of security related patches and rpm packaging. 7- pub 1024D/40B8CCDA 2004-04-28 Marc Deslauriers Key fingerprint = FE27 D137 99A5 EE00 C34E 8B4C 2CC0 2CFF 40B8 CCDA sub 1024g/2036F883 2004-04-28 From jkeating at j2solutions.net Thu May 20 22:52:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 15:52:14 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> References: <200405200721.47540.jkeating@j2solutions.net> <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> Message-ID: <200405201552.14162.jkeating@j2solutions.net> On Thursday 20 May 2004 15:47, Eric Rostetter wrote: > Wasn't AS 2.1 built off RHL 7.2? So wouldn't the patches be fairly > easy to come by in most cases? I think that was the argument > before... > > No such argument for RHL 8.0 though. It is different enough that > backporting patches is non-trivial. Sortof. It was built between 7.2 and 7.3, and diverged from there. Not everything is the same. Base source versions on 7.2 is not always the same in RHAS 2.1 and RHL7.3. This requires patches be backported and people QA the packages and test them in updates-testing. We get almost none of that now. > > Also we can't hit every > > update, so I would feel not so good about missing some security > > stuff. > > Why not? I don't think there is anything in 7.2 that isn't in 7.3, > is there? And if 7.2 does follow AS 2.1, then it should be pretty > easy to track... See reasons above. Some things are older source versions and need backported patches that nobody is willing to do. > > If we're going to turn off 7.2/8.0 it's going to be complete. I'd > > leave the directory trees up there, but nothingmore would be added. > > Not arguing that, just think we should discuss both options before we > decide. My memory is a little vague as to the AS 2.1 tracking though, > so correct me if I'm wrong.. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu May 20 22:52:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 15:52:54 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <1085093566.5103.6.camel@weasel.net.laiskiainen.org> References: <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> <1085093566.5103.6.camel@weasel.net.laiskiainen.org> Message-ID: <200405201552.54140.jkeating@j2solutions.net> On Thursday 20 May 2004 15:52, Panu Matilainen wrote: > Indeed it's based on RHL 7.2 so for most packages supporting 7.2 > should be quite easy using AS 2.1 updates. Correct most. Not all. And thats my point. I'm not going to provide 'most' updates for the release. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From kelson at speed.net Thu May 20 22:40:28 2004 From: kelson at speed.net (Kelson Vibber) Date: Thu, 20 May 2004 15:40:28 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <1085091830.12795.1.camel@mdlinux> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40AD1E85.5080500@sagesys.net> <1085091830.12795.1.camel@mdlinux> Message-ID: <6.1.0.6.0.20040520152609.02743de0@mail.speed.net> At 03:23 PM 5/20/2004, Marc Deslauriers wrote: >Unstable release? > >I know a _bunch_ of people running FC1 on servers depending on FL to get >patches out when RH stops. Blame Red Hat marketing. I think they're deathly afraid people will keep using Fedora Core the same way they were using the free RHL. Hence, the warnings about FC stability, in hopes that people will move to RHEL instead. Of course, what's happened instead is a mass (or at least noisy) exodus to SuSE and Debian, with a lot of people moving to Fedora Core anyway and others moving to RHEL clones like cAos, Whitebox, etc. "It will eat your braaane!" Kelson Vibber SpeedGate Communications From jkeating at j2solutions.net Thu May 20 22:56:49 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 15:56:49 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: References: Message-ID: <200405201556.49442.jkeating@j2solutions.net> On Thursday 20 May 2004 15:53, Howard Owen wrote: > Businesses I have knowledge of have shied away from Fedora Core > because of the rapid rate of change issue. In my opinion, folks who > have taken the plunge with FC1 on production machines really need to > seriously consider upgrading to FC2. This is in line with the > objectives quoted above. Red Hat and the volunteers at the Fedora > project seem to have tried awfully hard to make that as smooth as > possible. (c.f. *not turning on SELinux by default.) Sure there is a rapid change rate. Fedora Legacy was originally concieved to provide a longer life span for Fedora Core releases. The support for RHL 7.3/9 is just a byproduct of this, an added bonus. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From hbo at egbok.com Thu May 20 23:08:16 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 16:08:16 -0700 (PDT) Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <200405201556.49442.jkeating@j2solutions.net> Message-ID: I know you've thought about what it will mean to support three releases a year, *every year*. How about picking just one a year? On Thu, 20 May 2004, Jesse Keating wrote: > On Thursday 20 May 2004 15:53, Howard Owen wrote: > > Businesses I have knowledge of have shied away from Fedora Core > > because of the rapid rate of change issue. In my opinion, folks who > > have taken the plunge with FC1 on production machines really need to > > seriously consider upgrading to FC2. This is in line with the > > objectives quoted above. Red Hat and the volunteers at the Fedora > > project seem to have tried awfully hard to make that as smooth as > > possible. (c.f. *not turning on SELinux by default.) > > Sure there is a rapid change rate. Fedora Legacy was originally > concieved to provide a longer life span for Fedora Core releases. The > support for RHL 7.3/9 is just a byproduct of this, an added bonus. > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From hbo at egbok.com Thu May 20 23:14:23 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 16:14:23 -0700 (PDT) Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <6.1.0.6.0.20040520152609.02743de0@mail.speed.net> Message-ID: There's no doubt that this was deliberate on the part of Red Hat. But not everyone is jumping ship. The last I looked, Red Hat's subscriptions are way up, and their renewal rate is between 80%-90%. Also, while the instability and disavowal of support do scare off business use of Fedora Core, the willingness to accept the latest changes in existing packages, and to try new stuff is appealing to the geeks among us. This is a core (heh) constituency that Red Hat needs to keep on board to ensure their enterprise offering stays at a high level of quality and relevance. This also seems to be working. On Thu, 20 May 2004, Kelson Vibber wrote: > At 03:23 PM 5/20/2004, Marc Deslauriers wrote: > >Unstable release? > > > >I know a _bunch_ of people running FC1 on servers depending on FL to get > >patches out when RH stops. > > Blame Red Hat marketing. I think they're deathly afraid people will keep > using Fedora Core the same way they were using the free RHL. Hence, the > warnings about FC stability, in hopes that people will move to RHEL > instead. Of course, what's happened instead is a mass (or at least noisy) > exodus to SuSE and Debian, with a lot of people moving to Fedora Core > anyway and others moving to RHEL clones like cAos, Whitebox, etc. > > "It will eat your braaane!" > > > Kelson Vibber > SpeedGate Communications > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From jkeating at j2solutions.net Thu May 20 23:12:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 16:12:38 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: References: Message-ID: <200405201612.38954.jkeating@j2solutions.net> On Thursday 20 May 2004 16:08, Howard Owen wrote: > I know you've thought about what it will mean to support three > releases a year, *every year*. > > How about picking just one a year? Not 3. 2. Every 4 to 6 months, and the way I've seen things go (from the inside) we're going to be pretty close to just 2 a year. Fedora Legacy will only support 2 FC releases at a time. So when FC1 goes EOL, we support it, and when FC2 goes EOL, we support it. When FC3 goes eol, we no longer support FC1, just FC2 and FC3. So on and so forth. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From hbo at egbok.com Thu May 20 23:25:50 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 16:25:50 -0700 (PDT) Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <200405201612.38954.jkeating@j2solutions.net> Message-ID: That makes sense. So effectively we add a year to the support lifetime of the Fedora Core releases. I also see why dropping two lesser used releases makes arithmetic sense. On Thu, 20 May 2004, Jesse Keating wrote: > On Thursday 20 May 2004 16:08, Howard Owen wrote: > > I know you've thought about what it will mean to support three > > releases a year, *every year*. > > > > How about picking just one a year? > > Not 3. 2. Every 4 to 6 months, and the way I've seen things go (from > the inside) we're going to be pretty close to just 2 a year. Fedora > Legacy will only support 2 FC releases at a time. So when FC1 goes > EOL, we support it, and when FC2 goes EOL, we support it. When FC3 > goes eol, we no longer support FC1, just FC2 and FC3. So on and so > forth. > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From mic at npgx.com.au Fri May 21 00:06:45 2004 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 21 May 2004 10:06:45 +1000 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <002301c43e52$98cf9d80$6401a8c0@internode.com.au> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <002301c43e52$98cf9d80$6401a8c0@internode.com.au> Message-ID: <20040520235313.M2065@npgx.com.au> Hi, > > Likewise, I agree with the proposal. Personally, I've upgraded any RH7.1 > > -> 7.2 machines through to 7.3. That process itself is fairly painless > > and 7.3 & 9 are the most supported legacy distros. > > > > As for RH8.. :) Why anyone would run it is beyond me and upgrading to > > RH9 is painless too (even remotely). :) I think that is just opinion, I have used 3 RH8 machines in production for years without dramas. I didn't like the 7 series and 9 didn't show me any major reason to upgrade. Most of my production servers are now Fedora Core 1 (going on FC2 as of last nights testing), with only 2 RH8 machines still residing in production which I'm migrating to FC1/2 as we speak. What did/do I use RH8 for? squid proxy caching, iptables (shoreline) firewall, Webmail, DNS, DHCP, Samba, portslave/freeradius, VOCP, mrtg, Spamassassin, Mailscanner, etc, the list goes on and on. It's stable and I've never had dramas with it. > I've personally got a Redhat 7.1 box and a Redhat 8 box both of > which I've considered upgrading, however I'm very skeptical about > doing it for fear of it stuffing up. (these boxen are in production!) > :) > > How well does the upgrade happen? does it keep config files and so forth? Personally I have never "upgraded" RH operating systems, I'm not comfortable with doing that on anything other than Debian. What I do when upgrading Red Hat is to go through a re-install process like: * install the upgraded environment on a test machine * test it * if ok, buy new drives * yank the drives that are in the old systems * put in new drives * mirror them * go through install procedure as performed on test * test * enter production Worst case, yank the new drives and put the old ones back in. That's a cheap upgrade process. You could buy a new server and go that route (I have done that also and it's fine) or (for even cheaper process) you could Ghost your old drives and re-install then Ghost back if things don't work. Michael. From maillist at jasonlim.com Fri May 21 00:19:52 2004 From: maillist at jasonlim.com (Jason Lim) Date: Fri, 21 May 2004 08:19:52 +0800 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? References: <200405192226.36522.jkeating@j2solutions.net><1085031752.3328.2.camel@localhost.localdomain><002301c43e52$98cf9d80$6401a8c0@internode.com.au> <20040520162337.lkl5w0sc0kc0w0w4@mail.ph.utexas.edu> Message-ID: <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> > For me, it is more of a customization issue than a technical issue. I've > got lots of custom software that I need to keep intact. > Same goes for the Redhat 7.2 and 8 systems I admin. Downtime is also not really an option, otherwise they would have all been upgraded to 9 a long time ago. If full support cannot be provided by Fedora Legacy, perhaps some sort of compromise (the hated word!) can be reached between full support and no support at all. There are some private people rolling their own packages and making them available for download, but then you risk having no testing at all (and also that the person won't trojan the packages or something). As mentioned, perhaps 7.2 and 8 can be put in a slightly different status than "full support". I don't know what resource is lacking... is it no one is making the packages for 7.2/8, or not enough people doing QA for 7.2/8 packages, or something else? But at least making the packages available for download, even if not QAed as much as 9, would be far better than nothing, because there are bound to be more people doing QA on Fedora Legacy packages than there are for some person's private package repository. Also, if you want to know how many people are running Redhat 7.2/8 and need the updates, then it would be pretty simple... do a bit of extra effort to QA the packages already available, make sure yum/apt is available for 7.2/8, and announce it available. See the number of people downloading over 1 month... and compare it to say 7.3 and others, and see if it is worthwhile to support it fully. I'm sure the server admin has access to these logs, and simply webstat software like analog or webalizer can be used to see this. Just my 2 cents on how to resolve this issue. Jas From mkratz at internode.com.au Fri May 21 00:47:28 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Fri, 21 May 2004 10:17:28 +0930 Subject: State of 7.2/8.0 in Fedora Legacy References: <200405192226.36522.jkeating@j2solutions.net><1085031752.3328.2.camel@localhost.localdomain><002301c43e52$98cf9d80$6401a8c0@internode.com.au> <20040520162337.lkl5w0sc0kc0w0w4@mail.ph.utexas.edu> Message-ID: <06df01c43ecd$314c7a90$26e753c0@internode.com.au> ----- Original Message ----- From: "Eric Rostetter" To: Sent: Friday, May 21, 2004 6:53 AM Subject: Re: State of 7.2/8.0 in Fedora Legacy > > How well does the upgrade happen? does it keep config files and so forth? > > Depends on your services, etc. 7.1 to 7.3 shouldn't be a big deal. > 7.x to 8.x has some things to watch for (wu-ftp -> vsftp, apache 1.x > to apache 2.x come to mind) which can cause upgrade problems for you > if you use those services. > > For me, it is more of a customization issue than a technical issue. I've > got lots of custom software that I need to keep intact. The only custom thing that I'm running on these boxen is really Amavis, and a changed sendmail.cf file to interact with Amavis. The rest is pretty much standard stuff. From mkratz at internode.com.au Fri May 21 00:49:15 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Fri, 21 May 2004 10:19:15 +0930 Subject: State of 7.2/8.0 in Fedora Legacy References: <200405192226.36522.jkeating@j2solutions.net><20040520113357.vx00c4kg0wos0sgw@mail.ph.utexas.edu> <6.1.0.6.0.20040520095345.02537ec8@mail.speed.net> Message-ID: <070f01c43ecd$70dc7390$26e753c0@internode.com.au> Kelson Vibber wrote: > I don't know what the success rate is for upgrading 7.2->7.3 or 8.0->9 > using yum or apt-get dist-upgrade, but if it's high enough, perhaps posting > directions on doing so would be valuable. That would eliminate most of the > downtime (since it could be done on a live system and require only a reboot). That sounds like a good idea. From rostetter at mail.utexas.edu Fri May 21 02:31:55 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 21:31:55 -0500 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <40AD1E85.5080500@sagesys.net> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40AD1E85.5080500@sagesys.net> Message-ID: <20040520213155.bmpco8ggo004cwkw@mail.ph.utexas.edu> Quoting Jonathan Crowe : > Even though it would be nice to not have to upgrade the FC1 machines > until FC2 has been around for a while (and through several rounds of bug > fixes), they are, after all, not servers. First, that is the whole foundation of FL. Second, a lot of people are running FC1 on servers (for better or for worse). > Even through it has been solid for me on the desktop, when it came out > FC1 was billed as an unstable release. Red Hat engineers have been pretty sworn that it was a stable option for servers on every mailing list I've been on where the topic came up. > I suspect that for the most > part people have not installed it on servers. While I wish that was true, it isn't. Many small shops are running it on servers. -- Eric Rostetter From rostetter at mail.utexas.edu Fri May 21 03:01:44 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 22:01:44 -0500 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <1085090617.20034.29.camel@quirk.cisco.com> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> <1085090617.20034.29.camel@quirk.cisco.com> Message-ID: <20040520220144.1uasskws408c0g40@mail.ph.utexas.edu> Quoting Howard B Owen : > There are very economical commercial patch services for legacy systems. > If it's one server, five bucks a month (six month minimum) will get you > Progeny Transition Service support. (http://transition.progeny.com) If > you are planning to upgrade after the spring quarter, it sounds like all > you would need would be sixty bucks. * Economical is in the eye of the beholder. * We have no idea how long Progeny et al will continue the support. * My spring quarter is over next week, so if I upgrade then, I sure don't want to buy 6 months of support for the no longer installed O/S > The point is, the more popular releases are more likely to be deployed > on a larger number of servers. Apart from the project resource issues, > concentrating on the releases with a greater installed base may provide > most of the value in places where money is tight. Progeny et al may take the same attitude, and then the there would be no support left... -- Eric Rostetter From rostetter at mail.utexas.edu Fri May 21 03:27:25 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 22:27:25 -0500 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: References: Message-ID: <20040520222725.uq4g4scowss4w04w@mail.ph.utexas.edu> Quoting Howard Owen : > "3. Do as much of the development work as possible directly in the > upstream packages. This includes updates; our default policy will be to > upgrade to new versions for security as well as for bugfix and new > feature update releases of packages." That is different than "unstable". > This is less conservative than a distribution designed to run for years > performing a particular workload. The word "unstable" isn't mentioned in > the objectives Of course not. Who would intentionally create an unstable OS? > but point one of the "non-objectives" is: > > "1. Slow rate of change." It follows the open source dogma of "release often" is all. That doesn't mean it can't be stable (if done properly). > OTOH, point seven of the objectives is: > > "7. Promote rapid adoption of new releases by maintaining easy > upgradeability, with minimal disturbances to configuration changes." That has nothing to do with stability of the OS. > I can attest that the FC1-FC2 upgrade worked extremely well for me. That has nothing to do with the stability of an install, only of the upgrade process. > Businesses I have knowledge of have shied away from Fedora Core because of > the rapid rate of change issue. Yes, and many large businesses I know have shied away from Linux and gone with a "real unix" also. But what's the point? > In my opinion, folks who have taken the > plunge with FC1 on production machines really need to seriously consider > upgrading to FC2. Yes, they do, but should they be forced to do it on the FC schedule, rather than depend on FL giving them a bit more flexibility in when to upgrade? FL doesn't want to extend FC 1 forever, just to about 1.5 years. They will need to upgrade, FL just gives them more time to do so, so that they don't have to do it every 6 months (but say, instead, every 12 months). > This is in line with the objectives quoted above. Red > Hat and the volunteers at the Fedora project seem to have tried awfully > hard to make that as smooth as possible. (c.f. *not turning on SELinux by > default.) Yes, and that is good for some target audiences. And FL is good for other target audiences. Both have their place. -- Eric Rostetter From ral77 at bellsouth.net Fri May 21 03:35:11 2004 From: ral77 at bellsouth.net (ral77) Date: Thu, 20 May 2004 23:35:11 -0400 Subject: redhat 8.0 support In-Reply-To: <40ACAEAB.2000403@reea.net> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40ACACBB.4020500@clifford.net> <40ACAEAB.2000403@reea.net> Message-ID: <40AD78EF.4020303@bellsouth.net> marius popa wrote: > > Upgrade from 8.0 -> 9.0 is painless and you could choose what packages > need to be left untouched (mysql,apache...) > > I have (1) rh8 server just running samba file and print services & nfs. Can you give a brief description on doing a inplace migration from rh8.0 -> 9.0 I've been researching this option today and not really clear. I have yum installed and apt will be installed this weekend. I have tape backup (amanda) on another server. Another other key question is how much free disk space do I need, current partitioning scheme is as follows: Filesystem Size Used Avail Use% Mounted on /dev/hda7 486M 181M 280M 40% / /dev/hda1 99M 24M 70M 26% /boot /dev/hda2 3.8G 1.1G 2.5G 30% /home /dev/hda8 99M 4.1M 89M 5% /tmp /dev/hda3 3.4G 2.4G 891M 73% /usr /dev/hda5 787M 242M 506M 33% /var /dev/hda9 4.9G 3.3G 1.3G 71% /nfs /dev/hdb1 16G 12G 4.0G 74% /mnt/hdb1 ******************************************* Disk /dev/hda: 255 heads, 63 sectors, 1868 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 523 4096575 83 Linux /dev/hda3 524 969 3582495 83 Linux /dev/hda4 970 1868 7221217+ f Win95 Ext'd (LBA) /dev/hda5 970 1071 819283+ 83 Linux /dev/hda6 1072 1147 610438+ 82 Linux swap /dev/hda7 1148 1211 514048+ 83 Linux /dev/hda8 1212 1224 104391 83 Linux /dev/hda9 1225 1868 5172898+ 83 Linux Thx's in advance on any comments. ral From stuart at serverpeak.com Fri May 21 03:39:01 2004 From: stuart at serverpeak.com (Stuart Low) Date: Fri, 21 May 2004 13:39:01 +1000 Subject: redhat 8.0 support In-Reply-To: <40AD78EF.4020303@bellsouth.net> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40ACACBB.4020500@clifford.net> <40ACAEAB.2000403@reea.net> <40AD78EF.4020303@bellsouth.net> Message-ID: <1085110741.3466.16.camel@testbed.seekbrain.com> Heya, http://www.atomicrocketturtle.com/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=3#16 That explains how to do it using Ximian's Red Carpet. It's for RH 7.2 -> 7.3 but 8.0 -> 9.0 is pretty damn similar. Stuart On Fri, 2004-05-21 at 13:35, ral77 wrote: > marius popa wrote: > > > > > Upgrade from 8.0 -> 9.0 is painless and you could choose what packages > > need to be left untouched (mysql,apache...) > > > > > > > I have (1) rh8 server just running samba file and print services & nfs. > Can you give a brief description on doing a inplace > migration from rh8.0 -> 9.0 I've been researching this option today and > not really clear. I have yum installed and apt will be installed this > weekend. I have tape backup (amanda) on another server. Another other > key question is how much free disk space do I need, current partitioning > scheme is as follows: > > Filesystem Size Used Avail Use% Mounted on > /dev/hda7 486M 181M 280M 40% / > /dev/hda1 99M 24M 70M 26% /boot > /dev/hda2 3.8G 1.1G 2.5G 30% /home > /dev/hda8 99M 4.1M 89M 5% /tmp > /dev/hda3 3.4G 2.4G 891M 73% /usr > /dev/hda5 787M 242M 506M 33% /var > /dev/hda9 4.9G 3.3G 1.3G 71% /nfs > /dev/hdb1 16G 12G 4.0G 74% /mnt/hdb1 > > ******************************************* > > Disk /dev/hda: 255 heads, 63 sectors, 1868 cylinders > Units = cylinders of 16065 * 512 bytes > > Device Boot Start End Blocks Id System > /dev/hda1 * 1 13 104391 83 Linux > /dev/hda2 14 523 4096575 83 Linux > /dev/hda3 524 969 3582495 83 Linux > /dev/hda4 970 1868 7221217+ f Win95 Ext'd (LBA) > /dev/hda5 970 1071 819283+ 83 Linux > /dev/hda6 1072 1147 610438+ 82 Linux swap > /dev/hda7 1148 1211 514048+ 83 Linux > /dev/hda8 1212 1224 104391 83 Linux > /dev/hda9 1225 1868 5172898+ 83 Linux > > > Thx's in advance on any comments. > ral > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From stuart at serverpeak.com Fri May 21 03:49:45 2004 From: stuart at serverpeak.com (Stuart Low) Date: Fri, 21 May 2004 13:49:45 +1000 Subject: redhat 8.0 support References: <20040520124043.97FCB7466E@hormel.redhat.com> <40ACACBB.4020500@clifford.net> <40ACAEAB.2000403@reea.net> <40AD78EF.4020303@bellsouth.net> <1085110741.3466.16.camel@testbed.seekbrain.com> Message-ID: <000501c43ee6$a8496900$4f01a8c0@perlboy> Heya, I amost forgot that I had actually done a write up of this as well. :) http://www.seekbrain.com/archives/2004_02.html Cheers, Stuart ----- Original Message ----- From: "Stuart Low" To: "Discussion of the Fedora Legacy Project" Sent: Friday, May 21, 2004 1:39 PM Subject: Re: redhat 8.0 support > Heya, > > http://www.atomicrocketturtle.com/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=3#16 > > That explains how to do it using Ximian's Red Carpet. It's for RH 7.2 -> > 7.3 but 8.0 -> 9.0 is pretty damn similar. > > Stuart > > On Fri, 2004-05-21 at 13:35, ral77 wrote: > > marius popa wrote: > > > > > > > > Upgrade from 8.0 -> 9.0 is painless and you could choose what packages > > > need to be left untouched (mysql,apache...) > > > > > > > > > > > > I have (1) rh8 server just running samba file and print services & nfs. > > Can you give a brief description on doing a inplace > > migration from rh8.0 -> 9.0 I've been researching this option today and > > not really clear. I have yum installed and apt will be installed this > > weekend. I have tape backup (amanda) on another server. Another other > > key question is how much free disk space do I need, current partitioning > > scheme is as follows: > > > > Filesystem Size Used Avail Use% Mounted on > > /dev/hda7 486M 181M 280M 40% / > > /dev/hda1 99M 24M 70M 26% /boot > > /dev/hda2 3.8G 1.1G 2.5G 30% /home > > /dev/hda8 99M 4.1M 89M 5% /tmp > > /dev/hda3 3.4G 2.4G 891M 73% /usr > > /dev/hda5 787M 242M 506M 33% /var > > /dev/hda9 4.9G 3.3G 1.3G 71% /nfs > > /dev/hdb1 16G 12G 4.0G 74% /mnt/hdb1 > > > > ******************************************* > > > > Disk /dev/hda: 255 heads, 63 sectors, 1868 cylinders > > Units = cylinders of 16065 * 512 bytes > > > > Device Boot Start End Blocks Id System > > /dev/hda1 * 1 13 104391 83 Linux > > /dev/hda2 14 523 4096575 83 Linux > > /dev/hda3 524 969 3582495 83 Linux > > /dev/hda4 970 1868 7221217+ f Win95 Ext'd (LBA) > > /dev/hda5 970 1071 819283+ 83 Linux > > /dev/hda6 1072 1147 610438+ 82 Linux swap > > /dev/hda7 1148 1211 514048+ 83 Linux > > /dev/hda8 1212 1224 104391 83 Linux > > /dev/hda9 1225 1868 5172898+ 83 Linux > > > > > > Thx's in advance on any comments. > > ral > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rostetter at mail.utexas.edu Fri May 21 04:01:22 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 20 May 2004 23:01:22 -0500 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? In-Reply-To: <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> References: <200405192226.36522.jkeating@j2solutions.net><1085031752.3328.2.camel@localhost.localdomain><002301c43e52$98cf9d80$6401a8c0@internode.com.au> <20040520162337.lkl5w0sc0kc0w0w4@mail.ph.utexas.edu> <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> Message-ID: <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> Quoting Jason Lim : > Same goes for the Redhat 7.2 and 8 systems I admin. Downtime is also not > really an option, otherwise they would have all been upgraded to 9 a long > time ago. Exactly. > than "full support". I don't know what resource is lacking... is it no one > is making the packages for 7.2/8, or not enough people doing QA for 7.2/8 > packages, or something else? For 7.2, it appears to be a problem of getting them QA tested. For 8.0, there is a bit of a chicken and egg issue as we don't have the needed support there (apt/yum/etc) for people to even conveniently use the packages, etc. I'd think we'd see more 8.0 usage if the apt/yum/rpm issue was resolved. I know I've personally tried to do QA on the 7.2 and 8.0 packages, but I've been one of the very few. And since it takes multiple votes to get a package out, my single vote doesn't help much. > But at least making the packages available > for download, even if not QAed as much as 9, would be far better than > nothing, because there are bound to be more people doing QA on Fedora > Legacy packages than there are for some person's private package > repository. Well, maybe not as far as functionality, but I trust FL more as far as trojan/corruption/etc than most other sources. As far as functionality QA we still need testers, and more than just a couple. > Also, if you want to know how many people are running Redhat 7.2/8 and > need the updates, then it would be pretty simple... do a bit of extra > effort to QA the packages already available, make sure yum/apt is > available for 7.2/8, and announce it available. Yes, indeed. One other thing that was originally mentioned was a web vote for which versions to support. I never saw any such vote setup though (either it wasn't or I missed it). Would give a good count of how many active people use/want what versions supported. > See the number of people > downloading over 1 month... Not fair, since 7.x people may have apt/yum doing daily automatic upgrades, but since there is no apt/yum for 8.0, you won't see the same type of automatted hits. > Just my 2 cents on how to resolve this issue. Appreciate the discussion (not matter what the out come). > Jas -- Eric Rostetter From jkeating at j2solutions.net Fri May 21 05:20:57 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 May 2004 22:20:57 -0700 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? In-Reply-To: <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> References: <200405192226.36522.jkeating@j2solutions.net> <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> Message-ID: <200405202221.02693.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 May 2004 21:01, Eric Rostetter wrote: > For 7.2, it appears to be a problem of getting them QA tested. For 8.0, > there is a bit of a chicken and egg issue as we don't have the needed > support there (apt/yum/etc) for people to even conveniently use the > packages, etc. I'd think we'd see more 8.0 usage if the apt/yum/rpm > issue was resolved. It's just a much needing QA as it is needing packages built in the first place. 7.2 packages require extra work. I get many good submissions and work for 7.3, do put out a 7.2 and an 8.0 package most often I have to do the work myself, and that can take too long. When I took over this project it was with the caveat that I am not a developer, but a project manager. Sure I can rebuild packages and stuff, but I can't spend all my time engineering and backporting patches when updates need to be pushed, mirrors need to be added, infrastructure needs to be built etc... 8.0 is even worse than 7.2. - -- 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.3 (GNU/Linux) iD8DBQFArZG+4v2HLvE71NURAq2tAJ9jvoJ8C2tw56bI7/e6ky9YkK4KhACgpurm JQnd0+sZlX3tqYer+m8jMN4= =7CU9 -----END PGP SIGNATURE----- From hbo at egbok.com Fri May 21 05:21:21 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 22:21:21 -0700 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <20040520220144.1uasskws408c0g40@mail.ph.utexas.edu> References: <200405192226.36522.jkeating@j2solutions.net> <1085031752.3328.2.camel@localhost.localdomain> <20040520130620.z00skkkcogkso848@mail.ph.utexas.edu> <1085090617.20034.29.camel@quirk.cisco.com> <20040520220144.1uasskws408c0g40@mail.ph.utexas.edu> Message-ID: <1085116880.12115.9.camel@owen.egbok.com> Well, they do call it a "transition" service. OTOH, they recently extended their commitment to provide the service through the end of 2005. I can understand you not wanting to pay 25 bucks (30, not 60, I doubled it inadvertently, minus 5 for the one month) for five months of service you don't need. But it does seem to put an upper bound on how valuable you think the Fedora Legacy service is, at least for this particular server. On Thu, 2004-05-20 at 20:01, Eric Rostetter wrote: > Quoting Howard B Owen : > > > There are very economical commercial patch services for legacy systems. > > If it's one server, five bucks a month (six month minimum) will get you > > Progeny Transition Service support. (http://transition.progeny.com) If > > you are planning to upgrade after the spring quarter, it sounds like all > > you would need would be sixty bucks. > > * Economical is in the eye of the beholder. > * We have no idea how long Progeny et al will continue the support. > * My spring quarter is over next week, so if I upgrade then, I sure > don't want to buy 6 months of support for the no longer installed O/S > > > The point is, the more popular releases are more likely to be deployed > > on a larger number of servers. Apart from the project resource issues, > > concentrating on the releases with a greater installed base may provide > > most of the value in places where money is tight. > > Progeny et al may take the same attitude, and then the there would be > no support left... > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From hbo at egbok.com Fri May 21 05:57:32 2004 From: hbo at egbok.com (Howard Owen) Date: Thu, 20 May 2004 22:57:32 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040520222725.uq4g4scowss4w04w@mail.ph.utexas.edu> References: <20040520222725.uq4g4scowss4w04w@mail.ph.utexas.edu> Message-ID: <1085119051.12115.42.camel@owen.egbok.com> I'm using "unstable" as in the dictionary definition "not firm or fixed in one place : apt to move." (Although perhaps that should be "yum to move?") There's overlap between that definition and saying that a slow rate of change is not one of you goals. There's a pejorative sense of the word meaning "unreliable," which I think is the impression that was given by Red Hat marketing when Fedora was announced. As far as I can tell, that wasn't true at all of FC1. My experience was that release was that it was rock solid stable, in the sense of "reliable." I was writing here from ignorance of the goals of the FL project to only support two Fedora Core releases at a time. I was going by the originally stated objectives of FC to release three times a year, and doing the math. (My multiplication has been suspect today.) I still do think that if you decide to put FC into production, you have to be prepared to upgrade more frequently than what you may have been used to. That was my meaning in quoting point 7 of the FC objectives, not to cast more "unstable" aspersions. Finally, I should have been clearer that the "businesses I have knowledge of .." are big Linux fans. And looking at Unix server sales figures for the last couple of years, it sure looks like many businesses I *don't* have knowledge of are too. Large enterprises that want Linux aren't installing FC, and the ones I have first-hand knowledge of are going with RHEL or SLES because of two things. One is the stability offered by those distributions, and the other is support. (I don't count ISV support in my list because that's really another manifestation of OS stability in the form of frozen APIs.) Smaller businesses that can't afford the fee for the enterprise distributions may well consider Fedora Core. But they need to be prepared to face a lack of SLAs now, and pressure to upgrade sooner than they would if they paid up-front. Now that I'm over the misconception about the number of FC releases that have to be supported by FL at any given time, I'm a lot more comfortable with the position of the project in that regard. Please forgive my ignorance of matters that have clearly been hashed out before. I *will* learn, eventually. 8) On Thu, 2004-05-20 at 20:27, Eric Rostetter wrote: > Quoting Howard Owen : > > > "3. Do as much of the development work as possible directly in the > > upstream packages. This includes updates; our default policy will be to > > upgrade to new versions for security as well as for bugfix and new > > feature update releases of packages." > > That is different than "unstable". > > > This is less conservative than a distribution designed to run for years > > performing a particular workload. The word "unstable" isn't mentioned in > > the objectives > > Of course not. Who would intentionally create an unstable OS? > > > but point one of the "non-objectives" is: > > > > "1. Slow rate of change." > > It follows the open source dogma of "release often" is all. That doesn't > mean it can't be stable (if done properly). > > > OTOH, point seven of the objectives is: > > > > "7. Promote rapid adoption of new releases by maintaining easy > > upgradeability, with minimal disturbances to configuration changes." > > That has nothing to do with stability of the OS. > > > I can attest that the FC1-FC2 upgrade worked extremely well for me. > > That has nothing to do with the stability of an install, only of the > upgrade process. > > > Businesses I have knowledge of have shied away from Fedora Core because of > > the rapid rate of change issue. > > Yes, and many large businesses I know have shied away from Linux and gone with > a "real unix" also. But what's the point? > > > In my opinion, folks who have taken the > > plunge with FC1 on production machines really need to seriously consider > > upgrading to FC2. > > Yes, they do, but should they be forced to do it on the FC schedule, rather > than depend on FL giving them a bit more flexibility in when to upgrade? > > FL doesn't want to extend FC 1 forever, just to about 1.5 years. They > will need to upgrade, FL just gives them more time to do so, so that they > don't have to do it every 6 months (but say, instead, every 12 months). > > > This is in line with the objectives quoted above. Red > > Hat and the volunteers at the Fedora project seem to have tried awfully > > hard to make that as smooth as possible. (c.f. *not turning on SELinux by > > default.) > > Yes, and that is good for some target audiences. And FL is good for > other target audiences. Both have their place. > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers From pmatilai at welho.com Fri May 21 06:08:32 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 21 May 2004 09:08:32 +0300 Subject: State of 7.2/8.0 in Fedora Legacy In-Reply-To: <200405201552.54140.jkeating@j2solutions.net> References: <20040520174745.zgv8kcokg4gco804@mail.ph.utexas.edu> <1085093566.5103.6.camel@weasel.net.laiskiainen.org> <200405201552.54140.jkeating@j2solutions.net> Message-ID: <1085119712.12821.18.camel@weasel.net.laiskiainen.org> On Fri, 2004-05-21 at 01:52, Jesse Keating wrote: > On Thursday 20 May 2004 15:52, Panu Matilainen wrote: > > Indeed it's based on RHL 7.2 so for most packages supporting 7.2 > > should be quite easy using AS 2.1 updates. > > Correct most. Not all. And thats my point. I'm not going to provide > 'most' updates for the release. Sure, I wasn't arguing for supporting RHL 7.2 (because of the AS 2.1 relation or otherwise), just confirming the relation. - Panu - From maillist at jasonlim.com Fri May 21 07:42:14 2004 From: maillist at jasonlim.com (Jason Lim) Date: Fri, 21 May 2004 15:42:14 +0800 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? References: <200405192226.36522.jkeating@j2solutions.net><1085031752.3328.2.camel@localhost.localdomain><002301c43e52$98cf9d80$6401a8c0@internode.com.au><20040520162337.lkl5w0sc0kc0w0w4@mail.ph.utexas.edu><2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> Message-ID: <2c9501c43f07$22877480$ce00a8c0@SYSTEM9> > > See the number of people > > downloading over 1 month... > > Not fair, since 7.x people may have apt/yum doing daily automatic upgrades, > but since there is no apt/yum for 8.0, you won't see the same type of > automatted hits. Actually, this is exactly why I mention: > > effort to QA the packages already available, make sure yum/apt is > > available for 7.2/8, and announce it available. As the famous problem with Redhat 8 is lack of any way to auto-update/install with 8. If only it was just released. From mic at npgx.com.au Fri May 21 13:26:12 2004 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 21 May 2004 23:26:12 +1000 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040520213155.bmpco8ggo004cwkw@mail.ph.utexas.edu> References: <20040520124043.97FCB7466E@hormel.redhat.com> <40AD1E85.5080500@sagesys.net> <20040520213155.bmpco8ggo004cwkw@mail.ph.utexas.edu> Message-ID: <20040521132020.M42359@npgx.com.au> Hi, > > Even though it would be nice to not have to upgrade the FC1 machines > > until FC2 has been around for a while (and through several rounds of bug > > fixes), they are, after all, not servers. > > First, that is the whole foundation of FL. > > Second, a lot of people are running FC1 on servers (for better or for > worse). > > > Even through it has been solid for me on the desktop, when it came out > > FC1 was billed as an unstable release. > > Red Hat engineers have been pretty sworn that it was a stable option > for servers on every mailing list I've been on where the topic came up. > > > I suspect that for the most > > part people have not installed it on servers. > > While I wish that was true, it isn't. Many small shops are running > it on servers. I run it on 3 production servers which provide various on-line services for my clients. I also run it at home for ADSL dialup (PPPoE), squid, DNS, firewall. I don't understand what the mystery is in getting this on production and on servers, I run it and i'm positive many others do to. Apart from the SMP kernel problem (which I worked around) I didn't have any other issues and have found it rock solid for work, business and personal use. Michael. From brian.t.brunner at gai-tronics.com Fri May 21 15:29:00 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Fri, 21 May 2004 11:29:00 -0400 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 Message-ID: As a software engineer, 'unstable' means (to me) 'prone to collapse'. All software is subject to evolution (patches) without name changes (upgrade) neither of which implies that the software was unstable (prone to collapse) before or after the patch or upgrade. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> hbo at egbok.com 05/21/04 01:57AM >>> I'm using "unstable" as in the dictionary definition "not firm or fixed in one place : apt to move." (Although perhaps that should be "yum to move?") lol ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From dawson at fnal.gov Fri May 21 15:29:55 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 10:29:55 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum Message-ID: <40AE2073.4040901@fnal.gov> Hi, Would this be of use to anyone? I had written up a web page on how to upgrade Fermi Linux 7.1.1 to Fermi Linux 7.3.1 for our users when we were dropping 7.1.1. All it needed was for me to take out the Fermi stuff, point to the correct yum, and I think everything is correct. The web page is at http://www-oss.fnal.gov/projects/fermilinux/common/tips/Upgrade_RH71_to_RH73_via_yum.html though if someone wanted to take it and put it in the Fedora Legacy pages, that is fine. If no-one finds they need this, then I won't put any more effort into it. Someone needs to at least verify step 5, to find out if there is a kernel problem in the real RedHat release, since our Fermi Linux was customized slightly. If people want something similar to this for going from 7.2 to 7.3, ... well, since you only have to yank out step 5, it should be rather easy to write. Hope this helps some folks Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From dkoobs at fcsservices.com Fri May 21 15:37:20 2004 From: dkoobs at fcsservices.com (Doug Koobs) Date: Fri, 21 May 2004 11:37:20 -0400 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <40AE2073.4040901@fnal.gov> Message-ID: <001801c43f49$80fbbac0$a07ac80a@fcsservices.com> > Hi, > Would this be of use to anyone? > I had written up a web page on how to upgrade Fermi Linux > 7.1.1 to Fermi Linux > 7.3.1 for our users when we were dropping 7.1.1. All it > needed was for me I think this would be useful for me. What would be the advantages of using yum to go from 7.1 to 7.3, as opposed to using the upgrade option from the 7.3 install CD's? Doug Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. From rostetter at mail.utexas.edu Fri May 21 15:47:33 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 21 May 2004 10:47:33 -0500 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? In-Reply-To: <200405202221.02693.jkeating@j2solutions.net> References: <200405192226.36522.jkeating@j2solutions.net> <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> <200405202221.02693.jkeating@j2solutions.net> Message-ID: <20040521104733.6nb6sw4wccwg0ccw@mail.ph.utexas.edu> Quoting Jesse Keating : > put out a 7.2 and an 8.0 package most often I have to do > the work myself, and that can take too long. I guess then unless someone volunteers to be the main 7.2 or 8.0 packager, we have no choice but to kill them. We can't ask Jesse to do this in addition to all the other stuff he does. I'll gladly QA test 7.2 and 8.0 stuff, but I don't have the time to do the packages. If no one else steps up asap to take on one of these, then I guess they should be dropped. > When I took over this > project it was with the caveat that I am not a developer, but a project > manager. That seems reasonable. > 8.0 is even worse than 7.2. Personally I'd rather see us drop 7.2 and keep 8.0, simply because 7.2 is a dot release/update rather than a major release like 8.0 was. I just think the project will look better if we maintain a version of each major release. But if no one steps up to do the work, then I guess we need to drop them. > - -- > 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.3 (GNU/Linux) > > iD8DBQFArZG+4v2HLvE71NURAq2tAJ9jvoJ8C2tw56bI7/e6ky9YkK4KhACgpurm > JQnd0+sZlX3tqYer+m8jMN4= > =7CU9 > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Eric Rostetter From dawson at fnal.gov Fri May 21 15:58:55 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 10:58:55 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <001801c43f49$80fbbac0$a07ac80a@fcsservices.com> References: <001801c43f49$80fbbac0$a07ac80a@fcsservices.com> Message-ID: <40AE273F.7000500@fnal.gov> Doug Koobs wrote: >>Hi, >>Would this be of use to anyone? >>I had written up a web page on how to upgrade Fermi Linux >>7.1.1 to Fermi Linux >> 7.3.1 for our users when we were dropping 7.1.1. All it >>needed was for me > > > I think this would be useful for me. What would be the advantages of using > yum to go from 7.1 to 7.3, as opposed to using the upgrade option from the > 7.3 install CD's? > > Doug > There are three big area's where doing it via yum is useful. 1- Uptime. You're up and running the whole time. I've done this one several machines and the only downtime is the time it takes to reboot. 2- You are more in control. We have several users that are very cautious and wanted to do things one step at a time. You actually can do 'yum upgrade kernel' and it will just do the kernel along with all the rpm's needed to upgrade a kernel. You can also tell it no when it gives you the list of rpms. 3- It doesn't 'trample over everything' if there is a problem. I don't write up web pages unless it saves me time. I had too many sys admins comming to me after doing a update from the CD's, and we were having to go through each rpm, verifying them, finding what got changed. If an upgrade from the CD's goes good, it goes good. If it doesn't go good, your system has all sorts of odd things happen that you have to track down. Now I'm not garanteeing that the yum upgrades won't make things work different, and might have some problems, but I have found with my admin's, that the problems were less, and most of them they were able to find before the upgrade, cuz yum wouldn't let them do things. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From jpdalbec at ysu.edu Fri May 21 16:49:28 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 21 May 2004 12:49:28 -0400 Subject: How To Upgrade 7.1 to 7.3 via yum Message-ID: <40AE3318.8040605@ysu.edu> I've upgraded 7.1 to 7.3 on several production servers. I first did a traditional upgrade on a test copy of one of the servers. I then compared the old and new package lists. I rebuilt several customized packages because they were "older" than the 7.3 versions. I installed the C library on the production servers. This caused SSHd not to do initgroups() on login the next morning. Restarting SSHd fixed the problem. I installed the custom packages on the production servers. I installed the packages that were added during the traditional upgrade. I installed the packages from CD 1 using rpm -Fvh a*.rpm, ... rpm -Fvh z*.rpm, rpm -Fvh *.rpm. I did the same with CDs 2 and 3. Occasionally I had to install packages from a different CD to satisfy dependencies so I just scp'd them to my account on the server from my workstation. The one problem that bit me was that the default /etc/identd.conf changed to enable encryption of ident information. I use ident authentication on my PostgreSQL server which is needed for web applications so that broke. Once I figured out that identd was the problem, I just had to change the default setting back. I also upgraded 7.1 to 7.3 on my home firewall using apt-get. I had a problem with gdk-pixbuf-gnome - apt-get wanted to remove it. I wound up copying and pasting the "upgraded packages" list into separate apt-get commands a line at a time. Eventually I figured out that if I specified gdk-pixbuf-gnome on the apt-get command it would upgrade it instead of removing it. My one mistake was not re-running LILO. Naturally I didn't have a boot disk available. I had to make a boot floppy on a 7.3 system at work and figure out which partition was my root partition via trial and error. My experience with yum leads me to believe that it doesn't resolve dependencies well when many packages are involved. Apt-get is a much better tool for system upgrades. My $0.02 USD, John From dkoobs at fcsservices.com Fri May 21 17:01:31 2004 From: dkoobs at fcsservices.com (Doug Koobs) Date: Fri, 21 May 2004 13:01:31 -0400 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <40AE273F.7000500@fnal.gov> Message-ID: <002001c43f55$44232320$a07ac80a@fcsservices.com> > There are three big area's where doing it via yum is useful. Sounds like this is the way I want to go (after a good backup). You may want to add a step to your how-to to edit the yum.conf file. When I followed your instructions (yum was not installed), and tried to run step 4, this happened: [root at fcsftp /root]# yum update yum Gathering package information from servers Getting headers from: Red Hat Linux 7.1 base Traceback (innermost last): File "/usr/bin/yum", line 44, in ? yummain.main(sys.argv[1:]) File "yummain.py", line 144, in main File "clientStuff.py", line 688, in get_package_info_from_servers File "clientStuff.py", line 128, in HeaderInfoNevralLoad ValueError: unpack list of wrong size There is no 7.1 directory in http://download.fedoralegacy.org/redhat/, so I changed /etc/yum.conf, and replaced all instances of $releasever with 7.3 and $basearch with i386, then I successfully ran "yum update yum". I'm assuming that since I am upgrading to 7.3, this is correct. Please verify. Thanks!! Doug Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. From dwb7 at ccmr.cornell.edu Fri May 21 17:20:05 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Fri, 21 May 2004 13:20:05 -0400 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: References: <200405201612.38954.jkeating@j2solutions.net> Message-ID: <20040521172001.GA29424@ccmr.cornell.edu> The only thing to think about with FC1, perhaps, is that it is the last 2.4 kernel release (unless FC2 offers a substitute 2.4. kernel). For many, going to the 2.6 kernel at this time is not a viable option. Reasons include wanting to let it be out there for a while to see what is and is not broken. In our case, we use a filesystem called Openafs. The 2.6 kernel completely broke openafs. I won't get into the politics of the situation, but if we were to go to a fedora core relase, it would have to be FC1. I wonder if you will find that there is support for a release like FC1 a la rh7.3 as compared to the other FC releases. On Thu, May 20, 2004 at 04:25:50PM -0700, Howard Owen wrote: > > That makes sense. So effectively we add a year to the support lifetime of > the Fedora Core releases. > > I also see why dropping two lesser used releases makes arithmetic sense. > > On Thu, 20 May 2004, Jesse Keating wrote: > > > On Thursday 20 May 2004 16:08, Howard Owen wrote: > > > I know you've thought about what it will mean to support three > > > releases a year, *every year*. > > > > > > How about picking just one a year? > > > > Not 3. 2. Every 4 to 6 months, and the way I've seen things go (from > > the inside) we're going to be pretty close to just 2 a year. Fedora > > Legacy will only support 2 FC releases at a time. So when FC1 goes > > EOL, we support it, and when FC2 goes EOL, we support it. When FC3 > > goes eol, we no longer support FC1, just FC2 and FC3. So on and so > > forth. > > > > > > -- > Howard Owen "Even if you are on the right > EGBOK Consultants track, you'll get run over if you > hbo at egbok.com +1-650-218-2216 just sit there." - Will Rogers > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From jkeating at j2solutions.net Fri May 21 17:20:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 21 May 2004 10:20:04 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040521172001.GA29424@ccmr.cornell.edu> References: <200405201612.38954.jkeating@j2solutions.net> <20040521172001.GA29424@ccmr.cornell.edu> Message-ID: <200405211020.08535.jkeating@j2solutions.net> On Friday 21 May 2004 10:20, David Botsch wrote: > I wonder if you will find that there is support for a release like > FC1 a la rh7.3 as compared to the other FC releases. That would completely depend on the community. I knew this was a possibility going into the project, but I didn't want to make any official policy until we see what the community demand (and help) is around the time of the Fedora Legacy EOL of FC1. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dawson at fnal.gov Fri May 21 18:13:10 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 13:13:10 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <40AE3318.8040605@ysu.edu> References: <40AE3318.8040605@ysu.edu> Message-ID: <40AE46B6.1080209@fnal.gov> John Dalbec wrote: > I've upgraded 7.1 to 7.3 on several production servers. I first did a > traditional upgrade on a test copy of one of the servers. I then > compared the old and new package lists. I rebuilt several customized > packages because they were "older" than the 7.3 versions. I installed > the C library on the production servers. This caused SSHd not to do > initgroups() on login the next morning. Restarting SSHd fixed the > problem. I installed the custom packages on the production servers. I > installed the packages that were added during the traditional upgrade. > I installed the packages from CD 1 using rpm -Fvh a*.rpm, ... rpm -Fvh > z*.rpm, rpm -Fvh *.rpm. I did the same with CDs 2 and 3. Occasionally I > had to install packages from a different CD to satisfy dependencies so I > just scp'd them to my account on the server from my workstation. The > one problem that bit me was that the default /etc/identd.conf changed to > enable encryption of ident information. I use ident authentication on > my PostgreSQL server which is needed for web applications so that broke. > Once I figured out that identd was the problem, I just had to change the > default setting back. > That sounds like alot of work. Ouch. > I also upgraded 7.1 to 7.3 on my home firewall using apt-get. I had a > problem with gdk-pixbuf-gnome - apt-get wanted to remove it. I wound up > copying and pasting the "upgraded packages" list into separate apt-get > commands a line at a time. Eventually I figured out that if I specified > gdk-pixbuf-gnome on the apt-get command it would upgrade it instead of > removing it. My one mistake was not re-running LILO. Naturally I > didn't have a boot disk available. I had to make a boot floppy on a 7.3 > system at work and figure out which partition was my root partition via > trial and error. > So it sounds like apt does a good job of it, and I have heard of many people using it to do the upgrades. That lilo part does get alot of people. But you can actually use the rescue part of RedHat 9, or Enterprise, and it will work fine with RedHat 7.3 for doing the re-lilo, or re-grub. I'm not saying yum is better or worse, it's just what I use, and it works great for me. I'm sure there are plenty of people on this list that would like an upgrade via apt document, just like this upgrade via yum document. I personally am not the person to write it, cuz I don't use it. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From dawson at fnal.gov Fri May 21 18:15:44 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 13:15:44 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <002001c43f55$44232320$a07ac80a@fcsservices.com> References: <002001c43f55$44232320$a07ac80a@fcsservices.com> Message-ID: <40AE4750.4050308@fnal.gov> Thanks for the info. Yep, I'll have to put in a section on the yum.conf file. In my original document I actually had a yum.conf file for people to use. Looks like I'll put one in. I finolly found a pure RedHat 7.1 installation (instead of a Fermi Linux one) so I'm running through the steps right now. Troy Doug Koobs wrote: >>There are three big area's where doing it via yum is useful. > > > Sounds like this is the way I want to go (after a good backup). You may want > to add a step to your how-to to edit the yum.conf file. When I followed your > instructions (yum was not installed), and tried to run step 4, this > happened: > > [root at fcsftp /root]# yum update yum > Gathering package information from servers > Getting headers from: Red Hat Linux 7.1 base > Traceback (innermost last): > File "/usr/bin/yum", line 44, in ? > yummain.main(sys.argv[1:]) > File "yummain.py", line 144, in main > File "clientStuff.py", line 688, in get_package_info_from_servers > File "clientStuff.py", line 128, in HeaderInfoNevralLoad > ValueError: unpack list of wrong size > > There is no 7.1 directory in http://download.fedoralegacy.org/redhat/, so I > changed /etc/yum.conf, and replaced all instances of $releasever with 7.3 > and $basearch with i386, then I successfully ran "yum update yum". > > I'm assuming that since I am upgrading to 7.3, this is correct. Please > verify. Thanks!! > > Doug > > > > Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From drees at greenhydrant.com Fri May 21 18:25:08 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 21 May 2004 11:25:08 -0700 (PDT) Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040521172001.GA29424@ccmr.cornell.edu> References: <200405201612.38954.jkeating@j2solutions.net> <20040521172001.GA29424@ccmr.cornell.edu> Message-ID: <3588.208.48.139.163.1085163908.squirrel@208.48.139.163> David Botsch wrote: > The only thing to think about with FC1, perhaps, is that it is the last > 2.4 kernel release (unless FC2 offers a substitute 2.4. kernel). For many, > going to the 2.6 kernel at this time is not a viable option. Reasons > include wanting to let it be out there for a while to see what is and is > not broken. > > In our case, we use a filesystem called Openafs. The 2.6 kernel completely > broke openafs. I won't get into the politics of the situation, but if we > were to go to a fedora core relase, it would have to be FC1. FWIW, I believe that you can run a FC1 kernel on FC2, but I have not tried it. I need to however, as one machine I've upgraded to FC2 is showing some strange NFS problems when reading from an IRIX share which aren't present in FC1. -Dave From dkoobs at fcsservices.com Fri May 21 18:27:51 2004 From: dkoobs at fcsservices.com (Doug Koobs) Date: Fri, 21 May 2004 14:27:51 -0400 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <40AE4750.4050308@fnal.gov> Message-ID: <002401c43f61$5337cd00$a07ac80a@fcsservices.com> > I finolly found a pure RedHat 7.1 installation (instead of a > Fermi Linux one) > so I'm running through the steps right now. > > Troy Thanks Troy! I think I'll wait till I hear back from you before I proceed. Doug Confidential: This electronic message and all contents contain information from Financial Credit Services which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender and destroy the original message and all copies. From jkeating at j2solutions.net Fri May 21 19:56:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 21 May 2004 12:56:41 -0700 Subject: cvs RHL9 rpms need QA Message-ID: <200405211256.44634.jkeating@j2solutions.net> I've built up RHL9 rpms of CVS that fixes a remote vuln. I would appreciate some quick QA so that they can be pushed to updates-testing for testing over the weekend. https://bugzilla.fedora.us/show_bug.cgi?id=1620 See comment #16 for the package links. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dawson at fnal.gov Fri May 21 20:23:01 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 15:23:01 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <002401c43f61$5337cd00$a07ac80a@fcsservices.com> References: <002401c43f61$5337cd00$a07ac80a@fcsservices.com> Message-ID: <40AE6525.4030206@fnal.gov> Doug Koobs wrote: >>I finolly found a pure RedHat 7.1 installation (instead of a >>Fermi Linux one) >>so I'm running through the steps right now. >> >>Troy > > > Thanks Troy! I think I'll wait till I hear back from you before I proceed. > > Doug > Hi Doug, I'm still working on the web page. It does currently have a link to a working yum.conf. It is essentially what you said, but it also has the exclude=kernel commented out, cuz you really do want to upgrade the kernel. There are a couple of things you need to double check. Make sure you have at least the 4.0.4 version of rpm, and you have to have the popt and the glibc that goes along with them. Make sure you have up2date uninstalled. Also make sure you don't have any 2.4.2 or 2.4.3 RedHat kernels installed. Beyond those things, my upgrade went quite well. I've got to re-install a machine and try the script I'm working on, so the web page might take a little bit longer to finish. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From dawson at fnal.gov Fri May 21 21:48:50 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 16:48:50 -0500 Subject: How To Upgrade 7.1 to 7.3 via yum In-Reply-To: <40AE6525.4030206@fnal.gov> References: <002401c43f61$5337cd00$a07ac80a@fcsservices.com> <40AE6525.4030206@fnal.gov> Message-ID: <40AE7942.4000601@fnal.gov> OK, web page works, been tested on fresh 7.1 machine. Please send me any problems, but I'm not here for the rest of the weekend. :) Troy Troy Dawson wrote: > Doug Koobs wrote: > >>> I finolly found a pure RedHat 7.1 installation (instead of a Fermi >>> Linux one) so I'm running through the steps right now. >>> >>> Troy >> >> >> >> Thanks Troy! I think I'll wait till I hear back from you before I >> proceed. >> Doug >> > Hi Doug, > I'm still working on the web page. It does currently have a link to a > working yum.conf. It is essentially what you said, but it also has the > exclude=kernel commented out, cuz you really do want to upgrade the kernel. > > There are a couple of things you need to double check. Make sure you > have at least the 4.0.4 version of rpm, and you have to have the popt > and the glibc that goes along with them. > > Make sure you have up2date uninstalled. > > Also make sure you don't have any 2.4.2 or 2.4.3 RedHat kernels installed. > > > Beyond those things, my upgrade went quite well. > > I've got to re-install a machine and try the script I'm working on, so > the web page might take a little bit longer to finish. > > Troy > -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From jkeating at j2solutions.net Sat May 22 02:22:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 21 May 2004 19:22:11 -0700 Subject: Fedora Legacy Test Update Notification: cvs Message-ID: <200405211922.14897.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1620 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1620 2004-05-21 --------------------------------------------------------------------- Name : cvs Version 7.3 : 1.11.1p1-14.legacy.2 Version 9 : 1.11.2-18.legacy Summary : A version control system. Description : CVS (Concurrent Version System) is a version control system that can record the history of your files (usually, but not always, source code). CVS only stores the differences between versions, instead of every version of every file you have ever created. CVS also keeps a log of who, when, and why changes occurred. CVS is very helpful for managing releases and controlling the concurrent editing of source files among multiple authors. Instead of providing version control for a collection of files in a single directory, CVS provides version control for a hierarchical collection of directories consisting of revision controlled files. These directories and files can then be combined together to form a software release. --------------------------------------------------------------------- Update Information: CAN-2004-0396: Heap-based buffer overflow in CVS 1.11.x up to 1.11.15, and 1.12.x up to 1.12.7, when using the pserver mechanism allows remote attackers to execute arbitrary code via Entry lines. --------------------------------------------------------------------- Changelog: 7.3: * Thu May 13 2004 Nalin Dahyabhai 1.11.1p1-14 - use revised version of Stefan Esser's patch provided by Derek Robert Price * Mon May 03 2004 Nalin Dahyabhai 1.11.1p1-13 - add patch from Stefan Esser to close CAN-2004-0396 9: * Fri May 21 2004 Jesse Keating From barryn at pobox.com Sat May 22 22:35:59 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 22 May 2004 15:35:59 -0700 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040521172001.GA29424@ccmr.cornell.edu> References: <200405201612.38954.jkeating@j2solutions.net> <20040521172001.GA29424@ccmr.cornell.edu> Message-ID: <20040522223558.GC2350@ip68-4-98-123.oc.oc.cox.net> On Fri, May 21, 2004 at 01:20:05PM -0400, David Botsch wrote: > The only thing to think about with FC1, perhaps, is that it is the last > 2.4 kernel release (unless FC2 offers a substitute 2.4. kernel). For many, > going to the 2.6 kernel at this time is not a viable option. Reasons include > wanting to let it be out there for a while to see what is and is not broken. The FC1 kernel can be used as a "substitute" 2.4 kernel for FC2. -Barry K. Nathan From dwb7 at ccmr.cornell.edu Sun May 23 05:07:40 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Sun, 23 May 2004 01:07:40 -0400 Subject: fedora-legacy-list Digest, Vol 3, Issue 24 In-Reply-To: <20040522223558.GC2350@ip68-4-98-123.oc.oc.cox.net> References: <200405201612.38954.jkeating@j2solutions.net> <20040521172001.GA29424@ccmr.cornell.edu> <20040522223558.GC2350@ip68-4-98-123.oc.oc.cox.net> Message-ID: <20040523050737.GA11174@ccmr.cornell.edu> Ok... but would it be supported along with FC2 if FC1 is EOLed? I would guess no. On Sat, May 22, 2004 at 03:35:59PM -0700, Barry K. Nathan wrote: > On Fri, May 21, 2004 at 01:20:05PM -0400, David Botsch wrote: > > The only thing to think about with FC1, perhaps, is that it is the last > > 2.4 kernel release (unless FC2 offers a substitute 2.4. kernel). For many, > > going to the 2.6 kernel at this time is not a viable option. Reasons include > > wanting to let it be out there for a while to see what is and is not broken. > > The FC1 kernel can be used as a "substitute" 2.4 kernel for FC2. > > -Barry K. Nathan > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From marcdeslauriers at videotron.ca Sun May 23 15:39:53 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 23 May 2004 11:39:53 -0400 Subject: State of 7.2/8.0 in Fedora Legacy - compromise? In-Reply-To: <20040521104733.6nb6sw4wccwg0ccw@mail.ph.utexas.edu> References: <200405192226.36522.jkeating@j2solutions.net> <2b3101c43ec9$55f4ed40$ce00a8c0@SYSTEM9> <20040520230122.9q0wgw48s4ocock8@mail.ph.utexas.edu> <200405202221.02693.jkeating@j2solutions.net> <20040521104733.6nb6sw4wccwg0ccw@mail.ph.utexas.edu> Message-ID: <1085326793.29704.6.camel@mdlinux> On Fri, 2004-05-21 at 11:47, Eric Rostetter wrote: > I guess then unless someone volunteers to be the main 7.2 or 8.0 packager, > we have no choice but to kill them. We can't ask Jesse to do this in > addition to all the other stuff he does. > > I'll gladly QA test 7.2 and 8.0 stuff, but I don't have the time to do the > packages. If no one else steps up asap to take on one of these, then I > guess they should be dropped. If people are still using 8.0, I guess I could step up and do the packages. A few people would have to do the QA though, as I don't have any 8.0 machine in production anymore. I was looking into contributing to FL, so that could be it. BUT, if everyone can upgrade to a newer version, my time could be better spent doing RHL9 packages, and FC1 in a few months. I think 7.2 should be dropped as the upgrade to 7.3 is easy. There is also another alternative: support 7.2 and 8.0 only for priority 1 security bugs. For example: a remote http compromise. This would mean only a package here and there instead of having one for every local thing that comes out. Marc. From michal at harddata.com Mon May 24 04:18:52 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 23 May 2004 22:18:52 -0600 Subject: cvs Message-ID: <20040523221852.A7457@mail.harddata.com> Just FYI - I recorded today eighteen attempts to connect to cvs with user names like '_h43tM5qFJkt1haSMfrwUYGUXHVRO2tAW_'. No, I am not waiting until an official release will go through all the motions even if I am not providing a public cvs server. Michal From fedoraleg_form at mm-vanecek.cc Mon May 24 15:40:17 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Mon, 24 May 2004 10:40:17 -0500 Subject: RH 9 EOL Updates ISOs Message-ID: <20040524153739.M14875@mm-vanecek.cc> I have been asking around and have just about come to the conclusion that it don't exist. I would like to get CD(s) (or downloadable ISOs) containing all RH 9 updates (SRPM and i386 RPM) up to the point of EOL. I'd like to avoid having to download all the individual packages. With all the mirrors and legacy work going around, I was hoping someone had already put together an ISO. Does anyone know of a source? Thanks. From gbailey at lxpro.com Mon May 24 16:32:49 2004 From: gbailey at lxpro.com (Greg Bailey) Date: Mon, 24 May 2004 10:32:49 -0600 Subject: RH 9 EOL Updates ISOs In-Reply-To: <20040524153739.M14875@mm-vanecek.cc> References: <20040524153739.M14875@mm-vanecek.cc> Message-ID: <40B223B1.2030301@lxpro.com> I did something similar for RedHat 7.3 at its EOL. The frustrating thing (as a former RedHat mirror admin) is that RedHat doesn't really have a policy for removing superseded errata from the updates tree. Upon request, they've periodically purged the updates tree of old RPMs, but even RedHat 9 still has duplicate packages. Once they do that, it doesn't seem too difficult to produce an ISO (or two). Is this something useful for FedoraLegacy to include in its distribution tree? Thanks, Greg Mike Vanecek wrote: >I have been asking around and have just about come to the conclusion that it >don't exist. I would like to get CD(s) (or downloadable ISOs) containing all >RH 9 updates (SRPM and i386 RPM) up to the point of EOL. I'd like to avoid >having to download all the individual packages. With all the mirrors and >legacy work going around, I was hoping someone had already put together an >ISO. Does anyone know of a source? > >Thanks. > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From sopwith at redhat.com Mon May 24 17:47:00 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 24 May 2004 13:47:00 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From paul at frields.com Mon May 24 18:01:37 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 24 May 2004 14:01:37 -0400 Subject: up2date package(s) available Message-ID: <1085421621.30975.65.camel@bettie.internal.frields.org> Due to having a few minutes free the other night, I've done a quick tweak to up2date that should allow folks using RHL9 to have up2date function as it does on FC1, using fedoralegacy.org yum/apt sources. To say this was quick and dirty would be giving me a lot more credit than is deserved. The helpful folks at #fedora-legacy inform me that this is not a priority for FL, which I understand. However, since there is probably an audience (however small) for this tweak, I thought it was worthwhile to at least tell Google about it here. Most folks would probably simply use yum/apt either when they feel like it, or in a nightly cron job. I suppose that this tweak, though, would cover at least some combination of the following: (1) Linux newbies who aren't into RPM building; (2) those who don't maintain a broadband connection full-time, or are on segregated networks where they are still running RHL 9 servers and/or workstations (as I do); and (3) those who would like their rhn-applet to function as in FC1. Hopefully that comes to a total of more than 1 or 2 people. :-) rhnlib and rhn-applet are simply recompiled from the latest stable FC1 SRPMS, while up2date has a few simple patches to insure the Fedora Legacy public key is available in addition to the Red Hat key. Of course, it's up to users to be good netizens and replace the repo URLs in /etc/sysconfig/rhn/sources with mirror sites. This basically worksforme, but I would love people to try it out and make suggestions, or provide po stuff for the couple messages I changed. You may simply be able to install the rhnlib and rhn-applet packages from FC1 updates on your RHL9 box; I haven't tried it. I realize the fedora-legacy-list probably doesn't want any traffic on a non-official package. Therefore, unless there's an objection, please direct comments off-list. BINARY: http://paul.frields.org/rhnlib-1.4-1.noarch.rpm http://paul.frields.org/rhn-applet-2.1.2-1.i386.rpm http://paul.frields.org/up2date-4.1.21-3.1.i386.rpm http://paul.frields.org/up2date-gnome-4.1.21-3.1.i386.rpm SRPMS: http://paul.frields.org/up2date-4.1.21-3.1.src.rpm All signed by me; my GPG key is available, among other places, at: http://pgp.mit.edu:11371/pks/lookup?search=paul%40frields.com&op=index Fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 -- Paul W. Frields, RHCE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at frields.com Mon May 24 18:00:22 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 24 May 2004 14:00:22 -0400 Subject: up2date package(s) available Message-ID: <1085421621.30975.65.camel@bettie.internal.frields.org> Due to having a few minutes free the other night, I've done a quick tweak to up2date that should allow folks using RHL9 to have up2date function as it does on FC1, using fedoralegacy.org yum/apt sources. To say this was quick and dirty would be giving me a lot more credit than is deserved. The helpful folks at #fedora-legacy inform me that this is not a priority for FL, which I understand. However, since there is probably an audience (however small) for this tweak, I thought it was worthwhile to at least tell Google about it here. Most folks would probably simply use yum/apt either when they feel like it, or in a nightly cron job. I suppose that this tweak, though, would cover at least some combination of the following: (1) Linux newbies who aren't into RPM building; (2) those who don't maintain a broadband connection full-time, or are on segregated networks where they are still running RHL 9 servers and/or workstations (as I do); and (3) those who would like their rhn-applet to function as in FC1. Hopefully that comes to a total of more than 1 or 2 people. :-) rhnlib and rhn-applet are simply recompiled from the latest stable FC1 SRPMS, while up2date has a few simple patches to insure the Fedora Legacy public key is available in addition to the Red Hat key. Of course, it's up to users to be good netizens and replace the repo URLs in /etc/sysconfig/rhn/sources with mirror sites. This basically worksforme, but I would love people to try it out and make suggestions, or provide po stuff for the couple messages I changed. You may simply be able to install the rhnlib and rhn-applet packages from FC1 updates on your RHL9 box; I haven't tried it. I realize the fedora-legacy-list probably doesn't want any traffic on a non-official package. Therefore, unless there's an objection, please direct comments off-list. BINARY: http://paul.frields.org/rhnlib-1.4-1.noarch.rpm http://paul.frields.org/rhn-applet-2.1.2-1.i386.rpm http://paul.frields.org/up2date-4.1.21-3.1.i386.rpm http://paul.frields.org/up2date-gnome-4.1.21-3.1.i386.rpm SRPMS: http://paul.frields.org/up2date-4.1.21-3.1.src.rpm All signed by me; my GPG key is available, among other places, at: http://pgp.mit.edu:11371/pks/lookup?search=paul%40frields.com&op=index Fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 -- Paul W. Frields, RHCE -------------- 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 bluebell at bribieisland.net Mon May 24 21:03:58 2004 From: bluebell at bribieisland.net (glm) Date: Tue, 25 May 2004 07:03:58 +1000 Subject: up2date package(s) available In-Reply-To: <1085421621.30975.65.camel@bettie.internal.frields.org> References: <1085421621.30975.65.camel@bettie.internal.frields.org> Message-ID: <40B2633E.4020808@bribieisland.net> Paul W. Frields wrote: >Due to having a few minutes free the other night, I've done a quick >tweak to up2date that should allow folks using RHL9 to have up2date >function as it does on FC1, using fedoralegacy.org yum/apt sources. To >say this was quick and dirty would be giving me a lot more credit than >is deserved. > >The helpful folks at #fedora-legacy inform me that this is not a >priority for FL, which I understand. However, since there is probably an >audience (however small) for this tweak, I thought it was worthwhile to >at least tell Google about it here. > >Most folks would probably simply use yum/apt either when they feel like >it, or in a nightly cron job. I suppose that this tweak, though, would >cover at least some combination of the following: (1) Linux newbies who >aren't into RPM building; (2) those who don't maintain a broadband >connection full-time, or are on segregated networks where they are still >running RHL 9 servers and/or workstations (as I do); and (3) those who >would like their rhn-applet to function as in FC1. Hopefully that comes >to a total of more than 1 or 2 people. :-) > >rhnlib and rhn-applet are simply recompiled from the latest stable FC1 >SRPMS, while up2date has a few simple patches to insure the Fedora >Legacy public key is available in addition to the Red Hat key. Of >course, it's up to users to be good netizens and replace the repo URLs >in /etc/sysconfig/rhn/sources with mirror sites. > >This basically worksforme, but I would love people to try it out and >make suggestions, or provide po stuff for the couple messages I changed. >You may simply be able to install the rhnlib and rhn-applet packages >from FC1 updates on your RHL9 box; I haven't tried it. I realize the >fedora-legacy-list probably doesn't want any traffic on a non-official >package. Therefore, unless there's an objection, please direct comments >off-list. > >BINARY: >http://paul.frields.org/rhnlib-1.4-1.noarch.rpm >http://paul.frields.org/rhn-applet-2.1.2-1.i386.rpm >http://paul.frields.org/up2date-4.1.21-3.1.i386.rpm >http://paul.frields.org/up2date-gnome-4.1.21-3.1.i386.rpm > >SRPMS: >http://paul.frields.org/up2date-4.1.21-3.1.src.rpm > >All signed by me; my GPG key is available, among other places, at: >http://pgp.mit.edu:11371/pks/lookup?search=paul%40frields.com&op=index >Fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > > > >------------------------------------------------------------------------ > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > Thanks Paul for the good work Regards from Australia Glynn. , From paul at frields.com Tue May 25 00:00:33 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 24 May 2004 20:00:33 -0400 Subject: up2date package(s) available In-Reply-To: <1085421621.30975.65.camel@bettie.internal.frields.org> References: <1085421621.30975.65.camel@bettie.internal.frields.org> Message-ID: <1085443233.31829.58.camel@bettie.internal.frields.org> On Mon, 2004-05-24 at 14:00, Paul W. Frields wrote: > Due to having a few minutes free the other night, I've done a quick > tweak to up2date that should allow folks using RHL9 to have up2date > function as it does on FC1, using fedoralegacy.org yum/apt sources. To > say this was quick and dirty would be giving me a lot more credit than > is deserved. And yet I still made a big boo-boo even though I should know better. Thanks to Chip Turner for pointing out that these should have a version number that indicates they are not Red Hat official (or FLP official, for that matter). I've renumbered them and replaced the old URL's with links to the fixed products. The new version numbers should allow upgrade to the next available package without fuss. New URL's are: BINARY: http://paul.frields.org/rpm/rhnlib-1.4-1.0.pwf.noarch.rpm http://paul.frields.org/rpm/rhn-applet-2.1.2-1.0.pwf.i386.rpm http://paul.frields.org/rpm/up2date-4.1.21-3.0.pwf.i386.rpm http://paul.frields.org/rpm/up2date-gnome-4.1.21-3.0.pwf.i386.rpm SOURCE: http://paul.frields.org/rpm/rhnlib-1.4-1.0.pwf.src.rpm http://paul.frields.org/rpm/rhn-applet-2.1.2-1.0.pwf.src.rpm http://paul.frields.org/rpm/up2date-4.1.21-3.0.pwf.src.rpm > All signed by me; my GPG key is available, among other places, at: > http://pgp.mit.edu:11371/pks/lookup?search=paul%40frields.com&op=index > Fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 This part's still good. :-) Please feel free to bring any other goofs to my attention. -- Paul W. Frields, RHCE -------------- 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 htodd at twofifty.com Tue May 25 18:09:47 2004 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Tue, 25 May 2004 11:09:47 -0700 (PDT) Subject: error from yum ".package cvs needs no (not provided)" Message-ID: Well, this is probably a misconfiguration on my part, but I keep seeing this error and I can't update cvs. I added testing to my 7.3 system, so that might be my problem. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From skvidal at phy.duke.edu Tue May 25 18:17:43 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 May 2004 14:17:43 -0400 Subject: error from yum ".package cvs needs no (not provided)" In-Reply-To: References: Message-ID: <1085509063.21890.29.camel@opus> On Tue, 2004-05-25 at 14:09, Hisashi T Fujinaka wrote: > Well, this is probably a misconfiguration on my part, but I keep seeing > this error and I can't update cvs. > > I added testing to my 7.3 system, so that might be my problem. do you have a packaged named 'no'? rpm -q no -sv From whooperhsd3 at earthlink.net Tue May 25 18:30:15 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Tue, 25 May 2004 14:30:15 -0400 (EDT) Subject: error from yum '.package cvs needs no (not provided)' In-Reply-To: References: Message-ID: <4055.12.29.16.103.1085509815.squirrel@12.29.16.103> Hisashi T Fujinaka said: > Well, this is probably a misconfiguration on my part, but I keep seeing > this error and I can't update cvs. > > I added testing to my 7.3 system, so that might be my problem. http://www.advogato.org/person/jkeating/diary.html?start=30 -- William Hooper From Freedom_Lover at pobox.com Tue May 25 18:31:51 2004 From: Freedom_Lover at pobox.com (Todd) Date: Tue, 25 May 2004 14:31:51 -0400 Subject: error from yum ".package cvs needs no (not provided)" In-Reply-To: References: Message-ID: <20040525183151.GB1584@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hisashi T Fujinaka wrote: > Well, this is probably a misconfiguration on my part, but I keep > seeing this error and I can't update cvs. The cvs package in updates-testing has problems. See the comments in https://bugzilla.fedora.us/show_bug.cgi?id=1620 - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Artificial Intelligence is no match for Natural Stupidity -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAs5EXuv+09NZUB1oRAs9/AJ4/K3HADhV2Hz/DZldoYBQiAtHgrQCdGzg4 jzaFovVb0l1gOREvzDDiduI= =6YJC -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue May 25 18:39:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 25 May 2004 11:39:12 -0700 Subject: error from yum ".package cvs needs no (not provided)" In-Reply-To: References: Message-ID: <200405251139.14956.jkeating@j2solutions.net> On Tuesday 25 May 2004 11:09, Hisashi T Fujinaka wrote: > Well, this is probably a misconfiguration on my part, but I keep > seeing this error and I can't update cvs. > > I added testing to my 7.3 system, so that might be my problem. It's a problem with the package, I need to rebuild it today. csh was not listed as a buildreq/req. Will make it today and re-issue the testing update notice. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Tue May 25 19:46:45 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 25 May 2004 13:46:45 -0600 Subject: error from yum ".package cvs needs no (not provided)" In-Reply-To: ; from htodd@twofifty.com on Tue, May 25, 2004 at 11:09:47AM -0700 References: Message-ID: <20040525134645.A4994@mail.harddata.com> On Tue, May 25, 2004 at 11:09:47AM -0700, Hisashi T Fujinaka wrote: > Well, this is probably a misconfiguration on my part, No, it is not. This is a problem in that particular package. I left a note to that effect on 2004-05-21. https://bugzilla.fedora.us/show_bug.cgi?id=1620#c20 > but I keep seeing > this error and I can't update cvs. Install not via yum but directly with 'rpm -Fvh --nodeps cvs*.i386.rpm'. '--nodeps' is someting which usually you should NOT do but in this particular case this is a workaround although it will leave dependencies on your installation "broken". Or rebuild binaries from provided .src.rpm. The later should be correct. Something went slightly haywire on a machine where these packages were originally prepared. Missing {t}csh? Michal From jkeating at j2solutions.net Wed May 26 00:50:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 25 May 2004 17:50:05 -0700 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200405211922.14897.jkeating@j2solutions.net> References: <200405211922.14897.jkeating@j2solutions.net> Message-ID: <200405251750.09434.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 21 May 2004 19:22, Jesse Keating wrote: > This update can be downloaded from: > ? http://download.fedoralegacy.org/redhat/ > ? > e4d30403a2ca8a64dfe873f739ccfb7b7e97d331 ? > 7.3/updates-testing/SRPMS/cvs-1.11.1p1-14.legacy.2.src.rpm > 1abc86e11ed907274f058fe95a1e18e56b06d561 ? > 7.3/updates-testing/i386/cvs-1.11.1p1-14.legacy.2.i386.rpm Due to a missing buildreq of tcsh, these have been rebuild and are now: de3bbf0941d5e8e75c5198ed94f497dfbf889e1a 7.3/updates-testing/SRPMS/cvs-1.11.1p1-14.legacy.3.src.rpm 72a356d222a2e576c529157556d49c31145ab4c5 7.3/updates-testing/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm - -- 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) iD8DBQFAs+nB4v2HLvE71NURArjdAJ453Hnl8Mw2P8djXUuSJQOq8qTpeQCggv6o 4sxShHQDeogh4LQsg7wL7M4= =toUI -----END PGP SIGNATURE----- From ssharma at revsharecorp.com Wed May 26 17:51:26 2004 From: ssharma at revsharecorp.com (Ajay Sharma) Date: Wed, 26 May 2004 10:51:26 -0700 Subject: up2date package(s) available In-Reply-To: <1085421621.30975.65.camel@bettie.internal.frields.org> References: <1085421621.30975.65.camel@bettie.internal.frields.org> Message-ID: <40B4D91E.2010104@revsharecorp.com> Paul W. Frields wrote: > Due to having a few minutes free the other night, I've done a quick > tweak to up2date that should allow folks using RHL9 to have up2date > function as it does on FC1, using fedoralegacy.org yum/apt sources. To > say this was quick and dirty would be giving me a lot more credit than > is deserved. Hey Paul, I downloaded your packages and ran up2date -l: ---------------------- # up2date -l Fetching package list for channel: base... Fetching http://download.fedoralegacy.org/redhat/$releasever/os/$basearch/headers/header.info... There was a fatal error communicating with the server. The message was: An HTTP error occurred: URL: http://download.fedoralegacy.org/redhat/$releasever/os/$basearch/headers/header.info Status Code: 404 Error Message: Not Found ---------------------- Do you have any idea why that url wasn't expanded into: http://download.fedoralegacy.org/redhat/9/os/i386/headers/header.info Thanks, Ajay -- Satyajot (Ajay) Sharma RevShare Corp System Administrator From paul at frields.com Wed May 26 19:00:18 2004 From: paul at frields.com (Paul W. Frields) Date: Wed, 26 May 2004 15:00:18 -0400 Subject: up2date package(s) available In-Reply-To: <40B4D91E.2010104@revsharecorp.com> References: <1085421621.30975.65.camel@bettie.internal.frields.org> <40B4D91E.2010104@revsharecorp.com> Message-ID: <1085598018.3640.47.camel@london.east.gov> On Wed, 2004-05-26 at 13:51, Ajay Sharma wrote: > I downloaded your packages and ran up2date -l: > ---------------------- > # up2date -l > > Fetching package list for channel: base... > > Fetching > http://download.fedoralegacy.org/redhat/$releasever/os/$basearch/headers/header.info... > There was a fatal error communicating with the server. The message was: > > An HTTP error occurred: > URL: > http://download.fedoralegacy.org/redhat/$releasever/os/$basearch/headers/header.info > Status Code: 404 > Error Message: Not Found > ---------------------- > > Do you have any idea why that url wasn't expanded into: > > http://download.fedoralegacy.org/redhat/9/os/i386/headers/header.info Time to open my mouth and *prove* (again) I'm an idiot. I don't believe up2date-4.1.21 resolves these variables for you... I did a "grep -r releasever *" in the up2date build tree and didn't find a hit, so my guess is that it doesn't. I didn't change anything other than the code to insert the FedoraLegacy.org public key in the rpm keyring, and the associated messages. I also think I'm recalling correctly that the FC1 version of up2date doesn't [didn't?] do mirror definitions, the way the FC2 version does, and providing a single mirror address wouldn't be the Right Thing To Do with possible users from across the globe. (Wishful thinking, I know.) :-) So I decided to leave this alone, in the hopes that people would substitute their own local mirror URLs to avoid flogging the FedoraLegacy.org site itself, as requested in previous postings to the list by Jesse K. I suppose I might take a look at the FC2 up2date and see if I can fudge it similarly. HTH, please advise if not. -- Paul W. Frields, RHCE From john at chattanooga.net Wed May 26 19:08:49 2004 From: john at chattanooga.net (John Aldrich) Date: Wed, 26 May 2004 15:08:49 -0400 Subject: up2date package(s) available In-Reply-To: <40B4D91E.2010104@revsharecorp.com> References: <1085421621.30975.65.camel@bettie.internal.frields.org> <40B4D91E.2010104@revsharecorp.com> Message-ID: <200405261508.49672.john@chattanooga.net> On Wednesday 26 May 2004 01:51 pm, Ajay Sharma wrote: [mega-snip] > ---------------------- > > Do you have any idea why that url wasn't expanded into: > > http://download.fedoralegacy.org/redhat/9/os/i386/headers/header.info > I don't know why that doesn't work, but when I first configured Yum, I had to specify the RedHat version manually in my yum.conf, and the URL that Paul sent me (off-list... Thanks, Paul!) contained the correct release version. For some reason, the default "redhat-release" info was not being found correctly. You'll need to specify your version, etc. From marcdeslauriers at videotron.ca Wed May 26 23:50:11 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 26 May 2004 19:50:11 -0400 Subject: 8.0 packages to QA Message-ID: <1085615411.22938.6.camel@mdlinux> Since I would hate to see 8.0 support being dropped from FL, I officially volunteer to make 8.0 packages. In fact, I made a bunch of them over the past couple of days. Who is going to show their support for 8.0 by volunteering to QA the packages I've made? https://bugzilla.fedora.us/show_bug.cgi?id=1581 https://bugzilla.fedora.us/show_bug.cgi?id=1551 https://bugzilla.fedora.us/show_bug.cgi?id=1549 https://bugzilla.fedora.us/show_bug.cgi?id=1545 https://bugzilla.fedora.us/show_bug.cgi?id=1376 If no one shows up, I guess 8.0 is pretty much dead and can be dropped. Marc. From christian.naumer at greyfish.net Thu May 27 06:54:52 2004 From: christian.naumer at greyfish.net (Christian Naumer) Date: Thu, 27 May 2004 08:54:52 +0200 (CEST) Subject: 8.0 packages to QA In-Reply-To: <1085615411.22938.6.camel@mdlinux> References: <1085615411.22938.6.camel@mdlinux> Message-ID: <3701.212.184.120.194.1085640892.squirrel@gate.cgg-neustadt.de> > Who is going to show their support for 8.0 by volunteering to QA the > packages I've made? Well I only got one machine running RH8 but that isn't up and running all the time. It hasnt got X on it so I can only QA the Apache module. And since you asked I can try and rebuild the OO.org package on that machine (Duron 1400). So just point me to where to dowload the Apache module. Are there any specific tests that should be run for QA. I followed the threads here on the list but not very closly so if anyone could point me to the right resource for that. Hope this could help and I would be also sorry if support for RH8 would be dropped. regards Chris From christian.naumer at greyfish.net Thu May 27 06:57:20 2004 From: christian.naumer at greyfish.net (Christian Naumer) Date: Thu, 27 May 2004 08:57:20 +0200 (CEST) Subject: 8.0 packages to QA In-Reply-To: <1085615411.22938.6.camel@mdlinux> References: <1085615411.22938.6.camel@mdlinux> Message-ID: <4014.212.184.120.194.1085641040.squirrel@gate.cgg-neustadt.de> Sorry completely missed the links in the bugzilla page. I'll download and test them now... regards Chris From rostetter at mail.utexas.edu Thu May 27 15:29:26 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 27 May 2004 10:29:26 -0500 Subject: 8.0 packages to QA In-Reply-To: <1085615411.22938.6.camel@mdlinux> References: <1085615411.22938.6.camel@mdlinux> Message-ID: <20040527102926.bfngkksgowsg8s4g@mail.ph.utexas.edu> Quoting Marc Deslauriers : > Since I would hate to see 8.0 support being dropped from FL, I > officially volunteer to make 8.0 packages. Great. I would also hate to see it dropped. But, unfortunately, I am currently, as I type, upgrading my only RH 8.0 server to RH 9... > Who is going to show their support for 8.0 by volunteering to QA the > packages I've made? I will try to test them, but unfortunately I can't do much. I'll hopefully soon no longer have a RH 8.0 server. I'll try to create a RH 8.0 test environment, but this will really only allow me to test that they install/run and not give them a proper usability test. > If no one shows up, I guess 8.0 is pretty much dead and can be dropped. I think most people who still use RH 8.0 do so on a server environment. Most of them won't be able to test emacs/flim, xchat, or openoffice since these are typically not installed on a server. So don't expect much testing of these (though maybe you will get lucky). The apache and wu-ftpd packages should draw some interest! > Marc. -- Eric Rostetter From maillist at jasonlim.com Thu May 27 16:18:01 2004 From: maillist at jasonlim.com (Jason Lim) Date: Fri, 28 May 2004 00:18:01 +0800 Subject: 8.0 packages to QA References: <1085615411.22938.6.camel@mdlinux> <20040527102926.bfngkksgowsg8s4g@mail.ph.utexas.edu> Message-ID: <061b01c44406$30d73800$ce00a8c0@SYSTEM9> much dead and can be dropped. > > I think most people who still use RH 8.0 do so on a server environment. > Most of them won't be able to test emacs/flim, xchat, or openoffice since > these are typically not installed on a server. So don't expect much > testing of these (though maybe you will get lucky). The apache and > wu-ftpd packages should draw some interest! I second that. We run RH 8.0 on servers, so certainly no OO.org, xchat, etc. is installed. But I can test out the other packages, like wu-ftpd and others! From mic at npgx.com.au Thu May 27 21:54:15 2004 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 28 May 2004 07:54:15 +1000 Subject: 8.0 packages to QA In-Reply-To: <061b01c44406$30d73800$ce00a8c0@SYSTEM9> References: <1085615411.22938.6.camel@mdlinux> <20040527102926.bfngkksgowsg8s4g@mail.ph.utexas.edu> <061b01c44406$30d73800$ce00a8c0@SYSTEM9> Message-ID: <20040527214800.M89533@npgx.com.au> > much dead and can be dropped. > > > > I think most people who still use RH 8.0 do so on a server environment. > > Most of them won't be able to test emacs/flim, xchat, or openoffice > since > > these are typically not installed on a server. So don't expect much > > testing of these (though maybe you will get lucky). The apache and > > wu-ftpd packages should draw some interest! > > I second that. We run RH 8.0 on servers, so certainly no OO.org, > xchat, etc. is installed. > > But I can test out the other packages, like wu-ftpd and others! And I'll third that too :) .. I can test/QA packages in a production environment, but even here that won't be for too much longer. I only have two RH8 servers left (I've decommissioned 6 of them already), and am currently in the final stages migrating them to FC1. They've served us well for many years, but with the RH end of life and FL end of support looming, it's not really leaving us with too much choice but to move away from the older platforms altogether. Michael. From Ow.Mun.Heng at wdc.com Fri May 28 02:07:49 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Thu, 27 May 2004 19:07:49 -0700 Subject: 8.0 packages to QA In-Reply-To: <061b01c44406$30d73800$ce00a8c0@SYSTEM9> References: <1085615411.22938.6.camel@mdlinux> <20040527102926.bfngkksgowsg8s4g@mail.ph.utexas.edu> <061b01c44406$30d73800$ce00a8c0@SYSTEM9> Message-ID: <1085710069.5955.31.camel@Neuromancer.home.net> On Thu, 2004-05-27 at 09:18, Jason Lim wrote: > much dead and can be dropped. > > > > I think most people who still use RH 8.0 do so on a server environment. > > Most of them won't be able to test emacs/flim, xchat, or openoffice > since > > these are typically not installed on a server. So don't expect much > > testing of these (though maybe you will get lucky). The apache and > > wu-ftpd packages should draw some interest! > > I second that. We run RH 8.0 on servers, so certainly no OO.org, xchat, > etc. is installed. Marc et. all, You guys are doing great job. Us who are left in the lurch from Redhat's demise (in this "business" segment) and who don't really know how to begin patching stuffs, really welcomes these updates. I've most certainly will need the httpd updates. I've Update my servers already with your new releases. Thanks a million. -- From christian.naumer at greyfish.net Fri May 28 12:02:51 2004 From: christian.naumer at greyfish.net (Christian Naumer) Date: Fri, 28 May 2004 14:02:51 +0200 Subject: 8.0 packages to QA In-Reply-To: <3701.212.184.120.194.1085640892.squirrel@gate.cgg-neustadt.de> References: <1085615411.22938.6.camel@mdlinux> <3701.212.184.120.194.1085640892.squirrel@gate.cgg-neustadt.de> Message-ID: <1085745771.2507.3.camel@nachtschatten> Am Do, den 27.05.2004 schrieb Christian Naumer um 8:54: > Well I only got one machine running RH8 but that isn't up and running all > the time. It hasnt got X on it so I can only QA the Apache module. And > since you asked I can try and rebuild the OO.org package on that machine > (Duron 1400). Sorry to say but I couldn't rebuild the OO package. It is not due to any build errors but buildspace on my harddrive. I only have aubout 3Gig left and that wasn't enough to build OO completely. Again sorry next time I'll check first. I installed the Apache module and so far had no Problems. regards Chris From khismaeel at ecs.gov.eg Sun May 30 06:41:32 2004 From: khismaeel at ecs.gov.eg (khaled fawzy) Date: Sun, 30 May 2004 09:41:32 +0300 Subject: LHA security vulnerabilities Message-ID: <000f01c44611$29fc85a0$d90310ac@traderep.com> dear sir; Is redhat 9 vulnerable to LHA package security vulnerabilities. thanks in advance. khaled From jonny.strom at netikka.fi Sun May 30 08:42:31 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Sun, 30 May 2004 11:42:31 +0300 Subject: LHA security vulnerabilities In-Reply-To: <000f01c44611$29fc85a0$d90310ac@traderep.com> References: <000f01c44611$29fc85a0$d90310ac@traderep.com> Message-ID: <40B99E77.90205@netikka.fi> khaled fawzy wrote: > dear sir; > Is redhat 9 vulnerable to LHA package security vulnerabilities. > thanks in advance. No we do not think so. > khaled > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From fedoraleg_form at mm-vanecek.cc Sun May 30 14:59:01 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Sun, 30 May 2004 09:59:01 -0500 Subject: LHA security vulnerabilities In-Reply-To: <000f01c44611$29fc85a0$d90310ac@traderep.com> References: <000f01c44611$29fc85a0$d90310ac@traderep.com> Message-ID: <20040530145409.M25139@mm-vanecek.cc> On Sun, 30 May 2004 09:41:32 +0300, khaled fawzy wrote > dear sir; > Is redhat 9 vulnerable to LHA package security vulnerabilities. > thanks in advance. I had the same question ... I decided to download lha-1.14i-12.1.src.rpm from http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/SRPMS/. Rebuilt the binary on my RH 9 system and installed it. Seems to be doing OK as far as I can tell. From marcdeslauriers at videotron.ca Sun May 30 15:31:12 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 30 May 2004 11:31:12 -0400 Subject: LHA security vulnerabilities In-Reply-To: <000f01c44611$29fc85a0$d90310ac@traderep.com> References: <000f01c44611$29fc85a0$d90310ac@traderep.com> Message-ID: <1085931072.1869.0.camel@mdlinux> On Sun, 2004-05-30 at 02:41, khaled fawzy wrote: > dear sir; > Is redhat 9 vulnerable to LHA package security vulnerabilities. Red Hat came out with a LHA security update before they EOL'd RHL9. https://rhn.redhat.com/errata/RHSA-2004-179.html Marc. From marcdeslauriers at videotron.ca Sun May 30 15:31:58 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 30 May 2004 11:31:58 -0400 Subject: 8.0 packages to QA In-Reply-To: <1085745771.2507.3.camel@nachtschatten> References: <1085615411.22938.6.camel@mdlinux> <3701.212.184.120.194.1085640892.squirrel@gate.cgg-neustadt.de> <1085745771.2507.3.camel@nachtschatten> Message-ID: <1085931117.1869.2.camel@mdlinux> On Fri, 2004-05-28 at 08:02, Christian Naumer wrote: > Sorry to say but I couldn't rebuild the OO package. It is not due to any > build errors but buildspace on my harddrive. I only have aubout 3Gig Doesn't matter, my machine finished building it. Thanks for trying! Marc. From jkeating at j2solutions.net Mon May 31 21:19:19 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 14:19:19 -0700 Subject: Fedora Legacy Test Update Notification: rsync Message-ID: <200405311419.19956.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1569 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1569 2004-05-31 - --------------------------------------------------------------------- Name : rsync Version 7.3 : 2.5.7-1.legacy.7x Version 9 : 2.5.7-1.legacy.9 Summary : A program for synchronizing files over a network. Description : Rsync uses a reliable algorithm to bring remote and host files into sync very quickly. Rsync is fast because it just sends the differences in the files over the network instead of sending the complete files. Rsync is often used as a very powerful mirroring process or just as a more capable replacement for the rcp command. A technical report which describes the rsync algorithm is included in this package. - --------------------------------------------------------------------- Update Information: CAN-2004-0426: rsync before 2.6.1 does not properly sanitize paths when running a read/write daemon without using chroot, allows remote attackers to write files outside of the module's path. - --------------------------------------------------------------------- Changelog: 7.3: * Wed May 05 2004 Seth Vidal 2.5.7-1.legacy.7x - - apply sanitize path's patch for: - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0426 - - Fix for segfault when RSYNC_PROXY port part is too long 9: * Tue May 04 2004 Rok Papez 2.5.7-1.legacy.9 - - Fix for segfault when RSYNC_PROXY port part is too long - - Fix for CAN-2004-0426: not properly sanitizing paths - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ d4d63c594b993ec4194b2b1145abe71348e984e8 7.3/updates-testing/SRPMS/rsync-2.5.7-1.legacy.7x.src.rpm c7960f3fdf5a053c459ee063651470fa95a5dc00 7.3/updates-testing/i386/rsync-2.5.7-1.legacy.7x.i386.rpm 36ab488484efbb6a6c7e03b06b6cc3f9810bdcae 9/updates-testing/SRPMS/rsync-2.5.7-1.legacy.9.src.rpm 341b5116c4a761b212d00a15e5262a6dc6ca17e3 9/updates-testing/i386/rsync-2.5.7-1.legacy.9.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu6FX4v2HLvE71NURApEVAJ41WnakDFtXtHpFT1gu1c3VH6hl4ACeKYsX 0uPUJghzTzpdTYATxMegNhs= =bRou -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon May 31 21:40:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 14:40:00 -0700 Subject: Fedora Legacy Test Update Notification: wu-ftpd Message-ID: <200405311440.00654.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1376 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1376 2004-05-31 - --------------------------------------------------------------------- Name : wu-ftpd Version 7.3 : 2.6.2-14.legacy.7x Summary : An FTP daemon provided by Washington University. Description : The wu-ftpd package contains the wu-ftpd FTP (File Transfer Protocol) server daemon. The FTP protocol is a method of transferring files between machines on a network and/or over the Internet. Wu-ftpd's features include logging of transfers, logging of commands, on the fly compression and archiving, classification of users' type and location, per class limits, per directory upload permissions, restricted guest accounts, system wide and per directory messages, directory alias, cdpath, filename filter, and virtual host support. - --------------------------------------------------------------------- Update Information: CAN-1999-0997: wu-ftp with FTP conversion enabled allows an attacker to execute commands via a malformed file name that is interpreted as an argument to the program that does the conversion, e.g. tar or uncompress. CAN-2004-0148: wu-ftpd 2.6.2 and earlier, with the restricted-gid option enabled, allows local users to bypass access restrictions by changing the permissions to prevent access to their home directory, which causes wu-ftpd to use the root directory instead. CAN-2004-0185: Buffer overflow in the skey_challenge function in ftpd.c for wu-ftp daemon (wu-ftpd) 2.6.2 allows remote attackers to cause a denial of service and possibly execute arbitrary code via a s/key (SKEY) request with a long name. - --------------------------------------------------------------------- Changelog: 7.3: * Mon May 31 2004 Jesse Keating 2.6.2-14.legacy.7x - - Added byacc to buildreqs * Sat May 22 2004 Marc Deslauriers 2.6.2-13.legacy.7x - - bugfix release CAN-1999-0997 ftp conversions - - CAN-2004-0148 escape from home - - CAN-2004-0185 skeychallenge - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 4fafbba3bd2a5522d5ad39ad4a1ae742751628d5 7.3/updates-testing/SRPMS/wu-ftpd-2.6.2-14.legacy.7x.src.rpm 8005185d531ffc61f6b749b7a49b4875fbd49e33 7.3/updates-testing/i386/wu-ftpd-2.6.2-14.legacy.7x.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu6Yw4v2HLvE71NURAi6RAJ9j5KaQuouyXBv46IV/W0fbAwW+jwCgs7Jz c53WqsP/T6x8jARsyNTXXGQ= =Hw8Y -----END PGP SIGNATURE----- From cra at WPI.EDU Mon May 31 21:49:48 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 31 May 2004 17:49:48 -0400 Subject: Fedora Legacy Test Update Notification: wu-ftpd In-Reply-To: <200405311440.00654.jkeating@j2solutions.net> References: <200405311440.00654.jkeating@j2solutions.net> Message-ID: <20040531214948.GE21370@angus.ind.WPI.EDU> On Mon, May 31, 2004 at 02:40:00PM -0700, Jesse Keating wrote: > Version 7.3 : 2.6.2-14.legacy.7x Why is the legacy tag in the middle of the release number? Previous updates always had it at the end... From jkeating at j2solutions.net Mon May 31 21:50:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 14:50:33 -0700 Subject: Fedora Legacy Test Update Notification: wu-ftpd In-Reply-To: <20040531214948.GE21370@angus.ind.WPI.EDU> References: <200405311440.00654.jkeating@j2solutions.net> <20040531214948.GE21370@angus.ind.WPI.EDU> Message-ID: <200405311450.33575.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 31 May 2004 14:49, Charles R. Anderson wrote: > Why is the legacy tag in the middle of the release number? ?Previous > updates always had it at the end... Oversight. - -- 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) iD8DBQFAu6ip4v2HLvE71NURAmlfAJ9NmSXETuKxrv5kJ6kM7rtUqX3fhwCePcm7 pngzK4kYawJDM7ARzD8weS0= =tQ6D -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon May 31 21:54:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 14:54:05 -0700 Subject: Fedora Legacy Test Update Notification: mod_python Message-ID: <200405311454.05223.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1325 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1325 2004-05-31 - --------------------------------------------------------------------- Name : mod_python Version 7.3 : 1.7.3.2.legacy Summary : An embedded Python interpreter for the Apache Web server. Description : Mod_python is a module that embeds the Python language interpreter within the server, allowing Apache handlers to be written in Python. Mod_python brings together the versatility of Python and the power of the Apache Web server for a considerable boost in flexibility and performance over the traditional CGI approach. - --------------------------------------------------------------------- Update Information: CAN-2003-0973: Unknown vulnerability in mod_python 3.0.x before 3.0.4, and 2.7.x before 2.7.9, allows remote attackers to cause a denial of service (httpd crash) via a certain query string. - --------------------------------------------------------------------- Changelog: 7.3: * Sun May 02 2004 Jonny Strom 2.7.8-1 - - update for CAN-2003-0973 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 49aa1436fc8982e616b5957554485e278d772f9b 7.3/updates-testing/SRPMS/mod_python-2.7.8-1.7.3.2.legacy.src.rpm 1cb0e3eccd14fbfb220bf26259b509ff17ed9eec 7.3/updates-testing/i386/mod_python-2.7.8-1.7.3.2.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu6l94v2HLvE71NURAuhGAKCYGhw4r/bN52+bCwqDj4efShv3owCghGO4 4brPvHAJjAyzJvHHz50r3F0= =cfPG -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon May 31 22:05:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 15:05:58 -0700 Subject: Fedora Legacy Test Update Notification: libxml2 Message-ID: <200405311505.58597.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1324 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1324 2004-05-31 - --------------------------------------------------------------------- Name : libxml2 Version 7.3 : 2.4.19-5.legacy Summary : Library providing XML and HTML support. Description : This library lets you manipulate XML files. It includes support to read, modify, and write XML and HTML files. It has DTD support, including parsing and validation, even with complex DTDs. The output can be a simple SAX stream or an in-memory DOM like representation. In this case you can use the built-in XPath and XPointer implementation to select subnodes or ranges. A flexible Input/Output mechanism is available, with existing HTTP and FTP modules and combined to an URI library. - --------------------------------------------------------------------- Update Information: CAN-2004-0110: Buffer overflow in the (1) nanohttp or (2) nanoftp modules in XMLSoft Libxml2 2.6.0 through 2.6.5 allow remote attackers to execute arbitrary code via a long URL. - --------------------------------------------------------------------- Changelog: 7.3: * Sat May 01 2004 Seth Vidal - - updated patch with patch from bug #1324 comment 4 - - added buildrequires from comment 6 * Fri Feb 27 2004 Dominic Hargreaves - - fixes overflow when parsing remote resources - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 7ea6c8e40a04c2eafb82d53e8e6931b27348f4ad 7.3/updates-testing/SRPMS/libxml2-2.4.19-5.legacy.src.rpm c325b2b9d03335b41db6b0b462a35d1ed847e56f 7.3/updates-testing/i386/libxml2-2.4.19-5.legacy.i386.rpm c53f70cad435630b3e5b5f5d363c7d425f980a35 7.3/updates-testing/i386/libxml2-devel-2.4.19-5.legacy.i386.rpm 8819fa789731693645839f32f55aac2f2dc27906 7.3/updates-testing/i386/libxml2-python-2.4.19-5.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu6xG4v2HLvE71NURAthaAJ0RDpR6ioSi9/wPO90LRslU0q3WkQCgluW1 FlbqgJM4oSDXNDbN7YsGUs8= =Mi+z -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon May 31 22:26:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 15:26:58 -0700 Subject: Fedora Legacy Test Update Notification: gdk-pixbuf Message-ID: <200405311526.58329.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1371 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1371 2004-05-31 - --------------------------------------------------------------------- Name : gdk-pixbuf Version 7.3 : 0.14.0-9.legacy.1 Summary : An image loading library used with GNOME. Description : The gdk-pixbuf package contains an image loading library used with the GNOME desktop environment. The GdkPixBuf library provides image loading facilities, the rendering of a GdkPixBuf into various formats (drawables or GdkRGB buffers), and a cache interface. - --------------------------------------------------------------------- Update Information: CAN-2004-0111: gdk-pixbuf before 0.20 allows attackers to cause a denial of service (crash) via a malformed bitmap (BMP) file. - --------------------------------------------------------------------- Changelog: 7.3: * Mon May 31 2004 Jesse Keating - - Added missing buildreqs * Sat May 01 2004 Seth Vidal - - bmp colormap check fix - - fixes http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0111 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ cebed6a9021cf4002f6d403a115ad9d21f2a9c03 7.3/updates-testing/SRPMS/gdk-pixbuf-0.14.0-9.legacy.1.src.rpm f7d01aa00978b6d4e1f341cf4e5c4b5f1bc90602 7.3/updates-testing/i386/gdk-pixbuf-0.14.0-9.legacy.1.i386.rpm c7c4614f2ab7c662f8f1c025f5490851c3d1b418 7.3/updates-testing/i386/gdk-pixbuf-devel-0.14.0-9.legacy.1.i386.rpm e060399ff750d635fb3f540608902778d5b55791 7.3/updates-testing/i386/gdk-pixbuf-gnome-0.14.0-9.legacy.1.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu7Ey4v2HLvE71NURAjKYAJ430SMhrZ91Wj4EIIf9+Y6ghepdoQCgnGIc SI+krF1QUwvV538v6ixXpik= =pvRw -----END PGP SIGNATURE----- From jimpop at yahoo.com Mon May 31 22:35:30 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 31 May 2004 18:35:30 -0400 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200405251750.09434.jkeating@j2solutions.net> References: <200405211922.14897.jkeating@j2solutions.net> <200405251750.09434.jkeating@j2solutions.net> Message-ID: <1086042930.32727.29.camel@blue> I'm not sure if this matters, but on a mostly fresh and stable 7.3 test box, I got the following warning when I yum update'ed cvs: --------------------------------------------------------- Getting cvs-1.11.1p1-14.legacy.3.i386.rpm Calculating available disk space - this could take a bit cvs 100 % done install-info: warning: no info dir entry in `//usr/share/info/cvs.info.gz' install-info: warning: no info dir entry in `//usr/share/info/cvsclient.info.gz' Updated: cvs.i386 Transaction(s) Complete --------------------------------------------------------- -Jim P. On Tue, 2004-05-25 at 20:50, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 21 May 2004 19:22, Jesse Keating wrote: > > This update can be downloaded from: > > http://download.fedoralegacy.org/redhat/ > > > > e4d30403a2ca8a64dfe873f739ccfb7b7e97d331 > > 7.3/updates-testing/SRPMS/cvs-1.11.1p1-14.legacy.2.src.rpm > > 1abc86e11ed907274f058fe95a1e18e56b06d561 > > 7.3/updates-testing/i386/cvs-1.11.1p1-14.legacy.2.i386.rpm > > Due to a missing buildreq of tcsh, these have been rebuild and are now: > > de3bbf0941d5e8e75c5198ed94f497dfbf889e1a > 7.3/updates-testing/SRPMS/cvs-1.11.1p1-14.legacy.3.src.rpm > 72a356d222a2e576c529157556d49c31145ab4c5 > 7.3/updates-testing/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm > > - -- > 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) > > iD8DBQFAs+nB4v2HLvE71NURArjdAJ453Hnl8Mw2P8djXUuSJQOq8qTpeQCggv6o > 4sxShHQDeogh4LQsg7wL7M4= > =toUI > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Mon May 31 22:38:09 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 May 2004 15:38:09 -0700 Subject: Fedora Legacy Test Update Notification: sysstat Message-ID: <200405311538.09776.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1372 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1372 2004-05-31 - --------------------------------------------------------------------- Name : sysstat Version 7.3 : 4.0.3-3.legacy Summary : The sar and iostat system monitoring commands. Description : This package provides the sar and iostat commands for Linux. Sar and iostat enable system monitoring of disk, network, and other IO activity. - --------------------------------------------------------------------- Update Information: CAN-2004-0107: The (1) post and (2) trigger scripts in sysstat 4.0.7 and earlier allow local users to overwrite arbitrary files via symlink attacks on temporary files, a different vulnerability than CAN-2004-0108. - --------------------------------------------------------------------- Changelog: 7.3: * Thu Mar 11 2004 Michael Schwendt 4.0.3-3.legacy - - Fix CAN-2004-0107 in triggerpostun. - - Add buildreq gettext. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ c1af56083459a8b771846142e668a24765b35b58 7.3/updates-testing/SRPMS/sysstat-4.0.3-3.legacy.src.rpm 62cf6b1362f2a9eeec5ea39a7aa2e1dc0f5c74d7 7.3/updates-testing/i386/sysstat-4.0.3-3.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- 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) iD8DBQFAu7PR4v2HLvE71NURAue9AKCBmBKv0kaxnu+n3oE4SpGWVMLmQwCgkiWI wiBCPu/9/XPjrd2YDnq6eSA= =Pfg3 -----END PGP SIGNATURE----- From ehemdal at townisp.com Mon May 31 23:38:16 2004 From: ehemdal at townisp.com (J. Erik Hemdal) Date: Mon, 31 May 2004 19:38:16 -0400 Subject: Help with Intel PRO/1000 NIC Message-ID: <000401c44768$5c827180$6501a8c0@2Z1BG31> I have to install an Intel PRO/1000 interface board into a Dell PowerEdge server running RHAT 8.0 (kernel 2.4.18). Visiting the Intel site provides source for a driver which Intel claims will build correctly on kernels up through 2.4.20. Fair enough. Various vendor sites provide testimonials that attest to success with the card...but nothing specific otherwise by Googling. Can anyone offer advice on what to look for/look out for when installing the card and driver for this board? Thanks for the help. Erik From jy.cadic at medcost.fr Wed May 19 15:15:14 2004 From: jy.cadic at medcost.fr (jyc) Date: Wed, 19 May 2004 15:15:14 -0000 Subject: [OK-JYC] Re: Good bye, Fedora Legacy! In-Reply-To: <40A9F691.8020204@netikka.fi> References: <1084853693.40a98dbd9d929@192.168.40.40> <40A9F691.8020204@netikka.fi> Message-ID: <20040519170954.286F.JY.CADIC@medcost.fr> hello guys ! i just would like to thank all the guys working on this project you all do a wonderful job ! i could not be able to do all these things by myself. i'm not a developper, i'm unable to cook a good rpm without using alien... and i have so many 7.3 to manage without any opportunity to move them to another linux-distro... the fedora-legacy project is just a great exemple of the true power of open source. "Chapeau bas messieurs ! " as we say in France. (literally : i bring my hat down near the floor to show you m respect) long live the fedora-legacy project ! From afk at machos.ru Mon May 31 13:55:24 2004 From: afk at machos.ru (afk at machos.ru) Date: Mon, 31 May 2004 20:55:24 +0700 Subject: httpd 2.0.40 mod_ssl security vulnerability Message-ID: <1086011724.40bb394cdc0fc@webmail.machos.ru> Hello guys! Sorry for my bad english. I've read recently (http://www.securityfocus.com/bid/10355/info/) that httpd 2.0.40 which comes with RedHat 9 is vulnerable to the issue. Does anybody know, will Fedora-Legacy Project release an update to httpd package? ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/