From dom at earth.li Tue Jun 1 15:09:27 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 1 Jun 2004 16:09:27 +0100 Subject: Help with Intel PRO/1000 NIC In-Reply-To: <000401c44768$5c827180$6501a8c0@2Z1BG31> References: <000401c44768$5c827180$6501a8c0@2Z1BG31> Message-ID: <20040601150927.GF11946@tirian.magd.ox.ac.uk> On Mon, May 31, 2004 at 07:38:16PM -0400, J. Erik Hemdal wrote: > I have to install an Intel PRO/1000 interface board into a Dell > PowerEdge server running RHAT 8.0 (kernel 2.4.18). Install the latest kernel errata (latest published release is 2.4.20-30.8.legacy, unofficial candidates for some further security fixes at ) Either is likely to fix your problem. Both the 2.4.18 and 2.4.20 RPMs have e1000 support, but the latest 2.4.20 errata has a better chance of recognising your specific revision (I'm assuming here that you have tried to modprobe e1000 already). Cheers, Dominic. From jkeating at j2solutions.net Tue Jun 1 18:47:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 1 Jun 2004 11:47:50 -0700 Subject: CVS Review needed Message-ID: <200406011147.53704.jkeating@j2solutions.net> There is a sudden influx of CVS issues, and I'm not sure what all CVEs our packages address. Can some of you check https://bugzilla.fedora.us/show_bug.cgi?id=1620 for the following CVE coverage: CAN-2004-0180 CAN-2004-0396 CAN-2004-0414 CAN-2004-0416 CAN-2004-0417 CAN-2004-0418 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 hbo at egbok.com Tue Jun 1 19:24:14 2004 From: hbo at egbok.com (Howard Owen) Date: Tue, 1 Jun 2004 12:24:14 -0700 (PDT) Subject: CVS Review needed In-Reply-To: <200406011147.53704.jkeating@j2solutions.net> Message-ID: CAN-2004-0414 through 418 are still "reserved." Looking at the sources in http://download.fedoralegacy.org/redhat/7.3/updates-testing/SRPMS/cvs-1.11.1p1-14.legacy.3.src.rpm 03cvs-client-exploit-fix-1.11.2.diff contains a patch similar to the OpenBSD patch for CAN-2004-0180. ccvs-exploit-20040519.2.diff contains a patch similar to the FreeBSD and OpenBSD patches for CAN-2004-0396. On Tue, 1 Jun 2004, Jesse Keating wrote: > There is a sudden influx of CVS issues, and I'm not sure what all CVEs > our packages address. Can some of you check > https://bugzilla.fedora.us/show_bug.cgi?id=1620 for the following CVE > coverage: > > CAN-2004-0180 CAN-2004-0396 CAN-2004-0414 CAN-2004-0416 CAN-2004-0417 > CAN-2004-0418 > > Thanks. > > -- 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 jimpop at yahoo.com Tue Jun 1 19:29:51 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 01 Jun 2004 15:29:51 -0400 Subject: CVS Review needed In-Reply-To: <200406011147.53704.jkeating@j2solutions.net> References: <200406011147.53704.jkeating@j2solutions.net> Message-ID: <1086118191.8479.54.camel@blue> Well, for starters, CAN-2004-0414/0416/0417/0418 haven't been published yet. CAN-2004-0396 is the most serious as it allows remote users to attack cvs servers. CAN-2004-0180 is the reverse, it allows a malicious server to attack a user. RedHat's response to CAN-2004-0396 http://rhn.redhat.com/errata/RHSA-2004-190.html RedHat's response to CAN-2004-0180 (which also mentions CAN-2004-0405) http://rhn.redhat.com/errata/RHSA-2004-154.html CAN-2004-0405(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0405) is probably just as bad as CAN-2004-0396 and therefore both fixes need to be implemented in legacy. So, according to Comment #19 (Daniel Drown) 2004-05-21, for bug 1620, cvs-1.11.1p1-9.7.legacy.src.rpm includes fixes for both CAN-2004-0396 and CVE-2004-0180 (although Daniels' comments should be CAN-2004-0180 not CVE-2004-0180). Presumably this was carried forward into the cvs-1.11.1p1-14.legacy.3.i386.rpm that exists in testing. ;) hth, -Jim P. On Tue, 2004-06-01 at 14:47, Jesse Keating wrote: > There is a sudden influx of CVS issues, and I'm not sure what all CVEs > our packages address. Can some of you check > https://bugzilla.fedora.us/show_bug.cgi?id=1620 for the following CVE > coverage: > > CAN-2004-0180 CAN-2004-0396 CAN-2004-0414 CAN-2004-0416 CAN-2004-0417 > CAN-2004-0418 > > Thanks. From hbo at egbok.com Tue Jun 1 22:37:07 2004 From: hbo at egbok.com (Howard Owen) Date: Tue, 1 Jun 2004 15:37:07 -0700 (PDT) Subject: CVS Review needed In-Reply-To: <1086118191.8479.54.camel@blue> Message-ID: That's interesting. Red Hat hasn't seen fit to patch for CAN-2004-0405 yet. (The latest sources for RHEL3 don't contain the code produced by the patch at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch). The client.c code in the legacy srpm doesn't contain the fix, either. (src/client.c, call_in_directory() function, starting at line 997) On Tue, 1 Jun 2004, Jim Popovitch wrote: > > Well, for starters, CAN-2004-0414/0416/0417/0418 haven't been published > yet. CAN-2004-0396 is the most serious as it allows remote users to > attack cvs servers. CAN-2004-0180 is the reverse, it allows a malicious > server to attack a user. > > RedHat's response to CAN-2004-0396 > http://rhn.redhat.com/errata/RHSA-2004-190.html > > RedHat's response to CAN-2004-0180 (which also mentions CAN-2004-0405) > http://rhn.redhat.com/errata/RHSA-2004-154.html > > CAN-2004-0405(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0405) is probably just as bad as CAN-2004-0396 and therefore both fixes need to be implemented in legacy. > > So, according to Comment #19 (Daniel Drown) 2004-05-21, for bug 1620, > cvs-1.11.1p1-9.7.legacy.src.rpm includes fixes for both CAN-2004-0396 > and CVE-2004-0180 (although Daniels' comments should be CAN-2004-0180 > not CVE-2004-0180). Presumably this was carried forward into the > cvs-1.11.1p1-14.legacy.3.i386.rpm that exists in testing. ;) > > hth, > > -Jim P. > > > On Tue, 2004-06-01 at 14:47, Jesse Keating wrote: > > There is a sudden influx of CVS issues, and I'm not sure what all CVEs > > our packages address. Can some of you check > > https://bugzilla.fedora.us/show_bug.cgi?id=1620 for the following CVE > > coverage: > > > > CAN-2004-0180 CAN-2004-0396 CAN-2004-0414 CAN-2004-0416 CAN-2004-0417 > > CAN-2004-0418 > > > > Thanks. > > > -- > 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 cradle at umd.edu Wed Jun 2 15:50:19 2004 From: cradle at umd.edu (David Eisner) Date: Wed, 02 Jun 2004 11:50:19 -0400 Subject: Red Hat 9 Updates Message-ID: <40BDF73B.5020500@umd.edu> I notice that there are no RH9 advisories listed yet: http://www.fedoralegacy.org/updates/RH9/ Is it safe to depend on Fedora Legacy to provide security updates for a RH9 system? In all sincerity, this is not a complaint. I realize Fedora Legacy is a volunteer effort with limited resources, and there are no free lunches. I just need to make an informed decision about whether I should start upgrading my RH9 systems to another OS (RHEL, FC, etc.). Thanks in advance. -David --------------------------------------------------------- D a v i d E i s n e r c r a d l e @ u m d . e d u CALCE EPSC University of Maryland From ametzler at logic.univie.ac.at Wed Jun 2 15:56:53 2004 From: ametzler at logic.univie.ac.at (Andreas Metzler) Date: Wed, 2 Jun 2004 17:56:53 +0200 Subject: Red Hat 9 Updates In-Reply-To: <40BDF73B.5020500@umd.edu> References: <40BDF73B.5020500@umd.edu> Message-ID: <20040602155651.GB4436@balrog.logic.univie.ac.at> On Wed, Jun 02, 2004 at 11:50:19AM -0400, David Eisner wrote: > I notice that there are no RH9 advisories listed yet: > http://www.fedoralegacy.org/updates/RH9/ > Is it safe to depend on Fedora Legacy to provide > security updates for a RH9 system? > In all sincerity, this is not a complaint. I realize > Fedora Legacy is a volunteer effort with limited > resources, and there are no free lunches. I just > need to make an informed decision about whether I > should start upgrading my RH9 systems to another > OS (RHEL, FC, etc.). Currently fedora-legacy seems to have turnaround times of more than month. - You should decide whether you can live with that. cu andreas From jkeating at j2solutions.net Wed Jun 2 15:57:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 2 Jun 2004 08:57:48 -0700 Subject: Red Hat 9 Updates In-Reply-To: <40BDF73B.5020500@umd.edu> References: <40BDF73B.5020500@umd.edu> Message-ID: <200406020857.48454.jkeating@j2solutions.net> On Wednesday 02 June 2004 08:50, David Eisner wrote: > I notice that there are no RH9 advisories listed yet: > > http://www.fedoralegacy.org/updates/RH9/ > > Is it safe to depend on Fedora Legacy to provide > security updates for a RH9 system? > > In all sincerity, this is not a complaint. I realize > Fedora Legacy is a volunteer effort with limited > resources, and there are no free lunches. I just > need to make an informed decision about whether I > should start upgrading my RH9 systems to another > OS (RHEL, FC, etc.). > > Thanks in advance. There have been a couple items pushed into updates-testing for RHL9, and there are some more coming up. I had a serious lack of time issue over the last couple months, and we were trying to work on more than we had the resources for. We've 'trimmed the fat' by dropping support for 7.2/8.0, and I have more free time now so that I can focus on pushing these updates. -- 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 Wed Jun 2 16:07:52 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 2 Jun 2004 17:07:52 +0100 Subject: Red Hat 9 Updates In-Reply-To: <200406020857.48454.jkeating@j2solutions.net> References: <40BDF73B.5020500@umd.edu> <200406020857.48454.jkeating@j2solutions.net> Message-ID: <20040602160752.GN11946@tirian.magd.ox.ac.uk> On Wed, Jun 02, 2004 at 08:57:48AM -0700, Jesse Keating wrote: > There have been a couple items pushed into updates-testing for RHL9, and > there are some more coming up. I had a serious lack of time issue over > the last couple months, and we were trying to work on more than we had > the resources for. We've 'trimmed the fat' by dropping support for > 7.2/8.0, and I have more free time now so that I can focus on pushing > these updates. Although I was aware you had pretty much decided on that I haven't seen anything sent to fedora-legacy-announce. That list should probably be told (sorry if you have already got this on your todo list :) Cheers, Dominic. From jlee at pbu.edu Wed Jun 2 16:04:36 2004 From: jlee at pbu.edu (Jay Lee) Date: Wed, 2 Jun 2004 12:04:36 -0400 (EDT) Subject: Red Hat 9 Updates In-Reply-To: <40BDF73B.5020500@umd.edu> References: <40BDF73B.5020500@umd.edu> Message-ID: <52936.10.1.1.92.1086192276.squirrel@10.1.1.92> David Eisner said: > I notice that there are no RH9 advisories listed yet: > > http://www.fedoralegacy.org/updates/RH9/ > > Is it safe to depend on Fedora Legacy to provide > security updates for a RH9 system? > > In all sincerity, this is not a complaint. I realize > Fedora Legacy is a volunteer effort with limited > resources, and there are no free lunches. I just > need to make an informed decision about whether I > should start upgrading my RH9 systems to another > OS (RHEL, FC, etc.). Noticing your .edu email address, you could purchase RHEL AS 3 for just $50 or WS for $25, I went this route with 4 of my servers and just Monday moved my last RH9 box up to FC2 (it's an internal server so I keep it a little more bleeding edge). I've found RHEL3 to be an excellent replacement to RH9, pricing is kinda hard on the commercial businesses but not for those of us in education :) I do have one last RH7.3 box and the proprietary app that runs on it won't work with RH8+, just crashes, not sure where the issue is. I have that box pulling updates via apt from fedoralegacy and haven't had any issues so far. Jay -- Jay Lee Network / Systems Administrator Information Technology Dept. Philadelphia Biblical University -- I say, if your knees aren't green by the end of the day, you ought to seriously re-examine your life. --Calvin From jkeating at j2solutions.net Wed Jun 2 16:07:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 2 Jun 2004 09:07:44 -0700 Subject: Red Hat 9 Updates In-Reply-To: <20040602160752.GN11946@tirian.magd.ox.ac.uk> References: <40BDF73B.5020500@umd.edu> <200406020857.48454.jkeating@j2solutions.net> <20040602160752.GN11946@tirian.magd.ox.ac.uk> Message-ID: <200406020907.44315.jkeating@j2solutions.net> On Wednesday 02 June 2004 09:07, Dominic Hargreaves wrote: > Although I was aware you had pretty much decided on that I haven't > seen anything sent to fedora-legacy-announce. That list should > probably be told (sorry if you have already got this on your todo > list :) It's on my list to make a public announcement about 7.2/8.0. I'm still thinking about the best way to do 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 Ow.Mun.Heng at wdc.com Wed Jun 2 18:08:55 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Wed, 02 Jun 2004 11:08:55 -0700 Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <200405311419.19956.jkeating@j2solutions.net> References: <200405311419.19956.jkeating@j2solutions.net> Message-ID: <1086199734.10827.3.camel@Neuromancer.home.net> On Mon, 2004-05-31 at 14:19, Jesse Keating wrote: > ------------------------------------------ > > 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 Jesse, So, i take it that 8.0 updates are no longer to be made available? (eg: discontinued?) I saw that floating in the list, but no definate date. Can you elaborate? (or maybe this doesn't affect 8.0?) -- From Ow.Mun.Heng at wdc.com Wed Jun 2 18:10:37 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Wed, 02 Jun 2004 11:10:37 -0700 Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <1086199734.10827.3.camel@Neuromancer.home.net> References: <200405311419.19956.jkeating@j2solutions.net> <1086199734.10827.3.camel@Neuromancer.home.net> Message-ID: <1086199837.10827.6.camel@Neuromancer.home.net> On Wed, 2004-06-02 at 11:08, Ow Mun Heng wrote: > On Mon, 2004-05-31 at 14:19, Jesse Keating wrote: > > ------------------------------------------ > > > > 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 > > Jesse, > > So, i take it that 8.0 updates are no longer to be made available? (eg: > discontinued?) > > I saw that floating in the list, but no definate date. Can you > elaborate? > > (or maybe this doesn't affect 8.0?) Forget it. Just re-scanned the emails and saw your note about 7.0/8.0 support. Guess it's about time for me to upgrade my rh8.0 box to @least 9.0 (?) I've never done an upgrade before, I'm getting all jittery in the knees thinkning about it. -- From drees at greenhydrant.com Wed Jun 2 18:16:03 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 2 Jun 2004 11:16:03 -0700 (PDT) Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <1086199837.10827.6.camel@Neuromancer.home.net> References: <200405311419.19956.jkeating@j2solutions.net> <1086199734.10827.3.camel@Neuromancer.home.net> <1086199837.10827.6.camel@Neuromancer.home.net> Message-ID: <2063.208.48.139.163.1086200163.squirrel@208.48.139.163> Ow Mun Heng wrote: > > I've never done an upgrade before, I'm getting all jittery in the knees > thinkning about it. It's really quite easy to do, don't stress over it. ;-) -Dave From Ow.Mun.Heng at wdc.com Wed Jun 2 18:45:20 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Wed, 02 Jun 2004 11:45:20 -0700 Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <2063.208.48.139.163.1086200163.squirrel@208.48.139.163> References: <200405311419.19956.jkeating@j2solutions.net> <1086199734.10827.3.camel@Neuromancer.home.net> <1086199837.10827.6.camel@Neuromancer.home.net> <2063.208.48.139.163.1086200163.squirrel@208.48.139.163> Message-ID: <1086201920.10827.22.camel@Neuromancer.home.net> On Wed, 2004-06-02 at 11:16, David Rees wrote: > Ow Mun Heng wrote: > > > > I've never done an upgrade before, I'm getting all jittery in the knees > > thinkning about it. > > It's really quite easy to do, don't stress over it. ;-) I know it's simple to do.. It's the "probs" after that which I'm afraid of. (touch wood) This _is_ a dept Server and I don't think the boss will like it getting screwed. :-) From strange at nsk.no-ip.org Wed Jun 2 19:59:53 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Wed, 2 Jun 2004 20:59:53 +0100 Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <1086201920.10827.22.camel@Neuromancer.home.net> References: <200405311419.19956.jkeating@j2solutions.net> <1086199734.10827.3.camel@Neuromancer.home.net> <1086199837.10827.6.camel@Neuromancer.home.net> <2063.208.48.139.163.1086200163.squirrel@208.48.139.163> <1086201920.10827.22.camel@Neuromancer.home.net> Message-ID: <20040602195953.GB1074@nsk.no-ip.org> On Wed, Jun 02, 2004 at 11:45:20AM -0700, Ow Mun Heng wrote: > On Wed, 2004-06-02 at 11:16, David Rees wrote: > > Ow Mun Heng wrote: > > > > > > I've never done an upgrade before, I'm getting all jittery in the knees > > > thinkning about it. > > > > It's really quite easy to do, don't stress over it. ;-) > > I know it's simple to do.. > > It's the "probs" after that which I'm afraid of. (touch wood) > > This _is_ a dept Server and I don't think the boss will like it > getting screwed. As the 8.0 version isn't very different than 9, you could download the updated src.rpm for 9 and recompile it on your server. Regards, Luciano Rocha -- Consciousness: that annoying time between naps. From Ow.Mun.Heng at wdc.com Wed Jun 2 20:29:00 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Wed, 02 Jun 2004 13:29:00 -0700 Subject: Fedora Legacy Test Update Notification: rsync In-Reply-To: <20040602195953.GB1074@nsk.no-ip.org> References: <200405311419.19956.jkeating@j2solutions.net> <1086199734.10827.3.camel@Neuromancer.home.net> <1086199837.10827.6.camel@Neuromancer.home.net> <2063.208.48.139.163.1086200163.squirrel@208.48.139.163> <1086201920.10827.22.camel@Neuromancer.home.net> <20040602195953.GB1074@nsk.no-ip.org> Message-ID: <1086208140.10827.38.camel@Neuromancer.home.net> On Wed, 2004-06-02 at 12:59, Luciano Miguel Ferreira Rocha wrote: > On Wed, Jun 02, 2004 at 11:45:20AM -0700, Ow Mun Heng wrote: > > On Wed, 2004-06-02 at 11:16, David Rees wrote: > > > Ow Mun Heng wrote: > > > > > > > > I've never done an upgrade before, I'm getting all jittery in the knees > > > > thinkning about it. > > > > > > It's really quite easy to do, don't stress over it. ;-) > > > > I know it's simple to do.. > > > > It's the "probs" after that which I'm afraid of. (touch wood) > > > > This _is_ a dept Server and I don't think the boss will like it > > getting screwed. > > As the 8.0 version isn't very different than 9, you could download the > updated src.rpm for 9 and recompile it on your server. Or maybe I will just Download the 2.6.2 release and use that instead. Actually, the only reason I'm not compiling from source and wanting rpms is because of the file locations. RH packages things to specific locations which I have no idea where and I frankly will just opt for /usr/local/ as default. :-) Thanks. -- From michal at harddata.com Wed Jun 2 21:07:27 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 2 Jun 2004 15:07:27 -0600 Subject: remote attack in mod_ssl Message-ID: <20040602150727.A29750@mail.harddata.com> I just posted https://bugzilla.fedora.us/show_bug.cgi?id=1708 with a title like a subject of this message. There is also a patch there. But this is basically for RH7.3 (and 7.2). Would somebody with another distro please look at that and add relevant comments? Michal From mic at npgx.com.au Wed Jun 2 21:58:39 2004 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 3 Jun 2004 07:58:39 +1000 Subject: Red Hat 9 Updates In-Reply-To: <20040602160752.GN11946@tirian.magd.ox.ac.uk> References: <40BDF73B.5020500@umd.edu> <200406020857.48454.jkeating@j2solutions.net> <20040602160752.GN11946@tirian.magd.ox.ac.uk> Message-ID: <20040602215623.M64929@npgx.com.au> > > There have been a couple items pushed into updates-testing for RHL9, and > > there are some more coming up. I had a serious lack of time issue over > > the last couple months, and we were trying to work on more than we had > > the resources for. We've 'trimmed the fat' by dropping support for > > 7.2/8.0, and I have more free time now so that I can focus on pushing > > these updates. > > Although I was aware you had pretty much decided on that I haven't seen > anything sent to fedora-legacy-announce. That list should probably be > told (sorry if you have already got this on your todo list :) > > Cheers, > > Dominic. Although there was nothing official from what I saw, I kinda knew this was the case from fedoranews.org, since I'm attached to those lists and they mentioned it there with links to some of the posts made here. Michael. From fedoraleg_form at mm-vanecek.cc Wed Jun 2 23:08:32 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Wed, 2 Jun 2004 18:08:32 -0500 Subject: Red Hat 9 Updates In-Reply-To: <40BDF73B.5020500@umd.edu> References: <40BDF73B.5020500@umd.edu> Message-ID: <20040602230343.M20804@mm-vanecek.cc> On Wed, 02 Jun 2004 11:50:19 -0400, David Eisner wrote > I notice that there are no RH9 advisories listed yet: > > http://www.fedoralegacy.org/updates/RH9/ > > Is it safe to depend on Fedora Legacy to provide > security updates for a RH9 system? > > In all sincerity, this is not a complaint. I realize > Fedora Legacy is a volunteer effort with limited > resources, and there are no free lunches. I just > need to make an informed decision about whether I > should start upgrading my RH9 systems to another > OS (RHEL, FC, etc.). CVS & rsync RH 9 updates are available for testing: http://download.fedoralegacy.org/redhat/9/updates-testing/i386/ Have you set up yum yet to query the different chains versus what you have installed and list what is available specific to your install? That is an easy way to keep track of what is available. Another alternative is http://transition.progeny.com/. Actually, I am using both right now to see what eventually gels. I also monitor the redhat and fedora announce lists to see what is being released for those systems. However, I am impressed with the effort and dedication of the folks associated with the FL effort. From paul at pbenjamin.net Wed Jun 2 17:31:45 2004 From: paul at pbenjamin.net (paul at pbenjamin.net) Date: Wed, 2 Jun 2004 10:31:45 -0700 (PDT) Subject: problem updating RH9 Message-ID: <53724.198.105.45.18.1086197505.spork@webmail.pbenjamin.net> Hi. I followed the instructions at http://www.fedoralegacy.org/docs/yum-rh9.php but when I do yum update I get: ... [update: mkisofs 8:2.0-11.9.1.i386] [update: sendmail-cf 8.12.8-9.90.i386] [update: XFree86-font-utils 4.3.0-2.90.55.i386] Is this ok [y/N]: y Getting samba-client-2.2.7a-8.9.0.i386.rpm warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/updates/packages/samba-client-2.2.7a-8.9.0.i386.rpm Error: You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/samba-client-2.2.7a-8.9.0.i386.rpm Error: You may also check that you have the correct GPG keys installed rpm -qa gives: gpg-pubkey-731002fa-400b9109 gpg-pubkey-731002fa-400b9109 gpg-pubkey-731002fa-400b9109 gpg-pubkey-731002fa-400b9109 gpg-pubkey-731002fa-400b9109 How do I fix this? Thanks. Paul Benjamin From nospam2 at nihonbunka.com Thu Jun 3 00:27:41 2004 From: nospam2 at nihonbunka.com (Timothy TAKEMOTO) Date: Thu, 3 Jun 2004 09:27:41 +0900 Subject: Red Hat 9 Updates References: <40BDF73B.5020500@umd.edu> <200406020857.48454.jkeating@j2solutions.net> Message-ID: <0a6401c44901$9a358450$0b01a8c0@exus> Thank you all for the recent postings, some of which I think I was able to understand a little. I am a linux nincompoop. I think I understand that the academic packs for commercial RH models are not too expensive. $50 is not a lot to pay for a server. But I wonder if it will be in fact $50 a year? I think I understand that the time between the disclosure of a security issue and the time that a kind volunteer fixes it is not fast. These CAN nos are security issues, and there are still no updates for RH9. I think I understand that at present there are issues with CVS (concurrent or current versioning systems?) and perhaps other things but as yet no one can break into a bog standard RH9 web server (assuming that there are no problems with the ftp/httpd software). I wonder how often users of FBSD are updating their servers. Tim From jkeating at j2solutions.net Fri Jun 4 06:28:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 3 Jun 2004 23:28:58 -0700 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities Message-ID: <200406032328.58546.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cvs resolves security vulnerability Advisory ID: FLSA:1620 Issue date: 2004-06-02 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1620 CVE Names: CAN-2004-0180 CAN-2004-0396 CAN-2004-0405 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated cvs packages that fix remote denial of service vulnerabilities are now available. 2. Relevent releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Sebastian Krahmer discovered a flaw in CVS clients where rcs diff files can create files with absolute pathnames An attacker could create a fake malicious CVS server that would cause arbitrary files to be created or overwritten when a victim connects to it. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0180 to this issue. (Note: Red Hat Linux 9 was already patched for this issue) Derek Price discovered a vulnerability whereby a CVS pserver could be abused by a malicious client to view the contents of certain files outside of the CVS root directory using relative pathnames containing "../". The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0405 to this issue. (Note: Red Hat Linux 9 was already patched for this issue) Stefan Esser discovered a flaw in cvs where malformed "Entry" lines could cause a heap overflow. An attacker who has access to a CVS server could use this flaw to execute arbitrary code under the UID which the CVS server is executing. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0396 to this issue. Users of CVS are advised to upgrade to these erratum packages, which contain a patch correcting this issue. Fedora Legacy would like to thank David M. Kaplan for bringing these issues 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 - 1620 - Security problems found with CVS that need to be fixed. 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cvs-1.11.1p1-14.legacy.3.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cvs-1.11.2-23.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cvs-1.11.2-23.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 58069558fc24abfa50f2ac94327c8d06f234bbd9 7.3/updates/SRPMS/cvs-1.11.1p1-14.legacy.3.src.rpm 523e9f69536d69ae5a8984f4327e35b32c38afdc 7.3/updates/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm 84027d8b84f72c675aeb15816034e86450534b62 9/updates/SRPMS/cvs-1.11.2-23.legacy.src.rpm e79bb82a8dca7a50cf51a72a85879bdbfa0b338d 9/updates/i386/cvs-1.11.2-23.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-0180 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0405 http://rhn.redhat.com/errata/RHSA-2004-153.html http://rhn.redhat.com/errata/RHSA-2004-190.html http://rhn.redhat.com/errata/RHSA-2004-154.html https://bugzilla.fedora.us/show_bug.cgi?id=1620 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAwBaq4v2HLvE71NURAvsNAJ9SSg36GQyr20SYyCtS4wbOKr3wygCgsZJ+ h2yNelOC3+SW9wW+n38K9Lw= =MY5k -----END PGP SIGNATURE----- From dom at earth.li Fri Jun 4 13:22:16 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 4 Jun 2004 14:22:16 +0100 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <200406032328.58546.jkeating@j2solutions.net> References: <200406032328.58546.jkeating@j2solutions.net> Message-ID: <20040604132216.GU11946@tirian.magd.ox.ac.uk> On Thu, Jun 03, 2004 at 11:28:58PM -0700, Jesse Keating wrote: > ----------------------------------------------------------------------- > Fedora Legacy Update Advisory > > Synopsis: Updated cvs resolves security vulnerability > Advisory ID: FLSA:1620 > Issue date: 2004-06-02 > Product: Red Hat Linux > Keywords: Security > Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1620 > CVE Names: CAN-2004-0180 CAN-2004-0396 CAN-2004-0405 > ----------------------------------------------------------------------- Hmm. Seems I missed the updates-testing for these packages, but I get the following errors whilst installing onto my redhat 7.3 boxes: Preparing... ################################################## cvs ################################################## 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' Additionally the packages seem to be much smaller than the original redhat updates and previous legacy updates: cvs-1.11.1p1-8.7.i386.rpm 17-Jan-2003 01:19 1.0M cvs-1.11.1p1-9.7.legacy.i386.rpm 24-Jan-2004 03:55 1.0M cvs-1.11.1p1-14.legacy.3.i386.rpm 04-Jun-2004 02:12 898K Anyone else seen this? Cheers, Dominic. From paul at frields.com Fri Jun 4 14:41:09 2004 From: paul at frields.com (Paul W. Frields) Date: Fri, 04 Jun 2004 10:41:09 -0400 Subject: up2date location change Message-ID: <1086360068.3653.8.camel@london.east.gov> To make everything easier to organize (and find), I've put my up2date update up at http://rpm.frields.org -- you can find my GPG key there, along with both binary and source RPMs for up2date and supporting packages. There is a note on the site to remind you to fix your /etc/sysconfig/rhn/sources file to point to your local mirror. An example is given for those who are not familiar with how this works, using yum repositories. I've now used this new up2date successfully under Red Hat Linux 9 to both add software and grab updates, in the same fashion as Fedora users do. Sorry to spam the list again about it, but I was forced to reorganize and wanted to make sure interested parties could find this. The packages themselves have not changed from the previous notice. -- Paul W. Frields, RHCE From barryn at pobox.com Fri Jun 4 14:39:19 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 4 Jun 2004 07:39:19 -0700 Subject: Red Hat 9 Updates In-Reply-To: <0a6401c44901$9a358450$0b01a8c0@exus> References: <40BDF73B.5020500@umd.edu> <200406020857.48454.jkeating@j2solutions.net> <0a6401c44901$9a358450$0b01a8c0@exus> Message-ID: <20040604143919.GD2350@ip68-4-98-123.oc.oc.cox.net> On Thu, Jun 03, 2004 at 09:27:41AM +0900, Timothy TAKEMOTO wrote: > I think I understand that the academic packs for commercial RH > models are not too expensive. $50 is not a lot to pay for a server. > But I wonder if it will be in fact $50 a year? Yes, in fact it is $50 per year. -Barry K. Nathan From villegas at math.gatech.edu Fri Jun 4 15:08:57 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 4 Jun 2004 11:08:57 -0400 Subject: problem updating RH9 In-Reply-To: <53724.198.105.45.18.1086197505.spork@webmail.pbenjamin.net> References: <53724.198.105.45.18.1086197505.spork@webmail.pbenjamin.net> Message-ID: <20040604150857.GN5583@math30192.math.gatech.edu> On Wed, Jun 02, 2004 at 10:31:45AM -0700, paul at pbenjamin.net wrote: > warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e That key is redhat's key, you need to import it first, it is on the CD and on the net in the top directory, I can also post it somewhere if you can't find it. To import it do "rpm --import KEY" Carlos From paul at frields.com Fri Jun 4 15:19:24 2004 From: paul at frields.com (Paul W. Frields) Date: Fri, 04 Jun 2004 11:19:24 -0400 Subject: problem updating RH9 In-Reply-To: <20040604150857.GN5583@math30192.math.gatech.edu> References: <53724.198.105.45.18.1086197505.spork@webmail.pbenjamin.net> <20040604150857.GN5583@math30192.math.gatech.edu> Message-ID: <1086362363.3653.10.camel@london.east.gov> On Fri, 2004-06-04 at 11:08, Carlos Villegas wrote: > On Wed, Jun 02, 2004 at 10:31:45AM -0700, paul at pbenjamin.net wrote: > > warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e > > That key is redhat's key, you need to import it first, it is on > the CD and on the net in the top directory, I can also post it > somewhere if you can't find it. To import it do "rpm --import KEY" Or: rpm --import /usr/share/rhn/RPM-GPG-KEY where it's found after installation. -- Paul W. Frields, RHCE From jkeating at j2solutions.net Fri Jun 4 15:19:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 4 Jun 2004 08:19:47 -0700 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <20040604132216.GU11946@tirian.magd.ox.ac.uk> References: <200406032328.58546.jkeating@j2solutions.net> <20040604132216.GU11946@tirian.magd.ox.ac.uk> Message-ID: <200406040819.47344.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 04 June 2004 06:22, Dominic Hargreaves wrote: > 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' Odd, I couldn't duplicate on my 7.3 boxes, but I was using yum to update. What happens if you do "info cvsclient" ? I get the cvs client info page, do you? - -- 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) iD8DBQFAwJMT4v2HLvE71NURArhoAJ98MF1teUgjENYtAdZdoPH8quqQIQCfc5QE yqa00njXl2Qwh+RPyV1PE6E= =uZCQ -----END PGP SIGNATURE----- From dom at earth.li Fri Jun 4 16:00:25 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 4 Jun 2004 17:00:25 +0100 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <200406040819.47344.jkeating@j2solutions.net> References: <200406032328.58546.jkeating@j2solutions.net> <20040604132216.GU11946@tirian.magd.ox.ac.uk> <200406040819.47344.jkeating@j2solutions.net> Message-ID: <20040604160025.GY11946@tirian.magd.ox.ac.uk> On Fri, Jun 04, 2004 at 08:19:47AM -0700, Jesse Keating wrote: > Odd, I couldn't duplicate on my 7.3 boxes, but I was using yum to update. > What happens if you do "info cvsclient" ? I get the cvs client info page, > do you? Nope. The info pages seem to be missing/corrupted. Comparing your binary RPM with one I've just rebuilt: [dom at isay misc]$ diff -u <(rpm -qlp /usr/local/RPMS/legacy/updates/i386/cvs-1.11 .1p1-14.legacy.3.i386.rpm) <(rpm -qlp cvs-1.11.1p1-14.legacy.3.i386.rpm) --- /dev/fd/63 Fri Jun 4 16:56:10 2004 +++ /dev/fd/62 Fri Jun 4 16:56:10 2004 @@ -31,7 +31,19 @@ /usr/share/doc/cvs-1.11.1p1/cvs-paper.ps /usr/share/doc/cvs-1.11.1p1/cvs.ps /usr/share/doc/cvs-1.11.1p1/cvsclient.ps +/usr/share/info/cvs.info-1.gz +/usr/share/info/cvs.info-2.gz +/usr/share/info/cvs.info-3.gz +/usr/share/info/cvs.info-4.gz +/usr/share/info/cvs.info-5.gz +/usr/share/info/cvs.info-6.gz +/usr/share/info/cvs.info-7.gz +/usr/share/info/cvs.info-8.gz +/usr/share/info/cvs.info-9.gz /usr/share/info/cvs.info.gz +/usr/share/info/cvsclient.info-1.gz +/usr/share/info/cvsclient.info-2.gz +/usr/share/info/cvsclient.info-3.gz /usr/share/info/cvsclient.info.gz /usr/share/man/man1/cvs.1.gz /usr/share/man/man5/cvs.5.gz (and likewise comparing the current a previous office binary RPMs: [dom at isay misc]$ diff -u <(rpm -qlp /usr/local/RPMS/tmp/cvs-1.11.1p1-9.7.legacy.i386.rpm) <(rpm -qlp /usr/local/RPMS/legacy/updates/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm) --- /dev/fd/63 Fri Jun 4 16:57:57 2004 +++ /dev/fd/62 Fri Jun 4 16:57:57 2004 @@ -31,19 +31,7 @@ /usr/share/doc/cvs-1.11.1p1/cvs-paper.ps /usr/share/doc/cvs-1.11.1p1/cvs.ps /usr/share/doc/cvs-1.11.1p1/cvsclient.ps -/usr/share/info/cvs.info-1.gz -/usr/share/info/cvs.info-2.gz -/usr/share/info/cvs.info-3.gz -/usr/share/info/cvs.info-4.gz -/usr/share/info/cvs.info-5.gz -/usr/share/info/cvs.info-6.gz -/usr/share/info/cvs.info-7.gz -/usr/share/info/cvs.info-8.gz -/usr/share/info/cvs.info-9.gz /usr/share/info/cvs.info.gz -/usr/share/info/cvsclient.info-1.gz -/usr/share/info/cvsclient.info-2.gz -/usr/share/info/cvsclient.info-3.gz /usr/share/info/cvsclient.info.gz /usr/share/man/man1/cvs.1.gz /usr/share/man/man5/cvs.5.gz http://www-astro.physics.ox.ac.uk/~dom/legacy/misc/cvs-1.11.1p1-14.legacy.3.i386.rpm is my RPM in case anyone wants to poke it). [dom at isay misc]$ sha1sum /usr/local/RPMS/legacy/updates/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm 523e9f69536d69ae5a8984f4327e35b32c38afdc /usr/local/RPMS/legacy/updates/i386/cvs-1.11.1p1-14.legacy.3.i386.rpm which matches your advisory. So it looks like something went wrong during rebuilding? Dominic. From jkeating at j2solutions.net Fri Jun 4 15:58:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 4 Jun 2004 08:58:22 -0700 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <20040604160025.GY11946@tirian.magd.ox.ac.uk> References: <200406032328.58546.jkeating@j2solutions.net> <200406040819.47344.jkeating@j2solutions.net> <20040604160025.GY11946@tirian.magd.ox.ac.uk> Message-ID: <200406040858.25436.jkeating@j2solutions.net> On Friday 04 June 2004 09:00, Dominic Hargreaves wrote: > which matches your advisory. > > So it looks like something went wrong during rebuilding? Odd odd odd odd. I looked through the build log and there were no errors of any kind.... Looking again. -- 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 Fri Jun 4 16:03:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 4 Jun 2004 09:03:30 -0700 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <200406040858.25436.jkeating@j2solutions.net> References: <200406032328.58546.jkeating@j2solutions.net> <20040604160025.GY11946@tirian.magd.ox.ac.uk> <200406040858.25436.jkeating@j2solutions.net> Message-ID: <200406040903.30729.jkeating@j2solutions.net> On Friday 04 June 2004 08:58, Jesse Keating wrote: > Odd odd odd odd. I looked through the build log and there were no > errors of any kind.... Looking again. d'oh! I see it now. texinfo is a buildreq, but not listed in the spec. Running again with texinfo as a buildreq. -- 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 Fri Jun 4 16:06:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 4 Jun 2004 09:06:52 -0700 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <200406040903.30729.jkeating@j2solutions.net> References: <200406032328.58546.jkeating@j2solutions.net> <200406040858.25436.jkeating@j2solutions.net> <200406040903.30729.jkeating@j2solutions.net> Message-ID: <200406040906.52117.jkeating@j2solutions.net> On Friday 04 June 2004 09:03, Jesse Keating wrote: > d'oh! I see it now. texinfo is a buildreq, but not listed in the > spec. Running again with texinfo as a buildreq. Yep, that was 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 villegas at math.gatech.edu Fri Jun 4 16:20:21 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 4 Jun 2004 12:20:21 -0400 Subject: problem updating RH9 In-Reply-To: <1086362363.3653.10.camel@london.east.gov> References: <53724.198.105.45.18.1086197505.spork@webmail.pbenjamin.net> <20040604150857.GN5583@math30192.math.gatech.edu> <1086362363.3653.10.camel@london.east.gov> Message-ID: <20040604162021.GR5583@math30192.math.gatech.edu> On Fri, Jun 04, 2004 at 11:19:24AM -0400, Paul W. Frields wrote: > Or: rpm --import /usr/share/rhn/RPM-GPG-KEY That's right, I forgot about that one :) Carlos From villegas at math.gatech.edu Fri Jun 4 16:25:58 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 4 Jun 2004 12:25:58 -0400 Subject: [FLSA-2004:1620] Updated cvs resolves security vulnerabilities In-Reply-To: <200406040906.52117.jkeating@j2solutions.net> References: <200406032328.58546.jkeating@j2solutions.net> <200406040858.25436.jkeating@j2solutions.net> <200406040903.30729.jkeating@j2solutions.net> <200406040906.52117.jkeating@j2solutions.net> Message-ID: <20040604162558.GS5583@math30192.math.gatech.edu> On Fri, Jun 04, 2004 at 09:06:52AM -0700, Jesse Keating wrote: Content-Description: signed data > On Friday 04 June 2004 09:03, Jesse Keating wrote: > > d'oh! I see it now. texinfo is a buildreq, but not listed in the > > spec. Running again with texinfo as a buildreq. In case you wonder, the one for RH 9 is good. So only a re-release is only needed for RH7.3. Carlos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bluebell at bribieisland.net Fri Jun 4 23:33:48 2004 From: bluebell at bribieisland.net (glm) Date: Sat, 05 Jun 2004 09:33:48 +1000 Subject: up2date location change In-Reply-To: <1086360068.3653.8.camel@london.east.gov> References: <1086360068.3653.8.camel@london.east.gov> Message-ID: <40C106DC.6020404@bribieisland.net> Thank You Paul, Regards, Glynn. Paul W. Frields wrote: >To make everything easier to organize (and find), I've put my up2date >update up at http://rpm.frields.org -- you can find my GPG key there, >along with both binary and source RPMs for up2date and supporting >packages. There is a note on the site to remind you to fix your >/etc/sysconfig/rhn/sources file to point to your local mirror. An >example is given for those who are not familiar with how this works, >using yum repositories. > >I've now used this new up2date successfully under Red Hat Linux 9 to >both add software and grab updates, in the same fashion as Fedora users >do. Sorry to spam the list again about it, but I was forced to >reorganize and wanted to make sure interested parties could find this. >The packages themselves have not changed from the previous notice. > > > From PEDROCJ at terra.es Sat Jun 5 08:44:20 2004 From: PEDROCJ at terra.es (Pedro Canadilla) Date: 05 Jun 2004 10:44:20 +0200 Subject: 8.0 packages to QA In-Reply-To: <1085615411.22938.6.camel@mdlinux> References: <1085615411.22938.6.camel@mdlinux> Message-ID: <1086425063.840.8.camel@localhost.localdomain> Hi Marc, Sorry for the delay. I have Psyche installed too. Just bacause it's the limit for my hardware, I'm downloading now your packages for QA. Thanks a lot for your best efford to help us to have a useful enviroment and to save money and investment in new hardware. If you need help for compiling, testing, documenting or something else that I can contribute, here I am. Best Regards, P.C. El jue, 27-05-2004 a las 01:50, Marc Deslauriers escribi?: > 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. > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From J.S.Peatfield at damtp.cam.ac.uk Sun Jun 6 12:01:22 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Sun, 06 Jun 2004 13:01:22 +0100 Subject: 8.0 packages to QA Message-ID: I did try to volunteer to build/test packages for RH8 last year but no-one replied to my request for further information on the procedures for arranging for packages to be uploaded/tested. Occasionally since then I've looked at the fl download site and again seen the lack of packages (even for RH73 or 9 -- which I don't use so don't really care about). I ended up building all the relevant ones myself (assuming that no-one else was interested). Before the RH9 EOL most of those packages (or a simple rebuild from the SRPM) were enough, since then I've picked SRPMs from RHEL-AS3, fedora-core and occasionally just applied the relevant patch to the last RH8 SRPM. Since I'm doing this just for the ~190 RH8 machines I look after I'm only building updates (mostly the security ones) for packages we actually install (so some are bound to be missing). Since the RH8 EOL, I have used updates for the followng: # From RH9 updates needing no rebuild tcpdump-3.7.2-7.9.1 startup-notification-0.5-1 gaim-0.75-0.9.0 netpbm-9.24-10.90.1 gdk-pixbuf-0.22.0-6.1.0 sysstat-4.0.7-4.rhl9.1 mozilla-1.4.2-0.9.0 cvs-1.11.2-17 lha-1.14i-9.1 mc-4.6.0-14.9 libpng-1.2.2-20 libpng10-1.0.13-11 # from RH9 rebuild SRPM (with minor changes) mutt-1.4.1-3.3.D80 XFree86-4.3.0-1.80.55.D fontconfig-2.1-9 freetype-2.1.3-6 ttmkfdir-3.0.9-1 kernel-2.4.20-30.8.JSP libxml2-2.5.4-3.rh8 kernel-2.4.20-31.8.JSP xchat-1.8.11-8 utempter-0.5.5-2.RHL8.0.JSP # from RHEL-AS3 SRPM cvs-1.11.2-22JSP rsync-2.5.7-4.80.JSP1 # Applied patch to last RH8 update kdelibs-3.0.5a-5.80.1JSP openssl-0.9.6b-36.8.JSP kdelibs-3.0.5a-6.80.1JSP # rebuild from fedora-core version (none are security related) octave-2.1.57-1.JSP aspell-0.50.5-1.JSP gnome-spell-0.4.1-5.JSP I didn't bother with openoffice, apache, ftpd, flim etc since we don't use the RH packages version (for complex reasons), so I just arranged to patch the copy we installed ourselves. Next month we might actually have time to start thinking of what we should switch our desktop machines to next... -- Jon From J.S.Peatfield at damtp.cam.ac.uk Sun Jun 6 14:34:21 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Sun, 06 Jun 2004 15:34:21 +0100 Subject: RH 9 EOL Updates ISOs Message-ID: > >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? > > 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). I make use of a handy repostory maintenance script (rh_buildtree written by Peter Benie who works in a different department here), which given a set of directories full of rpms constructs/maintains a directory which contains the latest version of all those packages which pass a signature-check (as hard-links to whichever source they were from -- original shipped version, updates, local-packages etc). [ We use it to re-build install trees overnight so that a fresh install always goes straight to having the latest versions available from the tree (which saves having insecure versions until patched and also is much quicker). We also use a script (rpmalert) which checks what versions are out-of-date on a machine and another (rpm-update) which applies the updates we have flagged as ok, but I suppose you may have yum/up2date for that function anyway. ] I'm still using this older repository maintenance script for my redhat trees (which takes ~15 minutes to run and (I think) results in an extra copy of some of the packages on disk). As part of my experiments with Suse9 I tried Peter's new repository maintenance script (rpmstream) which usually runs in seconds (since it keeps more cache info around). If you just want the latest versions of update packages that could probably be done easily enough. > Is this something useful for FedoraLegacy to include in its distribution > tree? Well I'm not sure that iso's would be anything other than a space waste -- anyone could make their own anyway. A list of rpms which are current or a script to generate such a list would be much smaller and possibly of more use to more people. -- Jon From PEDROCJ at terra.es Sun Jun 6 14:39:52 2004 From: PEDROCJ at terra.es (Pedro Canadilla) Date: 06 Jun 2004 16:39:52 +0200 Subject: 8.0 packages to QA In-Reply-To: References: Message-ID: <1086532867.915.17.camel@localhost.localdomain> Hi Jon, I'm new to this issues about compiling. Where are the patch you use for the rebuild? Is it necessary to edit the spec from the rpm file to include the pacht? As I can see in the bugzilla errors getting the packages for QA, the patch can be from the different sources: debian, redhat, etc. so I fear myself thinking that you have to be a very good developer to do that kind of things and I'm not a developer at all. I only know to rebuild a package from sources. But I'm happy because there a lot of people who share his effors to us. Thanks a lot for your help. I'm testing in QA all the psyche packages that are released, and I have a question... Where I can write that I'm testing that packages? For example, xchat and OpenOffice from Marc, kernel 2.4.20-32-7, libxml2, libxml2-python, lha, etc? Best Regards, P.C. El dom, 06-06-2004 a las 14:01, Jon Peatfield escribi?: > I did try to volunteer to build/test packages for RH8 last year but > no-one replied to my request for further information on the procedures > for arranging for packages to be uploaded/tested. > > Occasionally since then I've looked at the fl download site and again > seen the lack of packages (even for RH73 or 9 -- which I don't use so > don't really care about). > > I ended up building all the relevant ones myself (assuming that no-one > else was interested). Before the RH9 EOL most of those packages (or a > simple rebuild from the SRPM) were enough, since then I've picked > SRPMs from RHEL-AS3, fedora-core and occasionally just applied the > relevant patch to the last RH8 SRPM. > > Since I'm doing this just for the ~190 RH8 machines I look after I'm > only building updates (mostly the security ones) for packages we > actually install (so some are bound to be missing). > > Since the RH8 EOL, I have used updates for the followng: > > # From RH9 updates needing no rebuild > tcpdump-3.7.2-7.9.1 > startup-notification-0.5-1 > gaim-0.75-0.9.0 > netpbm-9.24-10.90.1 > gdk-pixbuf-0.22.0-6.1.0 > sysstat-4.0.7-4.rhl9.1 > mozilla-1.4.2-0.9.0 > cvs-1.11.2-17 > lha-1.14i-9.1 > mc-4.6.0-14.9 > libpng-1.2.2-20 > libpng10-1.0.13-11 > > # from RH9 rebuild SRPM (with minor changes) > mutt-1.4.1-3.3.D80 > XFree86-4.3.0-1.80.55.D > fontconfig-2.1-9 > freetype-2.1.3-6 > ttmkfdir-3.0.9-1 > kernel-2.4.20-30.8.JSP > libxml2-2.5.4-3.rh8 > kernel-2.4.20-31.8.JSP > xchat-1.8.11-8 > utempter-0.5.5-2.RHL8.0.JSP > > # from RHEL-AS3 SRPM > cvs-1.11.2-22JSP > rsync-2.5.7-4.80.JSP1 > > # Applied patch to last RH8 update > kdelibs-3.0.5a-5.80.1JSP > openssl-0.9.6b-36.8.JSP > kdelibs-3.0.5a-6.80.1JSP > > # rebuild from fedora-core version (none are security related) > octave-2.1.57-1.JSP > aspell-0.50.5-1.JSP > gnome-spell-0.4.1-5.JSP > > I didn't bother with openoffice, apache, ftpd, flim etc since we don't > use the RH packages version (for complex reasons), so I just arranged > to patch the copy we installed ourselves. > > Next month we might actually have time to start thinking of what we > should switch our desktop machines to next... > > -- Jon > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From marcdeslauriers at videotron.ca Sun Jun 6 14:49:55 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 06 Jun 2004 10:49:55 -0400 Subject: 8.0 packages to QA In-Reply-To: <1086532867.915.17.camel@localhost.localdomain> References: <1086532867.915.17.camel@localhost.localdomain> Message-ID: <1086533395.28546.2.camel@mdlinux> On Sun, 2004-06-06 at 10:39, Pedro Canadilla wrote: > I'm testing in QA all the psyche packages that are released, and I have > a question... Where I can write that I'm testing that packages? For > example, xchat and OpenOffice from Marc, kernel 2.4.20-32-7, libxml2, > libxml2-python, lha, etc? I wouldn't spend time testing the rh8 packages unless you need them for yourself. AFAIK, rh72 and rh8 support has been dropped from Fedora Legacy because of lack of interest. There hasn't been an official announcement, but it should be coming soon. Marc. From hunter at userfriendly.net Sun Jun 6 14:39:00 2004 From: hunter at userfriendly.net (Michael Weiner) Date: Sun, 06 Jun 2004 10:39:00 -0400 Subject: RH 9 EOL Updates ISOs In-Reply-To: References: Message-ID: <1086532740.20154.2.camel@nomad> On Sun, 2004-06-06 at 15:34 +0100, Jon Peatfield wrote: > I make use of a handy repostory maintenance script (rh_buildtree > written by Peter Benie who works in a different department here), > which given a set of directories full of rpms constructs/maintains a > directory which contains the latest version of all those packages > which pass a signature-check (as hard-links to whichever source they > were from -- original shipped version, updates, local-packages etc). > > [ We use it to re-build install trees overnight so that a fresh > install always goes straight to having the latest versions available > from the tree (which saves having insecure versions until patched and > also is much quicker). > > We also use a script (rpmalert) which checks what versions are > out-of-date on a machine and another (rpm-update) which applies the > updates we have flagged as ok, but I suppose you may have yum/up2date > for that function anyway. ] > > I'm still using this older repository maintenance script for my redhat > trees (which takes ~15 minutes to run and (I think) results in an > extra copy of some of the packages on disk). > > As part of my experiments with Suse9 I tried Peter's new repository > maintenance script (rpmstream) which usually runs in seconds (since it > keeps more cache info around). > > If you just want the latest versions of update packages that could > probably be done easily enough. > and are ANY of these scripts available publically, or anything CLOSE? Thanks in advance. Michael Weiner -------------- 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 PEDROCJ at terra.es Sun Jun 6 16:11:04 2004 From: PEDROCJ at terra.es (Pedro Canadilla) Date: 06 Jun 2004 18:11:04 +0200 Subject: 8.0 packages to QA In-Reply-To: <1086533395.28546.2.camel@mdlinux> References: <1086532867.915.17.camel@localhost.localdomain> <1086533395.28546.2.camel@mdlinux> Message-ID: <1086538267.698.31.camel@localhost.localdomain> El dom, 06-06-2004 a las 16:49, Marc Deslauriers escribi?: > I wouldn't spend time testing the rh8 packages unless you need them for > yourself. AFAIK, rh72 and rh8 support has been dropped from Fedora > Legacy because of lack of interest. It's a pity. I remember a paragraph from the FAQ... "For supported Red Hat Linux releases, we will continue to issue back-port security or critical fixes for as long as there is community interest, but for at least another 1.5 years from their official Red Hat End of Life." Another one: "We are currently supporting Red Hat Linux 7.2, 7.3, 8.0 and 9 as these have reached their End-of-Life (EOL). We will provide support for these Red Hat releases for as long as there is community interest." There are people that have interest in rh8. Perhaps not so many as others releases. Maybe it should say: <>. I understand the lack of resources of fedora legacy as I understand the lack of resources from the hardware to upgrade to 9 or to FC1 as some people has told here. I understand that 1.5 years is time enough to get investment to replace the obsoleted hardware, but 0.5 years is not. It's not a complaint, only deception. Regards, P.C. From joey at clean.q7.com Sun Jun 6 16:21:53 2004 From: joey at clean.q7.com (Joe Pruett) Date: Sun, 6 Jun 2004 09:21:53 -0700 (PDT) Subject: 8.0 packages to QA In-Reply-To: <1086538267.698.31.camel@localhost.localdomain> Message-ID: > It's a pity. I remember a paragraph from the FAQ... > > "For supported Red Hat Linux releases, we will continue to issue > back-port security or critical fixes for as long as there is community > interest, but for at least another 1.5 years from their official Red Hat > End of Life." i think that you need to read that as "community interest in helping build and test patches". that is the part that has been missing and talked about on this list quite a bit lately. i know for myself that i have interest in obtaining patches, but not the time available to help. i'm going to put most of my time into upgrading boxes to rh9 to avoid the issue for now. From J.S.Peatfield at damtp.cam.ac.uk Sun Jun 6 16:42:41 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Sun, 06 Jun 2004 17:42:41 +0100 Subject: 8.0 packages to QA Message-ID: > I'm new to this issues about compiling. Where are the patch you use for > the rebuild? Assuming you want to know where they came from; In my case I got some from debian, others from RedHat, fedora-core etc. I've even looked as a few Suse advisories. My list of places to regularly check for new security issues includes: http://www.debian.org/security/ # usually quite fast https://rhn.redhat.com/errata/rhel3as-errata.html # often quiet slow https://rhn.redhat.com/errata/rh9-errata.html # was fast but no longer http://www.fedoralegacy.org/updates/RH9/ # none so far http://download.fedora.redhat.com/pub/fedora/linux/core/updates/ # painful http://www.suse.com/de/security/announcements/ Suse arn't very fast at making releases (their QA may take a long time), but section 2 of every advisory lists the outstanding security problems they are working on. e.g. http://www.suse.com/de/security/2004_14_kdelibs.html lists rsync, flim and mod_ssl. These usually contain enough info to find the original report and find a suitable upstream-patch or > Is it necessary to edit the spec from the rpm file to > include the pacht? Usually yes, if the patch replaces one of the same name you *could* avoid editing the specfile, but usually you at least want to change the release version! The specfile contains a list of patches to apply to the source, if the same (exact) patch applies as can be takes from another source (Debian or RHEL fro example), then you just need to add the PatchN lines to the specfile, change the package release and rebuild. If the package is the same version (or "close enough") as in RH9 or RHEA-AS3 (etc) then rebuilding from the update SRPM will usually give you a package which works on RH73, RH8 or 9. To avoid later confusion it is probably best practice to add something to the "release" version to indicate that it is a rebuild for a different version by you (as fedora-legacy does). I've been a bit varied in my numbering scheme(s), but currently try to change anything that looks like a redhat linux version-number to "80" or "RHL80" and add a JSP in there to show they are my rebuilds. For most such rebuilds (from the SRPM) just the release-version change is all that is needed, but a few need other tweaks. e.g. the NPTL change for kernel-... (NPTL problems was why we didn't switch to RH9 last year), and XFree86 was a bit of a pain (since it requires getting the environment right to build the final rpms). The biggest pain is when the BuildRequires lines arn't complete; e.g. you meet them only to find that the rpmbuild fails 'cos a needed dependency is missing. I live in fear of it just producing a "slightly broken" version which I won't spot 'til I've deployed it. I normally test on 3-4 machines for 2-3 days before pushing to the rest, but that isn't proper QA since the packages may nto get stress tested... > As I can see in the bugzilla errors getting the packages for QA, the > patch can be from the different sources: debian, redhat, etc. so I fear > myself thinking that you have to be a very good developer to do that > kind of things and I'm not a developer at all. I only know to rebuild a > package from sources. But I'm happy because there a lot of people who > share his effors to us. Thanks a lot for your help. I'd be happy to make all the packages that I have for download (I have to build them anyway), but they are *only* for RH80 and apparently few people (on this list at least) use that. I've still got no idea how to offer them up for fdl to look at/test though. Of course you might not trust me or my packages (why should anyone). > I'm testing in QA all the psyche packages that are released, and I have > a question... Where I can write that I'm testing that packages? For > example, xchat and OpenOffice from Marc, kernel 2.4.20-32-7, libxml2, > libxml2-python, lha, etc? If I'd designed the QA system you would report that via the bug-tracking system (once to say you started and later if there are problems or if you are happy). If there isn't a track kept of testing use then unless you "know" all the testers you can't tell if they started (downloaded packages etc), but never actually did anything. Not reporting problems doesn't mean that there arn't any... > > Best Regards, > P.C. I finally got a reply to a message on the list! From skvidal at phy.duke.edu Sun Jun 6 19:16:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 06 Jun 2004 15:16:05 -0400 Subject: 8.0 packages to QA In-Reply-To: <1086538267.698.31.camel@localhost.localdomain> References: <1086532867.915.17.camel@localhost.localdomain> <1086533395.28546.2.camel@mdlinux> <1086538267.698.31.camel@localhost.localdomain> Message-ID: <1086549365.2612.33.camel@binkley> > It's not a complaint, only deception. > deception? You think there is something malicious in this? It's not malicious it's time. If you're hellbent for leather for 7.2 and 8.0 patches you're WELCOME TO PROVIDE THEM. No one here will stop you, but you damn well better keep up with the 7.3 and 9 patches, b/c things being held back by lesser used platforms is not interesting or positive. -sv From fedoraleg_form at mm-vanecek.cc Sun Jun 6 23:50:25 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Sun, 6 Jun 2004 18:50:25 -0500 Subject: RH 9 EOL Updates ISOs In-Reply-To: References: Message-ID: <20040606235025.M32227@mm-vanecek.cc> On Sun, 06 Jun 2004 15:34:21 +0100, Jon Peatfield 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? > > > > 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). > > I make use of a handy repostory maintenance script (rh_buildtree > written by Peter Benie who works in a different department here), > which given a set of directories full of rpms constructs/maintains a > directory which contains the latest version of all those packages > which pass a signature-check (as hard-links to whichever source they > were from -- original shipped version, updates, local-packages etc). Interesting. I finally just downloaded all the updates and put them on a CD. I did have to do some editing to get rid of the old duplicate RPMS (moved them to a folder by themselves). I also tried to create a boot CD containing a merge between the original files and the update files. I went through and tried manually deleting the duplicate replaced RPMS. Somehow the result was working out larger than the original CD. Also, I realized that I would also need to edit the TRANS file with the RPM information for the ones replaced or added. The editing soon lost its cost/benefit return and I just decided to do it from updates. It sounds like rh_buildtree does exactly that. > [ We use it to re-build install trees overnight so that a fresh > install always goes straight to having the latest versions available > from the tree (which saves having insecure versions until patched and > also is much quicker). Ooooh, that is exactly what I was trying to do. Now if one could create bootable install CDs, it would be perfect. Then when one installed a fresh system, it would be from updated RPMs. Would it be possible to get a copy of the scripts? > We also use a script (rpmalert) which checks what versions are > out-of-date on a machine and another (rpm-update) which applies the > updates we have flagged as ok, but I suppose you may have yum/up2date > for that function anyway. Yea, once the fresh install is done using the RH 9 CD made updated with updates, then one can just use yum. > I'm still using this older repository maintenance script for my > redhat trees (which takes ~15 minutes to run and (I think) results > in an extra copy of some of the packages on disk). That can be a pain if one is trying to hone it down to fit on a bootable CD using the format of the original RH 9 distribution CD. > If you just want the latest versions of update packages that could > probably be done easily enough. I'd be happy to just have a merged RH 9 system consisting of the original files and updates up to the EOL, but with duplicate RPMS removed. > > Is this something useful for FedoraLegacy to include in its distribution > > tree? > > Well I'm not sure that iso's would be anything other than a space > waste -- anyone could make their own anyway. A list of rpms which > are current or a script to generate such a list would be much > smaller and possibly of more use to more people. Yea, I can make my own ISOs so long as they will each fit on a single CD. My goal was to create a set of RH 9 install CDs with the RPMs based on what existed at EOL. From pekkas at netcore.fi Mon Jun 7 06:27:56 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 7 Jun 2004 09:27:56 +0300 (EEST) Subject: 8.0 packages to QA In-Reply-To: <1086538267.698.31.camel@localhost.localdomain> Message-ID: On 6 Jun 2004, Pedro Canadilla wrote: > Another one: "We are currently supporting Red Hat Linux 7.2, 7.3, 8.0 > and 9 as these have reached their End-of-Life (EOL). We will provide > support for these Red Hat releases for as long as there is community > interest." [...] > It's not a complaint, only deception. Easy solution: remove 7.2 and 8.0 from the (claimed) supported list. :-) We could still throw in a fixed package or two to 7.2/8.0 if be bother to (I wouldn't suggest that though), but at least the message would be clear... :) -- 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 paul at frields.com Mon Jun 7 11:33:08 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 07 Jun 2004 07:33:08 -0400 Subject: RH 9 EOL Updates ISOs In-Reply-To: <20040606235025.M32227@mm-vanecek.cc> References: <20040606235025.M32227@mm-vanecek.cc> Message-ID: <1086607987.3647.7.camel@london.east.gov> On Sun, 2004-06-06 at 19:50, Mike Vanecek wrote: > On Sun, 06 Jun 2004 15:34:21 +0100, Jon Peatfield 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? > > > > > > 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). > > > > I make use of a handy repostory maintenance script (rh_buildtree > > written by Peter Benie who works in a different department here), > > which given a set of directories full of rpms constructs/maintains a > > directory which contains the latest version of all those packages > > which pass a signature-check (as hard-links to whichever source they > > were from -- original shipped version, updates, local-packages etc). > > Interesting. I finally just downloaded all the updates and put them on a CD. I > did have to do some editing to get rid of the old duplicate RPMS (moved them > to a folder by themselves). Have you (and other folks) checked out the RedHat-CD-HOWTO? It contains detailed instructions for using the anaconda-runtime package to generate your own CD's (and/or network installation source tree) including errata packages. I've done this for 7.x through 9 in the past and it works very well. -- Paul W. Frields, RHCE From villegas at math.gatech.edu Mon Jun 7 14:10:29 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Mon, 7 Jun 2004 10:10:29 -0400 Subject: Proposal for management of supported releases, was: Re: 8.0 packages to QA In-Reply-To: References: <1086538267.698.31.camel@localhost.localdomain> Message-ID: <20040607141029.GA15432@math30192.math.gatech.edu> On Mon, Jun 07, 2004 at 09:27:56AM +0300, Pekka Savola wrote: > Easy solution: remove 7.2 and 8.0 from the (claimed) supported list. I think there is a better solution, I believe someone alredy proposed it, after some though I think is a good solution: release the updates for different distributions independently, the reason I think this is a good solution is because in the (far?) future the interest for say RHL9 might die out, and then the same problem will happen (one release holding out the others, and then some discussion between the few remaining trying to keep it alive). It also makes it easier to "single out" releases for discarding (or not) depending on the number of updates that actually make it out per release. It also enables a "pseudo support" for those unsupported releases in the fashion of something like the following sentence in an advisory for that version: "recompiling the srpm for RH9 might work, but it might not, it is not guaranteed or tested or supported by the FL community..." (for example for RH 8), although I agree with Jesse that that is a bad idea (pseudo support), but maybe the interested people in the updates will use them or decide to test them and revive the support for it ?. Usual disclaimer: I have no interest on the 7.2 or 8.0 (or 7.3) releases. Carlos From jpdalbec at ysu.edu Mon Jun 7 17:39:54 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 07 Jun 2004 13:39:54 -0400 Subject: QA request Message-ID: <40C4A86A.9080504@ysu.edu> I'd appreciate it if someone could QA my RH 7.3 packages at least. I've built 7.2 and 8.0 packages also so you could QA those if you feel motivated to do so. https://bugzilla.fedora.us/show_bug.cgi?id=1289 - new XFree86 packages https://bugzilla.fedora.us/show_bug.cgi?id=1376 - new wu-ftpd packages From jonny.strom at netikka.fi Mon Jun 7 17:50:02 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Mon, 07 Jun 2004 20:50:02 +0300 Subject: QA request In-Reply-To: <40C4A86A.9080504@ysu.edu> References: <40C4A86A.9080504@ysu.edu> Message-ID: <40C4AACA.3010903@netikka.fi> Hi And thanks John for the Xfree rpm's but we have a problem and that is that the rpm's at http://www.fedoralegacy.org/contrib/XFree86/ are forbidden to access: I get the following: Forbidden You don't have permission to access /contrib/XFree86/XFree86-75dpi-fonts-4.1.0-52.i386.rpm on this server. Apache/1.3.27 Server at www.fedoralegacy.org Port 80 So can someone that have access to www.fedoralegacy.org please change the permissionson those files, so that ppl can QA them. John Dalbec wrote: > I'd appreciate it if someone could QA my RH 7.3 packages at least. I've > built 7.2 and 8.0 packages also so you could QA those if you feel > motivated to do so. > > https://bugzilla.fedora.us/show_bug.cgi?id=1289 - new XFree86 packages > https://bugzilla.fedora.us/show_bug.cgi?id=1376 - new wu-ftpd packages > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jpdalbec at ysu.edu Mon Jun 7 18:06:56 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 07 Jun 2004 14:06:56 -0400 Subject: QA request In-Reply-To: <40C4AACA.3010903@netikka.fi> References: <40C4A86A.9080504@ysu.edu> <40C4AACA.3010903@netikka.fi> Message-ID: <40C4AEC0.5050803@ysu.edu> Johnny Strom wrote: > > Hi > > And thanks John for the Xfree rpm's but we have a problem and > that is that the rpm's at http://www.fedoralegacy.org/contrib/XFree86/ > are forbidden to access: > > I get the following: > > Forbidden > You don't have permission to access > /contrib/XFree86/XFree86-75dpi-fonts-4.1.0-52.i386.rpm on this server. > > Apache/1.3.27 Server at www.fedoralegacy.org Port 80 > > > > So can someone that have access to www.fedoralegacy.org please change > the permissionson those files, so that ppl can QA them. Done, sorry. My build system has umask 077. I forgot about the web server running with a different user. John > > > > > John Dalbec wrote: > >> I'd appreciate it if someone could QA my RH 7.3 packages at least. >> I've built 7.2 and 8.0 packages also so you could QA those if you feel >> motivated to do so. >> >> https://bugzilla.fedora.us/show_bug.cgi?id=1289 - new XFree86 packages >> https://bugzilla.fedora.us/show_bug.cgi?id=1376 - new wu-ftpd packages >> >> >> -- >> fedora-legacy-list mailing list >> fedora-legacy-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > From joey at clean.q7.com Mon Jun 7 18:26:16 2004 From: joey at clean.q7.com (Joe Pruett) Date: Mon, 7 Jun 2004 11:26:16 -0700 (PDT) Subject: does fedoralegacy depend on fedora.us? In-Reply-To: Message-ID: since there still isn't an official apt or yum for fedora legacy on rh9 boxes, we are instructed to use the fedora.us version. further, we are only instructed to add the fedoralegacy.org url to the sources.list file and not to comment out the fedora.us urls (or the macromedia ones in sources.list.d). is this an oversight in the docs (like not telling us to install the fedora legacy key)? or are you relying on the other rpms that fedora.us would install (10 packages that i see via apt-get -s upgrade)? i have assumed this is an oversight and not installed the fedora.us rpms, but clarification would be good, as well as updating the docs. From jkeating at j2solutions.net Mon Jun 7 18:33:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 7 Jun 2004 11:33:01 -0700 Subject: does fedoralegacy depend on fedora.us? In-Reply-To: References: Message-ID: <200406071133.04002.jkeating@j2solutions.net> On Monday 07 June 2004 11:26, Joe Pruett wrote: > since there still isn't an official apt or yum for fedora legacy on > rh9 boxes, we are instructed to use the fedora.us version. further, > we are only instructed to add the fedoralegacy.org url to the > sources.list file and not to comment out the fedora.us urls (or the > macromedia ones in sources.list.d). is this an oversight in the docs > (like not telling us to install the fedora legacy key)? or are you > relying on the other rpms that fedora.us would install (10 packages > that i see via apt-get -s upgrade)? i have assumed this is an > oversight and not installed the fedora.us rpms, but clarification > would be good, as well as updating the docs. Oversight. We absolutely do NOT depend on Fedora.us. A 9 version of yum is in QA mode, apt needs some love. -- 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 Mon Jun 7 20:02:12 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 15:02:12 -0500 Subject: 8.0 packages to QA In-Reply-To: <1086533395.28546.2.camel@mdlinux> References: <1086532867.915.17.camel@localhost.localdomain> <1086533395.28546.2.camel@mdlinux> Message-ID: <20040607150212.4o4kkgwgko8co88s@mail.ph.utexas.edu> Quoting Marc Deslauriers : > I wouldn't spend time testing the rh8 packages unless you need them for > yourself. AFAIK, rh72 and rh8 support has been dropped from Fedora > Legacy because of lack of interest. There hasn't been an official > announcement, but it should be coming soon. It may still be worth testing and pushing any updates which are already built before we will off RH 8.0 support. So if we can get them past QA before we officially kill it off, we can release them for those who want them. Interesting that no one has come to the rescue of RH 7.2, but several have tried to rescue RH 8.0. I'm guessing both will be terminated, but it is still interesting none-the-less. > Marc. -- Eric Rostetter From Ow.Mun.Heng at wdc.com Sun Jun 6 17:10:31 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Mon, 07 Jun 2004 01:10:31 +0800 Subject: 8.0 packages to QA In-Reply-To: References: Message-ID: <1086541831.23566.10.camel@Neuromancer.home.net> On Mon, 2004-06-07 at 00:42, Jon Peatfield wrote: > > > Is it necessary to edit the spec from the rpm file to > > include the pacht? > > Usually yes, if the patch replaces one of the same name you *could* > avoid editing the specfile, but usually you at least want to change > the release version! > > The specfile contains a list of patches to apply to the source, if the > same (exact) patch applies as can be takes from another source (Debian > or RHEL fro example), then you just need to add the PatchN lines to > the specfile, change the package release and rebuild. And usually do you include the patch url into the spec file? Do you patch it before making into RPM or get rpmbuild to wget the patch and merge it? How would one know if we're "not" doing more harm than actually making a "good" package? > If the package is the same version (or "close enough") as in RH9 or > RHEA-AS3 (etc) then rebuilding from the update SRPM will usually give > you a package which works on RH73, RH8 or 9. To avoid later confusion > it is probably best practice to add something to the "release" version > to indicate that it is a rebuild for a different version by you (as > fedora-legacy does). One of my _ways_ in getting some updated stuffs is to use FC1's SRPMS and recompiling them on _my_ machine. (hoping that it's "Close Enough") to work. I've managed to get a _few_ packages this way, but... I'm not sure if I've been more help or harm. > > I've been a bit varied in my numbering scheme(s), but currently try to > change anything that looks like a redhat linux version-number to "80" > or "RHL80" and add a JSP in there to show they are my rebuilds. Never did understand epoch/release #. > The biggest pain is when the BuildRequires lines arn't complete; > e.g. you meet them only to find that the rpmbuild fails 'cos a needed > dependency is missing. I live in fear of it just producing a > "slightly broken" version which I won't spot 'til I've deployed it. Exactly.. > I'd be happy to make all the packages that I have for download (I have > to build them anyway), but they are *only* for RH80 and apparently few > people (on this list at least) use that. I still use it, if that's any consolation. My RH8 Box is still in service. Considered upgrading to FC2 or something though. Did an upgrade on my RH9 (laptop) to FC2, turned out, well, in a way, screwed. Couldn't get gdmgreeter to start properly. Something bout not recognising .png files etc. Startx works though. > I've still got no idea how to offer them up for fdl to look at/test > though. can you contact jesse keating and upload to the fedora-legacy site. It'll be Very helpful for ppl like me. (PPl that needs to get a clue on how to _properly_ admin a box. and I only have 1 box to admin!) > > Of course you might not trust me or my packages (why should anyone). hehe.. Why Not?? I'm pretty OK With 'other' ppl packages. I'm paranoid, but I'm running Linux, so I'm pretty "OK" with these packages being devoid of viruses/rootkits etc. (Since The box' not connected to the I-Net so.., some consolation I guess) > If there isn't a track kept of testing use then unless you "know" all > the testers you can't tell if they started (downloaded packages etc), > but never actually did anything. Not reporting problems doesn't mean > that there arn't any... Well, out of the updates from fedora-legacy which I've installed, all seems fine From Ow.Mun.Heng at wdc.com Sun Jun 6 17:13:08 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Mon, 07 Jun 2004 01:13:08 +0800 Subject: RH 9 EOL Updates ISOs In-Reply-To: <1086532740.20154.2.camel@nomad> References: <1086532740.20154.2.camel@nomad> Message-ID: <1086541988.23566.12.camel@Neuromancer.home.net> On Sun, 2004-06-06 at 22:39, Michael Weiner wrote: > On Sun, 2004-06-06 at 15:34 +0100, Jon Peatfield wrote: > > I make use of a handy repostory maintenance script (rh_buildtree > > written by Peter Benie who works in a different department here), > > which given a set of directories full of rpms constructs/maintains a > > directory which contains the latest version of all those packages > > which pass a signature-check (as hard-links to whichever source they > > were from -- original shipped version, updates, local-packages etc). > > > > [ We use it to re-build install trees overnight so that a fresh > > install always goes straight to having the latest versions available > > from the tree (which saves having insecure versions until patched and > > also is much quicker). > > > > We also use a script (rpmalert) which checks what versions are > > out-of-date on a machine and another (rpm-update) which applies the > > updates we have flagged as ok, but I suppose you may have yum/up2date > > for that function anyway. ] > > > > I'm still using this older repository maintenance script for my redhat > > trees (which takes ~15 minutes to run and (I think) results in an > > extra copy of some of the packages on disk). > > > > As part of my experiments with Suse9 I tried Peter's new repository > > maintenance script (rpmstream) which usually runs in seconds (since it > > keeps more cache info around). > > > > If you just want the latest versions of update packages that could > > probably be done easily enough. > > > > and are ANY of these scripts available publically, or anything CLOSE? > I would be interested in these scripts too -- From rostetter at mail.utexas.edu Mon Jun 7 20:23:23 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 15:23:23 -0500 Subject: 8.0 packages to QA In-Reply-To: <1086538267.698.31.camel@localhost.localdomain> References: <1086532867.915.17.camel@localhost.localdomain> <1086533395.28546.2.camel@mdlinux> <1086538267.698.31.camel@localhost.localdomain> Message-ID: <20040607152323.ck0wg4o4gsc4w04w@mail.ph.utexas.edu> Quoting Pedro Canadilla : > It's a pity. I remember a paragraph from the FAQ... Yes, it is a pity. > "For supported Red Hat Linux releases, we will continue to issue > back-port security or critical fixes for as long as there is community > interest, but for at least another 1.5 years from their official Red Hat > End of Life." Yes, we would seem to be violating that "at least 1.5 years from their [EOL]" part. > Another one: "We are currently supporting Red Hat Linux 7.2, 7.3, 8.0 > and 9 as these have reached their End-of-Life (EOL). We will provide > support for these Red Hat releases for as long as there is community > interest." That part is correct. > There are people that have interest in rh8. Perhaps not so many as > others releases. Maybe it should say: < users from your distribution rather than others (democracy?) or there > are an algorith that determine that yours is relevant (ramdom?)>>. No, the community interest is correct. There must be community interest, which in the common usage for an opensource project means that there must be more than 2 people willing to support/develope it. So far, there has not been more than 2 people will to develope for RH 8.0. Don't confuse community interest with people paying lip service to wanting something. Community interest means people getting involved and participating, not just saying they are interested in it. > I understand the lack of resources of fedora legacy as I understand the > lack of resources from the hardware to upgrade to 9 or to FC1 as some > people has told here. I understand that 1.5 years is time enough to get > investment to replace the obsoleted hardware, but 0.5 years is not. I think the 1.5 year statement is an issue. But the lack of support is also an issue. > It's not a complaint, only deception. > > Regards, > P.C. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Jun 7 21:34:43 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 16:34:43 -0500 Subject: 8.0 packages to QA In-Reply-To: References: Message-ID: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> Quoting Pekka Savola : > Easy solution: remove 7.2 and 8.0 from the (claimed) supported list. > :-) That is essentially what Red Hat did that caused the need for FedoraLegacy in the first place. FedoraLegacy was supposed to fix the sudden drop of support for RHL, not do the same thing to its users. > We could still throw in a fixed package or two to 7.2/8.0 if be bother > to (I wouldn't suggest that though), but at least the message would be > clear... :) Yes, that FL doesn't care any more about its community than RH did. Is that the message we want to give? The reason for FL was so that people could plan for upgrades with a fixed support time for their releases. If we just drop them, then we've deceived these people (saying we'd support them for at least 1.5 years, and then not doing it). I'm not saying we can't do this, as if there is no community support, then it should be done. But we need to be upfront about it, and the message we should give out is one of fact (lack of community support) and not just one of convenience (now you see it, now you don't). And no, I didn't miss the smilly faces in the post. But I'm sure others will miss them, or misinterpret them, so I'm answering as if they are not there. -- Eric Rostetter From kelson at speed.net Mon Jun 7 21:40:07 2004 From: kelson at speed.net (Kelson Vibber) Date: Mon, 07 Jun 2004 14:40:07 -0700 Subject: 8.0 packages to QA In-Reply-To: <1086541831.23566.10.camel@Neuromancer.home.net> References: <1086541831.23566.10.camel@Neuromancer.home.net> Message-ID: <6.1.0.6.0.20040607142151.034b56f8@mail.speed.net> At 10:10 AM 6/6/2004, Ow Mun Heng wrote: >On Mon, 2004-06-07 at 00:42, Jon Peatfield wrote: > > The specfile contains a list of patches to apply to the source, if the > > same (exact) patch applies as can be takes from another source (Debian > > or RHEL fro example), then you just need to add the PatchN lines to > > the specfile, change the package release and rebuild. > >And usually do you include the patch url into the spec file? Not in any RPMs I've looked at. >Do you patch it before making into RPM or get rpmbuild to wget the patch >and merge it? One of the design goals (IIRC) of RPM was to be able to start with a project's plain, unmodified source code and add patches and structure on top of it. So a source RPM should include: - unpatched source code (usually tar.gz or tar.bz2) - patches (if needed) - install/uninstall scripts (if needed) - additional files (.desktop entries, icons, etc.) - the spec file You should download the patch, copy it to your RPM source directory, then add two lines to the .spec file, one in the header section identifying the patch filename, the other in the %setup section indicating at what point that patch should be applied. Something like: Patch1: add-redhat-customization.diff Patch2: fix-for-such-and-such.diff ... %setup %patch2 -p1 %patch1 -p0 Then rpmbuild will apply the patch as part of the build process. >How would one know if we're "not" doing more harm than actually making a >"good" package? You can use "rpmbuild -bp" to only work up through applying the patches to see if it's applied cleanly. If not, you may need to reorder the patches, change the -p option, edit the patch, or something more complicated. Kelson Vibber SpeedGate Communications From jonny.strom at netikka.fi Mon Jun 7 21:54:08 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 08 Jun 2004 00:54:08 +0300 Subject: 8.0 packages to QA In-Reply-To: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> Message-ID: <40C4E400.9090808@netikka.fi> Eric Rostetter wrote: > Quoting Pekka Savola : > >> Easy solution: remove 7.2 and 8.0 from the (claimed) supported list. >> :-) > > > That is essentially what Red Hat did that caused the need for FedoraLegacy > in the first place. FedoraLegacy was supposed to fix the sudden drop of > support for RHL, not do the same thing to its users. > >> We could still throw in a fixed package or two to 7.2/8.0 if be bother >> to (I wouldn't suggest that though), but at least the message would be >> clear... :) > > > Yes, that FL doesn't care any more about its community than RH did. > Is that the message we want to give? > Well to me it seems like there are quite a lot of ppl. that have shown intrest in doing backporting and QA on fedora but it seems that there are quite few that actually is doing anyting. I try to do my best and offer my freetime to help out with QA and things like that, it is not so hard to look in bugzila download packages and QA them and give feedback into bugzilla. So it is a lack of manpower that would care about rh 7.2 and rh 8.0 that is what why there is a problem. So to fix this I porpose that we setup a "what needs to be done list" that is sent out every second week or so, any thoughts on that? > The reason for FL was so that peopl e could plan for upgrades with a > fixed support time for their releases. If we just drop them, then > we've deceived these people (saying we'd support them for at least 1.5 > years, and then not doing it). > > I'm not saying we can't do this, as if there is no community support, > then it should be done. But we need to be upfront about it, and the > message we should give out is one of fact (lack of community support) > and not just one of convenience (now you see it, now you don't). > > And no, I didn't miss the smilly faces in the post. But I'm sure others > will miss them, or misinterpret them, so I'm answering as if they are > not there. > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From heinlein at cse.ogi.edu Mon Jun 7 22:04:23 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Mon, 7 Jun 2004 15:04:23 -0700 (PDT) Subject: 8.0 packages to QA In-Reply-To: <40C4E400.9090808@netikka.fi> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: On Tue, 8 Jun 2004, Johnny Strom wrote: > So to fix this I porpose that we setup a "what needs to be done > list" that is sent out every second week or so, any thoughts on > that? It would be *so* nice to have something like that or, if it already exists, a bugzilla URL that will accomplish the same thing. If the latter, I'd happy write up a bash/wget script that people can use in their own cron jobs. Part of the problem -- and this is merely a description, not a gripe, and it's certainly not directed at Jesse, who's put in way more work than anyone should expect -- is that it's difficult to find the time to figure out what needs doing. I'd happily Q/A more packages, but doing so requires (afaict) lots of bugzilla spelunking, and I'm still never sure if I've got it all. I realize that it requires lots of labor hours to make nifty interfaces and current web pages -- but that's my view from the cheap seats. --Paul Heinlein From Ow.Mun.Heng at wdc.com Sun Jun 6 19:14:36 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Mon, 07 Jun 2004 03:14:36 +0800 Subject: 8.0 packages to QA In-Reply-To: <40C4E400.9090808@netikka.fi> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <1086549276.23566.92.camel@Neuromancer.home.net> On Tue, 2004-06-08 at 05:54, Johnny Strom wrote: > Eric Rostetter wrote: > > Quoting Pekka Savola : > > > > Yes, that FL doesn't care any more about its community than RH did. > > Is that the message we want to give? > > > > Well to me it seems like there are quite a lot of ppl. that have shown > intrest in doing backporting and QA on fedora but it seems that there > are quite few that actually is doing anyting. I agree with you there. I'm ' Case - In - Point' I have interest, however, my issue is that I'm sort of a 'newbie' if you may in terms of looking for fixes and trying to do the backporting etc.. hey, I am willing to eat my own dog food, But 1st, I need to know how to 'Prepare" it. Point me into the "right" direction and I'll be eternally grateful. > I try to do my best and offer my freetime to help out with QA and things > like that, it is not so hard to look in bugzila download packages and QA > them and give feedback into bugzilla. > > So to fix this I porpose that we setup a "what needs to be done list" > that is sent out every second week or so, any thoughts on that? From Ow.Mun.Heng at wdc.com Sun Jun 6 19:20:06 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Mon, 07 Jun 2004 03:20:06 +0800 Subject: 8.0 packages to QA In-Reply-To: <6.1.0.6.0.20040607142151.034b56f8@mail.speed.net> References: <1086541831.23566.10.camel@Neuromancer.home.net> <6.1.0.6.0.20040607142151.034b56f8@mail.speed.net> Message-ID: <1086549606.23566.103.camel@Neuromancer.home.net> On Tue, 2004-06-08 at 05:40, Kelson Vibber wrote: > At 10:10 AM 6/6/2004, Ow Mun Heng wrote: > >On Mon, 2004-06-07 at 00:42, Jon Peatfield wrote: > > > The specfile contains a list of patches to apply to the source, if the > > > same (exact) patch applies as can be takes from another source (Debian > > > or RHEL fro example), then you just need to add the PatchN lines to > > > the specfile, change the package release and rebuild. > > > >And usually do you include the patch url into the spec file? > > Not in any RPMs I've looked at. Okay.. I might have mistaken those for the FreeBSD ports I've looked at. > > >Do you patch it before making into RPM or get rpmbuild to wget the patch > >and merge it? > > One of the design goals (IIRC) of RPM was to be able to start with a > project's plain, unmodified source code and add patches and structure on > top of it. So a source RPM should include: > > - unpatched source code (usually tar.gz or tar.bz2) > - patches (if needed) > - install/uninstall scripts (if needed) > - additional files (.desktop entries, icons, etc.) > - the spec file Understood. > > You should download the patch, Where to "Find" the patch would be the question. Someone on this list actually pointed a few URLs. however, I would like to get some sort of consensus here, Is BugZilla "the" way to go to look for patches? Eg: If I see something on Bugtraq which affects one of my RH8.0 packages, Can I just look into bugzilla and "try" to locate the patch for it?? If it's not available there, are there any other locations whereby it can be found? I guess, My problem would be "not" that I can't roll my own RPMs, it's more towards where to locate the patch (hand diffing the .rej is fine too) and then updating the corresponding .spec file. Thanks. /The One Who still doesn't get .spec files > copy it to your RPM source directory, then > add two lines to the .spec file, one in the header section identifying the > patch filename, the other in the %setup section indicating at what point > that patch should be applied. > > Something like: > Patch1: add-redhat-customization.diff > Patch2: fix-for-such-and-such.diff > > ... > > %setup > %patch2 -p1 > %patch1 -p0 > > Then rpmbuild will apply the patch as part of the build process. > > >How would one know if we're "not" doing more harm than actually making a > >"good" package? > > You can use "rpmbuild -bp" to only work up through applying the patches to > see if it's applied cleanly. If not, you may need to reorder the patches, > change the -p option, edit the patch, or something more complicated. > > Kelson Vibber > SpeedGate Communications > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- From Ow.Mun.Heng at wdc.com Sun Jun 6 19:24:00 2004 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Mon, 07 Jun 2004 03:24:00 +0800 Subject: 8.0 packages to QA In-Reply-To: References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <1086549840.23566.111.camel@Neuromancer.home.net> On Tue, 2004-06-08 at 06:04, Paul Heinlein wrote: > On Tue, 8 Jun 2004, Johnny Strom wrote: > > > So to fix this I porpose that we setup a "what needs to be done > > list" that is sent out every second week or so, any thoughts on > > that? > > It would be *so* nice to have something like that or, if it already > exists, a bugzilla URL that will accomplish the same thing. If the > latter, I'd happy write up a bash/wget script that people can use in > their own cron jobs. > > Part of the problem -- and this is merely a description, not a gripe, > and it's certainly not directed at Jesse, who's put in way more work > than anyone should expect -- is that it's difficult to find the time > to figure out what needs doing. I'd happily Q/A more packages, but > doing so requires (afaict) lots of bugzilla spelunking, and I'm still > never sure if I've got it all. > > I realize that it requires lots of labor hours to make nifty > interfaces and current web pages -- but that's my view from the cheap > seats. I understand this fact as well. I for one, am always one who's been sitting on the sidelines while you gentlemens do the dirty work. (I am throughly ashamed) :( But as you state above, the problem quote "is that it's difficult to find the time to figure out what needs doing" I really need to get a clue. And Once I _do_ get a clue, I'm gonna make sure I "Dot my i's and cross my t's" so to speak. :-) From jonny.strom at netikka.fi Mon Jun 7 22:20:31 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 08 Jun 2004 01:20:31 +0300 Subject: 8.0 packages to QA In-Reply-To: References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <40C4EA2F.2040005@netikka.fi> Paul Heinlein wrote: > On Tue, 8 Jun 2004, Johnny Strom wrote: > >> So to fix this I porpose that we setup a "what needs to be done list" >> that is sent out every second week or so, any thoughts on that? > > > It would be *so* nice to have something like that or, if it already > exists, a bugzilla URL that will accomplish the same thing. If the > latter, I'd happy write up a bash/wget script that people can use in > their own cron jobs. > Ok I will think about what should be in such a list I guess just short descriptions and pointers to bugzilla that is a good start already, I will try to make a first list next weekend when I have talked to ppl about it. > Part of the problem -- and this is merely a description, not a gripe, > and it's certainly not directed at Jesse, who's put in way more work > than anyone should expect -- is that it's difficult to find the time to > figure out what needs doing. I'd happily Q/A more packages, but doing so > requires (afaict) lots of bugzilla spelunking, and I'm still never sure > if I've got it all. > > I realize that it requires lots of labor hours to make nifty interfaces > and current web pages -- but that's my view from the cheap seats. > > --Paul Heinlein > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From marcdeslauriers at videotron.ca Mon Jun 7 22:23:23 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 07 Jun 2004 18:23:23 -0400 Subject: 8.0 packages to QA In-Reply-To: References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <1086647003.31552.1.camel@mdlinux> On Mon, 2004-06-07 at 18:04, Paul Heinlein wrote: > Part of the problem -- and this is merely a description, not a gripe, > and it's certainly not directed at Jesse, who's put in way more work > than anyone should expect -- is that it's difficult to find the time > to figure out what needs doing. I'd happily Q/A more packages, but > doing so requires (afaict) lots of bugzilla spelunking, and I'm still > never sure if I've got it all. What about some new bugzilla keywords, something like "needs73rpms", "needs9QA"? Marc. From jonny.strom at netikka.fi Mon Jun 7 22:31:02 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 08 Jun 2004 01:31:02 +0300 Subject: 8.0 packages to QA In-Reply-To: <1086647003.31552.1.camel@mdlinux> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> <1086647003.31552.1.camel@mdlinux> Message-ID: <40C4ECA6.2040006@netikka.fi> Marc Deslauriers wrote: > On Mon, 2004-06-07 at 18:04, Paul Heinlein wrote: > >>Part of the problem -- and this is merely a description, not a gripe, >>and it's certainly not directed at Jesse, who's put in way more work >>than anyone should expect -- is that it's difficult to find the time >>to figure out what needs doing. I'd happily Q/A more packages, but >>doing so requires (afaict) lots of bugzilla spelunking, and I'm still >>never sure if I've got it all. > > > What about some new bugzilla keywords, something like "needs73rpms", > "needs9QA"? Yes I will think about that... > Marc. > > > > -- > 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 Jun 7 22:32:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 7 Jun 2004 15:32:23 -0700 Subject: 8.0 packages to QA In-Reply-To: <40C4EA2F.2040005@netikka.fi> References: <40C4EA2F.2040005@netikka.fi> Message-ID: <200406071532.23493.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 07 June 2004 15:20, Johnny Strom wrote: > Ok > > I will think about what should be in such a list I guess just short > descriptions and pointers to bugzilla that is a good start already, > I will try to make a first list next weekend when I have talked to > ppl about it. This is something I can do pretty easily. I go through every bugzilla report at least once a week and write myself a to-do list on my desktop. I can easily write one for the mailing list as well. Look for one tonight even. - -- 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) iD8DBQFAxOz34v2HLvE71NURAhbXAKCfKtxyBn2Njg8uVAuP8GjH/B7n1wCfb3pr h0JpFetYx+X/xq6XAGL5tdQ= =Fq8Z -----END PGP SIGNATURE----- From heinlein at cse.ogi.edu Mon Jun 7 22:34:42 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Mon, 7 Jun 2004 15:34:42 -0700 (PDT) Subject: 8.0 packages to QA In-Reply-To: <1086647003.31552.1.camel@mdlinux> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> <1086647003.31552.1.camel@mdlinux> Message-ID: On Mon, 7 Jun 2004, Marc Deslauriers wrote: >> Part of the problem -- and this is merely a description, not a >> gripe, and it's certainly not directed at Jesse, who's put in way >> more work than anyone should expect -- is that it's difficult to >> find the time to figure out what needs doing. I'd happily Q/A more >> packages, but doing so requires (afaict) lots of bugzilla >> spelunking, and I'm still never sure if I've got it all. > > What about some new bugzilla keywords, something like "needs73rpms", > "needs9QA"? It's a start, perhaps, but the process would still be somewhat obscure: 1. Get to buzilla, enter keyword. 2. Review each ticket, figuring out - whether new keyword is still valid for this ticket - what package is involved - urls for src and/or binary rpms 3. Download, build/install, test 4. Report back I think my ideal would be something a little bit -- though not a lot -- simpler: 1. Peruse e-mailed nightly Q/A report over morning caffeine 2. Use links in report to download SRPMS or RPMS for testing 3. Build/install, test 4. Report back. A package would remain in the nightly Q/A report until it's moved into the official testing tree or it's withdrawn entirely. It's not ideal, but it'd certainly be easier for me to get test packages installed and run through whatever wringer I can devise. --Paul Heinlein From rostetter at mail.utexas.edu Mon Jun 7 22:35:15 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 17:35:15 -0500 Subject: does fedoralegacy depend on fedora.us? In-Reply-To: References: Message-ID: <20040607173515.9k4wwsg4w0g8ck48@mail.ph.utexas.edu> Quoting Joe Pruett : > since there still isn't an official apt or yum for fedora legacy on rh9 > boxes, we are instructed to use the fedora.us version. Not sure if you are instructed to use it, but I tried to provide instructions should you choose to use it. > further, we are > only instructed to add the fedoralegacy.org url to the sources.list file > and not to comment out the fedora.us urls (or the macromedia ones in > sources.list.d). Probably an oversight. Care to provide an updated description of what to do? > is this an oversight in the docs (like not telling us to > install the fedora legacy key)? Sounds like it. I wrote them in a hurry, and without testing them. > or are you relying on the other rpms that > fedora.us would install (10 packages that i see via apt-get -s upgrade)? No, they are not needed or even desired. > i have assumed this is an oversight and not installed the fedora.us rpms, > but clarification would be good, as well as updating the docs. I think it is all just oversights on my part, and any help updating the docs would be appreciated. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Jun 7 23:35:29 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 18:35:29 -0500 Subject: 8.0 packages to QA In-Reply-To: <40C4E400.9090808@netikka.fi> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <20040607183529.804scccg0g8sgwwg@mail.ph.utexas.edu> Quoting Johnny Strom : > So to fix this I porpose that we setup a "what needs to be done list" > that is sent out every second week or so, any thoughts on that? I think it might help some, if done right. One problem with FL QA testing (not update development, but QA testing after that) is that people don't know what is available to test, since they don't want to troll the bugzilla DB on a regular basis. So if we got the word out via a mailing list, more people might help in QA testing (before it goes to testing, as well as after it goes to testing). -- Eric Rostetter From rostetter at mail.utexas.edu Mon Jun 7 23:39:37 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 18:39:37 -0500 Subject: 8.0 packages to QA In-Reply-To: References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> Message-ID: <20040607183937.ogcg4k4g8048gs0k@mail.ph.utexas.edu> Quoting Paul Heinlein : > On Tue, 8 Jun 2004, Johnny Strom wrote: > >> So to fix this I porpose that we setup a "what needs to be done >> list" that is sent out every second week or so, any thoughts on that? > > It would be *so* nice to have something like that or, if it already > exists, a bugzilla URL that will accomplish the same thing. If the > latter, I'd happy write up a bash/wget script that people can use in > their own cron jobs. There is a web link to the bugzilla stuff, but it isn't as useful as a clear, detailed email would be since the subject line is often inaccurate, etc. > Part of the problem -- and this is merely a description, not a gripe, > and it's certainly not directed at Jesse, who's put in way more work > than anyone should expect -- is that it's difficult to find the time > to figure out what needs doing. I'd happily Q/A more packages, but > doing so requires (afaict) lots of bugzilla spelunking, and I'm still > never sure if I've got it all. Sometimes it does indeed. Some of the bugzilla subjects only mention e.g. RH 7.3, but then the entry also addresses RH 8.0, but how to know that without reading each entry in full? That makes things difficult... > I realize that it requires lots of labor hours to make nifty > interfaces and current web pages -- but that's my view from the cheap > seats. Yes, but it does pay off in increased community participation. > --Paul Heinlein > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Eric Rostetter From rostetter at mail.utexas.edu Mon Jun 7 23:46:05 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 7 Jun 2004 18:46:05 -0500 Subject: 8.0 packages to QA In-Reply-To: <1086549276.23566.92.camel@Neuromancer.home.net> References: <20040607163443.o884ws8gcc8c4s4c@mail.ph.utexas.edu> <40C4E400.9090808@netikka.fi> <1086549276.23566.92.camel@Neuromancer.home.net> Message-ID: <20040607184605.p1c0wss4o0s0888w@mail.ph.utexas.edu> Quoting Ow Mun Heng : > hey, I am willing to eat my own dog food, But 1st, I need to know how to > 'Prepare" it. > > Point me into the "right" direction and I'll be eternally grateful. First visit http://www.fedoralegacy.org/wiki/index.php/FedoraLegacyDocs and read the docs there. Then ask any remaining questions on the mailing list so we can help you. Then start actually doing it. The last step is important ;) To answer some other questions, you track updates that need to be done or tested at https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY You learn how to participate at http://www.fedoralegacy.org/participate/ You find other tasks that need to be done at http://www.fedoralegacy.org/participate/task-list.php -- Eric Rostetter From kelson at speed.net Mon Jun 7 23:50:15 2004 From: kelson at speed.net (Kelson Vibber) Date: Mon, 07 Jun 2004 16:50:15 -0700 Subject: 8.0 packages to QA In-Reply-To: <1086549606.23566.103.camel@Neuromancer.home.net> References: <1086541831.23566.10.camel@Neuromancer.home.net> <6.1.0.6.0.20040607142151.034b56f8@mail.speed.net> <1086549606.23566.103.camel@Neuromancer.home.net> Message-ID: <6.1.0.6.0.20040607161809.02523050@mail.speed.net> At 12:20 PM 6/6/2004, Ow Mun Heng wrote: >Where to "Find" the patch would be the question. Someone on this list >actually pointed a few URLs. however, I would like to get some sort of >consensus here, Is BugZilla "the" way to go to look for patches? Eg: If >I see something on Bugtraq which affects one of my RH8.0 packages, Can I >just look into bugzilla and "try" to locate the patch for it?? If it's >not available there, are there any other locations whereby it can be >found? Well, if no one's posted a patch to bugzilla yet, there's always the program's home page. Some projects (sendmail, for instance) will post patches in addition to releasing updated versions of the program. I think Jon was suggesting that if another vendor issues a patched package, if you can get the sources - say from an RHEL-provided SRPM - you should be able to extract the patch from that package. In the case of using someone else's SRPM, the easiest way to deal with it is: rpm -ivh patched-for-other-distro.src.rpm (rename the spec file so it won't get overwritten) rpm -ivh latest-for-your-distro.src.rpm At this point you'll have all the appropriate sources for the package on RH8, plus the patch that was provided by the other vendor (say RHEL). You can then copy the appropriate lines from the other spec file and build an RPM incorporating the patch. P.S. *Please* don't use quotation marks for emphasis. Those of us who went through writing programs in college cringe every time we see them misused that way. Quotation marks indicate precision (as in an exact quotation), titles, or, in informal writing, doubt or irony (as in so-called "scare quotes") - never emphasis. Kelson Vibber SpeedGate Communications From michal at harddata.com Tue Jun 8 00:08:24 2004 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 7 Jun 2004 18:08:24 -0600 Subject: 8.0 packages to QA In-Reply-To: <200406071532.23493.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Mon, Jun 07, 2004 at 03:32:23PM -0700 References: <40C4EA2F.2040005@netikka.fi> <200406071532.23493.jkeating@j2solutions.net> Message-ID: <20040607180824.B22865@mail.harddata.com> I cannot get rid of a thought that if we would have such activity in bugzilla like in this discussion about bugzilla then this discussion would be really not needed. :-) Michal From hbo at egbok.com Tue Jun 8 01:02:04 2004 From: hbo at egbok.com (Howard Owen) Date: Mon, 7 Jun 2004 18:02:04 -0700 (PDT) Subject: 8.0 packages to QA In-Reply-To: <6.1.0.6.0.20040607161809.02523050@mail.speed.net> Message-ID: I'd also suggest that the bugzilla entry be named in such a way as to clearly point to the problem. Often the bugtraq message subject is good for this. See for example https://bugzilla.fedora.us/show_bug.cgi?id=1719. In Red Hat's bugzilla, the component and product fields are often useful for narrowing down a search. Unfortunately, fedora.us doesn't make extensive use of these fields. The 'Fedora Legacy' "product" and the 'LEGACY' keyword are pretty useful, though. Other than that, bugtraq is a good place to look for patches, too. If you aren't in a tremendous hurry, waiting for patches from other distros, particularly the Red Hat ones, can be effective. If you *are* in a hurry, or if the package isn't getting the attention from the vendors it deserves, then the upstream package provider is the place to go. Security Focus also maintains a useful vulnerability list at http://www.securityfocus.com/bid. This has the nice property of listing which versions in which distributions are vulnerable, even for those not supported by the vendor. On Mon, 7 Jun 2004, Kelson Vibber wrote: > At 12:20 PM 6/6/2004, Ow Mun Heng wrote: > >Where to "Find" the patch would be the question. Someone on this list > >actually pointed a few URLs. however, I would like to get some sort of > >consensus here, Is BugZilla "the" way to go to look for patches? Eg: If > >I see something on Bugtraq which affects one of my RH8.0 packages, Can I > >just look into bugzilla and "try" to locate the patch for it?? If it's > >not available there, are there any other locations whereby it can be > >found? > > Well, if no one's posted a patch to bugzilla yet, there's always the > program's home page. Some projects (sendmail, for instance) will post > patches in addition to releasing updated versions of the program. > > I think Jon was suggesting that if another vendor issues a patched package, > if you can get the sources - say from an RHEL-provided SRPM - you should be > able to extract the patch from that package. > > In the case of using someone else's SRPM, the easiest way to deal with it is: > > rpm -ivh patched-for-other-distro.src.rpm > (rename the spec file so it won't get overwritten) > rpm -ivh latest-for-your-distro.src.rpm > > At this point you'll have all the appropriate sources for the package on > RH8, plus the patch that was provided by the other vendor (say RHEL). You > can then copy the appropriate lines from the other spec file and build an > RPM incorporating the patch. > > P.S. *Please* don't use quotation marks for emphasis. Those of us who went > through writing programs in college cringe every time we see them misused > that way. Quotation marks indicate precision (as in an exact quotation), > titles, or, in informal writing, doubt or irony (as in so-called "scare > quotes") - never emphasis. > > > 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 hbo at egbok.com Tue Jun 8 02:14:03 2004 From: hbo at egbok.com (Howard Owen) Date: Mon, 7 Jun 2004 19:14:03 -0700 (PDT) Subject: 8.0 packages to QA In-Reply-To: Message-ID: It also strikes me that the CVE (http://cve.mitre.org) CAN numbers would be a great thing to include in the bugzilla title. Of course, these lag the bugtraq notices by quite a bit. But the title can be changed once they are available. On Mon, 7 Jun 2004, Howard Owen wrote: > > I'd also suggest that the bugzilla entry be named in such a way as to > clearly point to the problem. Often the bugtraq message subject is good > for this. See for example https://bugzilla.fedora.us/show_bug.cgi?id=1719. > > In Red Hat's bugzilla, the component and product fields are often useful > for narrowing down a search. Unfortunately, fedora.us doesn't make > extensive use of these fields. The 'Fedora Legacy' "product" and the > 'LEGACY' keyword are pretty useful, though. > > Other than that, bugtraq is a good place to look for patches, too. If you > aren't in a tremendous hurry, waiting for patches from other distros, > particularly the Red Hat ones, can be effective. If you *are* in a hurry, > or if the package isn't getting the attention from the vendors it > deserves, then the upstream package provider is the place to go. > > Security Focus also maintains a useful vulnerability list at > http://www.securityfocus.com/bid. This has the nice property of listing > which versions in which distributions are vulnerable, even for those not > supported by the vendor. > > On Mon, 7 Jun 2004, > Kelson Vibber wrote: > > > At 12:20 PM 6/6/2004, Ow Mun Heng wrote: > > >Where to "Find" the patch would be the question. Someone on this list > > >actually pointed a few URLs. however, I would like to get some sort of > > >consensus here, Is BugZilla "the" way to go to look for patches? Eg: If > > >I see something on Bugtraq which affects one of my RH8.0 packages, Can I > > >just look into bugzilla and "try" to locate the patch for it?? If it's > > >not available there, are there any other locations whereby it can be > > >found? > > > > Well, if no one's posted a patch to bugzilla yet, there's always the > > program's home page. Some projects (sendmail, for instance) will post > > patches in addition to releasing updated versions of the program. > > > > I think Jon was suggesting that if another vendor issues a patched package, > > if you can get the sources - say from an RHEL-provided SRPM - you should be > > able to extract the patch from that package. > > > > In the case of using someone else's SRPM, the easiest way to deal with it is: > > > > rpm -ivh patched-for-other-distro.src.rpm > > (rename the spec file so it won't get overwritten) > > rpm -ivh latest-for-your-distro.src.rpm > > > > At this point you'll have all the appropriate sources for the package on > > RH8, plus the patch that was provided by the other vendor (say RHEL). You > > can then copy the appropriate lines from the other spec file and build an > > RPM incorporating the patch. > > > > P.S. *Please* don't use quotation marks for emphasis. Those of us who went > > through writing programs in college cringe every time we see them misused > > that way. Quotation marks indicate precision (as in an exact quotation), > > titles, or, in informal writing, doubt or irony (as in so-called "scare > > quotes") - never emphasis. > > > > > > 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 Tue Jun 8 05:44:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 7 Jun 2004 22:44:56 -0700 Subject: Quick To-Do list Message-ID: <200406072244.59516.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As promised, here is a quick to-do list. I've looked at just about every bug tonight, and made a comment in this to-do of what needs to be done. Note, most the 'build for updates-testing' stuff is something that only I can do at this time. However, all the things with 'QA' in them the community can do. Please take a look over this and help out where you can. Cheers! To Do List: #775 -> Close when # gets pushed. #1174 -> Build/QA an apt for 7.2/8.0/9 #1237 -> Push RHEL2.1 Gaim for 7.3, use bug package for 9 #1257 -> Build new packages for QA for 7.3/9 #1269 -> Bug Seth Vidal about the status of this bug, push to updates-testing. #1289 -> Build/push 7.3 packages for updates-testing #1324 -> QA the packages in updates-testing, push to updates #1325 -> QA the packages in updates-testing, push to updates #1345 -> Build a yum against stock RHL8 rpm, push to legacy-utils #1371 -> QA the package in updates-testing, push to updates #1372 -> Rebuild package with patch from Michael Jaegermann, re-push to updates-testing #1373 -> Build kdelibs using patch for QA #1376 -> Rebuild wu-ftpd including pam-devel and other fixes, repush to updates-testing #1419 -> Build Marc Deslauriers' packages for 7.3/9 and push to updates-testing #1468 -> Build/Push packages to updates-testing #1484 -> Build/push packages to updates-testing #1532 -> Build 7.3 packages and push to updates-testing #1547 -> Build 7.3 packages and push to updates-testing #1548 -> Build 7.3 packages and push to updates-testing #1549 -> Build 7.3 packages and push to updates-testing #1550 -> rebuild 7.3 (9?) packages using libpng-1.0.12-transfix.patch for QA #1552 -> build 7.3/9 packages and push to updates-testing #1553 -> Build 7.3/9 packages and push to updates-testing #1569 -> QA the package in updates-testing, push to updates #1581 -> Build 7.3/9 packages and push to updates-testing #1604 -> Fix issues w/ yum for 9, put up for QA #1614 -> Try to duplicate out in the world... #1652 -> Edit FAQ a bit to clarify 1-2-3 policy. #1693 -> Edit webpage once official yum/apt for RHL8 becomes available #1708 -> Double check that 1702 and 1708 are the same issues, built 7.3/9 packages for updates-testing #1719 -> QA 7.3 packages, build 7.3/9 packages for updates-testing #1726 -> QA 7.3 packages, build 7.3/9 packages for updates-testing #1728 -> Build 7.3/9 packages for QA - - Figure out an official statement as to why 7.2/8.0 packages are not showing up - - Remove 'rpm' upgrade from legacy-utils on RHL8 - - Rebuild legacy-utils for RHL8 against stock RPM in RHL8 - - Go through website and make adjustments accordingly for lack of 7.2/8.0 support, and addition of 9 support. Mark pages that will need to be updated for FC1 support when we take it over - - Modify python script I have to generate our updates-testing and updates announcements. Will need some nifty python tricks to discover what all rpms are built from an srpm, and which all releases to lookf or srpms in. Need to whiteboard on this one a bit - - Process mirror requests and fixes - - Persue Vendor-sec with Red Hat Security Responce Team - - Figure out a way to automate build/sign/upload of packages, using mach to build - -- 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) iD8DBQFAxVJb4v2HLvE71NURAoEdAJ0UZSmztQpVlEK4HiTB26yjIsGT9ACgxYnm e1QHb8QfS3RVONasSj6l8QA= =kvmX -----END PGP SIGNATURE----- From mkratz at internode.com.au Tue Jun 8 10:00:33 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Tue, 8 Jun 2004 19:30:33 +0930 Subject: Redhat 8 to 9 Message-ID: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> I've got a redhat 8 server, and out of interest I configured yum to use the redhat 9 repositories, then toyed with yum update (i.e. apache, sendmail, etc) what is interesting is that with some of these theres very few dependencies to do the upgrade. (i.e. dependency for sendmail was tcpwrappers, and thats it) My question is, is this a bad thing to do, and would it really break anything by upgrading some things to the Redhat 9 versions? -- michael From bvermeul at blackstar.nl Tue Jun 8 10:08:06 2004 From: bvermeul at blackstar.nl (Bas Vermeulen) Date: Tue, 08 Jun 2004 12:08:06 +0200 Subject: Redhat 8 to 9 In-Reply-To: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> Message-ID: <1086689286.2308.25.camel@laptop.blackstar.nl> On Tue, 2004-06-08 at 12:00, Michael Kratz wrote: > I've got a redhat 8 server, and out of interest I configured yum to use the > redhat 9 repositories, then toyed with yum update > (i.e. apache, sendmail, etc) what is interesting is that with some of these > theres very few dependencies to do the upgrade. (i.e. dependency for > sendmail was tcpwrappers, and thats it) > > My question is, is this a bad thing to do, and would it really break > anything by upgrading some things to the Redhat 9 versions? Personally I've just upgraded my server with apt-get upgrade from RH 8 to RH 9. Works so far, with 0 downtime. Bas Vermeulen From marcdeslauriers at videotron.ca Tue Jun 8 12:11:51 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 08 Jun 2004 08:11:51 -0400 Subject: Quick To-Do list In-Reply-To: <200406072244.59516.jkeating@j2solutions.net> References: <200406072244.59516.jkeating@j2solutions.net> Message-ID: <1086696711.1565.0.camel@mdlinux> On Tue, 2004-06-08 at 01:44, Jesse Keating wrote: > #1728 -> Build 7.3/9 packages for QA This is a dupe of #1468. I marked accordingly in Bugzilla. Marc. From rostetter at mail.utexas.edu Tue Jun 8 16:57:45 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 8 Jun 2004 11:57:45 -0500 Subject: Redhat 8 to 9 In-Reply-To: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> Message-ID: <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> Quoting Michael Kratz : > I've got a redhat 8 server, and out of interest I configured yum to use the > redhat 9 repositories, then toyed with yum update If you are going to do that, you might as well just update the OS to RH 9 via yum/apt. > My question is, is this a bad thing to do, and would it really break > anything by upgrading some things to the Redhat 9 versions? Well, it will be hard to get support, or even dubug problems, when you mix packages. I'd suggest you try to stay, in general, with one or the other. But that is just a convenience/support/debugging issue. There's nothing inherently wrong with what you are doing. But if you want the newer packages, I'd just upgrade the OS. I did a RH 8.0 to RH 9 upgrade via apt-get the other day. Was painless, and only downtime was the reboot to load the new kernel in. Now I'm trying to decide what to do with my RH 7.2 machines (upgrade to RH 7.3, or upgrade to RH 9.0). > -- > michael -- Eric Rostetter From maillist at jasonlim.com Tue Jun 8 21:52:05 2004 From: maillist at jasonlim.com (Jason Lim) Date: Wed, 9 Jun 2004 05:52:05 +0800 Subject: Redhat 8 to 9 References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> Message-ID: <102801c44da2$e4d40f40$d600a8c0@tw1> > Now I'm trying to decide what to do with my RH 7.2 machines (upgrade to > RH 7.3, or upgrade to RH 9.0). I believe this will be a much more difficult upgrade, as many things will break in the upgrade due to the large version differences. We also have a bunch of 7.2 servers, but dread upgrading them so if at all possible we will stay within 7.2 updates as long as they are offered. Almost everyone still running 7.2 and 7.3 are servers owners/users, so everyone wants to avoid the problems associated with upgrade or making massive changes like that. I was wondering... is the project interested in having a lowly 800Mhz or 1Gb server with say 20-30Gb and anything from 128-512Mb RAM hosted? Reason is that we can provide a free server or two to the project to test packages or others if it may help keep 7.2 and 8.0 alive. Would this sponsorship help at all, or is it just a lost cause anyway to sponsor resources for this? From marcdeslauriers at videotron.ca Tue Jun 8 22:42:39 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 08 Jun 2004 18:42:39 -0400 Subject: Quick To-Do list In-Reply-To: <200406072244.59516.jkeating@j2solutions.net> References: <200406072244.59516.jkeating@j2solutions.net> Message-ID: <1086734559.1748.0.camel@mdlinux> On Tue, 2004-06-08 at 01:44, Jesse Keating wrote: > #1708 -> Double check that 1702 and 1708 are the same issues, built 7.3/9 > packages for updates-testing I just double-checked. They are the same issue. Marc. From J.S.Peatfield at damtp.cam.ac.uk Wed Jun 9 11:45:33 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Wed, 09 Jun 2004 12:45:33 +0100 Subject: RH 9 EOL Updates ISOs Message-ID: > I would be interested in these scripts too You can obtain rpmalert from: http://www.chiark.greenend.org.uk/~peterb/rpms/ You can also find other older versions in various places (google finds several), but that is the author's current version. Peter hasn't released rpmstream (or the old code I still use for repository maintenance, and install-tree building; which he also wrote), so I don't feel comfortable posting it. I'll check with him and see if he minds others seeing it yet... Since at least one other person mentioned the "redhad iso howto" the info in there is correct (as far as I remember), and the rh_buildtree code essentially does: rsync over the latest updates + local updates into local disk use rpmalert to get a list of updated versions, link into a union-directory containing all versions of all packages in the output tree run rpmalert to see what versions are newer in union for each of the new packages sig-check them and if they pass hard-link them into place. clean up the output tree to remove older versions/avoid duplicates etc (using rpmalert again) generate an rpmalert xref-file of the latest versions make the tree suitable for use as an (nfs) install tree as described in the rh iso howto: # pass 1 no order list (yet) genhdlist --hdlist RedHat/base/hdlist.new "$PWD" mv RedHat/base/hdlist.new RedHat/base/hdlist mv RedHat/base/hdlist.new2 RedHat/base/hdlist2 # make order file; depends on hdlist PYTHONPATH=/usr/lib/anaconda pkgorder . i386 > RedHat/base/orderlist # pass 2 uses order list genhdlist --fileorder RedHat/base/orderlist --hdlist RedHat/base/hdlist.new "$PWD" mv RedHat/base/hdlist.new RedHat/base/hdlist mv RedHat/base/hdlist.new2 RedHat/base/hdlist2 We don't bother with the other steps needed to make iso images since we always do network-installs. Apparently you have to be somewhat careful that you use the RH-X anaconda to make files which work properly with that version. Once you have an up-to-date tree you can probably make it into a yum/atp repository fairly easily too but I have no experience with those (yet). We use a script rpm-upgrade which is a wrapper round rpmalert and performs upgrades of those rpms which have been manually checked as ok (and don't clash with sets of "altered" files etc). It does checks on in-use shared-libs, setuid-file changing (we keep a tripwire-like database), etc. It has a nasty tendency to think that machines need rebooting to re-start running daemons etc even if they don't really -- with a bit more work that could probably be fixed up. Since I wrote that (hack though it is), I'll gladly post a pointer to it. I have a patch (not yet applied) which fixes rpm-update to check that packages which contain %config(noreplace) files which are listed in our "don't touch" list of files won't prevent the package being updated. In case anyone wants to read though the scripts and pick them to pieces they can be found at: http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/ which also has rpms/srpms for the "local" updates we apply to our RH80 machines. -- Jon From stuart at serverpeak.com Wed Jun 9 15:02:12 2004 From: stuart at serverpeak.com (Stuart Low) Date: Thu, 10 Jun 2004 01:02:12 +1000 Subject: PHP RPMS Message-ID: <1086793332.4067.4.camel@poohbox> Hi there, I'm not entirely sure if the Fedora Legacy project is interested in this, so forgive me if it's not welcome. However, I've released PHP 4.3.7 RPMs for RH7.3 & RH9 (and RH ES3, but that's unrelated to this list :)). These are RPMs built originally from Redhat's supplied php src.rpm with additional updates etc. applied. You can grab them from: http://www.seekbrain.com/downloads/psa/ There's also a yum repository available for those interested in keeping themselves up to date. Note that I've actually recompiled the latest MySQL there too (4.0.20) so you may wish to add an exclusion rule. Yum details here: http://www.seekbrain.com/archives/000056.html Anyways, enjoy. Stuart From RParr at TemporalArts.COM Wed Jun 9 16:23:26 2004 From: RParr at TemporalArts.COM (Randall J. Parr) Date: Wed, 09 Jun 2004 09:23:26 -0700 Subject: Redhat 8 to 9 In-Reply-To: <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> Message-ID: <40C7397E.3050701@TemporalArts.com> Eric Rostetter wrote: > If you are going to do that, you might as well just update the OS to RH 9 > via yum/apt. > > > But if you want the newer packages, I'd just upgrade the OS. I did a > RH 8.0 > to RH 9 upgrade via apt-get the other day. Was painless, and only > downtime > was the reboot to load the new kernel in. > Are there instructions are a how-to for upgrading from RH 8.0 to RH 9.0 using yum and/or apt-get? Any pointers and/or references would be greatly appreciated. I have been very leary of taking this course but would love to upgrade my systems this way. Thanks R.Parr, RHCE Temporal Arts Seattle From skvidal at phy.duke.edu Wed Jun 9 17:33:43 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Jun 2004 13:33:43 -0400 Subject: Redhat 8 to 9 In-Reply-To: <40C7397E.3050701@TemporalArts.com> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> Message-ID: <1086802423.23522.29.camel@binkley> On Wed, 2004-06-09 at 09:23 -0700, Randall J. Parr wrote: > Eric Rostetter wrote: > > > If you are going to do that, you might as well just update the OS to RH 9 > > via yum/apt. > > > > > > But if you want the newer packages, I'd just upgrade the OS. I did a > > RH 8.0 > > to RH 9 upgrade via apt-get the other day. Was painless, and only > > downtime > > was the reboot to load the new kernel in. > > > > Are there instructions are a how-to for upgrading from RH 8.0 to RH 9.0 > using yum and/or apt-get? > > Any pointers and/or references would be greatly appreciated. > > I have been very leary of taking this course but would love to upgrade > my systems this way. 8.0 to 9 shouldn't be much work. 1. install yum 2. make sure you have 1-2gb free in your yum cachedir 3. point to remote repositories for 9 4. run yum upgrade 5. sit back and see what happens. it all depends on how much third party stuff you have installed. -sv From rostetter at mail.utexas.edu Wed Jun 9 21:52:25 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 9 Jun 2004 16:52:25 -0500 Subject: Redhat 8 to 9 In-Reply-To: <40C7397E.3050701@TemporalArts.com> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> Message-ID: <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> Quoting "Randall J. Parr" : > Are there instructions are a how-to for upgrading from RH 8.0 to RH 9.0 > using yum and/or apt-get? No complete ones that I know of. But it is fairly easy to do with apt-get, and only has a few issues (like uninstalling apt-get as part of the upgrade!) > Any pointers and/or references would be greatly appreciated. I'll try to write up something when I find the time, but I'm still very busy and just have not had the time lately to do anything (including reply to people who have asked me personally for help on this type of upgrade). > I have been very leary of taking this course but would love to upgrade > my systems this way. In my limited experience, an RH 8.0 to RH 9 upgrade via apt-get works well, but isn't for the faint of heart. I've also done some other upgrades. My results are: RH 6.1 to RH 6.2 via apt-get Works really well, no problems. RH 6.2 to RH 7.x via apt-get Many problems that must be worked around. RH 7.2 to RH 7.3 via apt-get Works okay, only minor problems. RH 8.0 to RH 9 via apt-get Works well, except it uninstalls a few things including apt itself, which must be re-installed afterwards. All the above are apt (sic) to produce some spurious error messages during the upgrade, but nothing serious. The only difficult upgrade was the 6.x to 7.x, where a dist-upgrade fails because of dependencies. I ended up doing it in three steps (apt-get upgrade with new repo, manual install of glibc and dependencies, then an apt-get dist-upgrade of the new repo). So, in summary, I can recommend the 6.1 to 6.2 for anyone, 8.0 to 9 for those who are experienced admins, and would warn people that a 7.x system will require a lot of work... -- Eric Rostetter From fedoraleg_form at mm-vanecek.cc Wed Jun 9 23:29:17 2004 From: fedoraleg_form at mm-vanecek.cc (Mike Vanecek) Date: Wed, 9 Jun 2004 18:29:17 -0500 Subject: PHP RPMS In-Reply-To: <1086793332.4067.4.camel@poohbox> References: <1086793332.4067.4.camel@poohbox> Message-ID: <20040609232651.M92429@mm-vanecek.cc> On Thu, 10 Jun 2004 01:02:12 +1000, Stuart Low wrote > Hi there, > > I'm not entirely sure if the Fedora Legacy project is interested in > this, so forgive me if it's not welcome. However, I've released PHP > 4.3.7 RPMs for RH7.3 & RH9 (and RH ES3, but that's unrelated to this > list :)). These are RPMs built originally from Redhat's supplied php > src.rpm with additional updates etc. applied. > > You can grab them from: http://www.seekbrain.com/downloads/psa/ I got the source from that page, but ... $ rpmbuild --rebuild php-4.3.7-sp.rh9.1.src.rpm Installing php-4.3.7-sp.rh9.1.src.rpm error: Failed build dependencies: bzip2-devel is needed by php-4.3.7-sp.rh9.1 aspell-devel is needed by php-4.3.7-sp.rh9.1 imap-devel is needed by php-4.3.7-sp.rh9.1 postgresql-devel is needed by php-4.3.7-sp.rh9.1 unixODBC-devel is needed by php-4.3.7-sp.rh9.1 sablotron is needed by php-4.3.7-sp.rh9.1 sablotron-devel is needed by php-4.3.7-sp.rh9.1 js is needed by php-4.3.7-sp.rh9.1 js-devel is needed by php-4.3.7-sp.rh9.1 mhash is needed by php-4.3.7-sp.rh9.1 mhash-devel is needed by php-4.3.7-sp.rh9.1 libmcrypt is needed by php-4.3.7-sp.rh9.1 libmcrypt-devel is needed by php-4.3.7-sp.rh9.1 net-snmp-devel is needed by php-4.3.7-sp.rh9.1 Have not tried the binary, but suspect I will also have dependency issues? From jkeating at j2solutions.net Wed Jun 9 23:53:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 9 Jun 2004 16:53:58 -0700 Subject: PHP RPMS In-Reply-To: <20040609232651.M92429@mm-vanecek.cc> References: <1086793332.4067.4.camel@poohbox> <20040609232651.M92429@mm-vanecek.cc> Message-ID: <200406091653.58453.jkeating@j2solutions.net> On Wednesday 09 June 2004 16:29, Mike Vanecek wrote: > Have not tried the binary, but suspect I will also have dependency > issues? Not nearly as bad. You'll note that almost all are -devel packages, which are most often ONLY needed to rebuild a package, not to run the package. Try again with the binary package and see what deps you get. -- 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 ral77 at bellsouth.net Thu Jun 10 02:35:11 2004 From: ral77 at bellsouth.net (ral77) Date: Wed, 09 Jun 2004 22:35:11 -0400 Subject: Redhat 8 to 9 In-Reply-To: <1086689286.2308.25.camel@laptop.blackstar.nl> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <1086689286.2308.25.camel@laptop.blackstar.nl> Message-ID: <40C7C8DF.7000005@bellsouth.net> Bas Vermeulen wrote: >On Tue, 2004-06-08 at 12:00, Michael Kratz wrote: > > >>I've got a redhat 8 server, and out of interest I configured yum to use the >>redhat 9 repositories, then toyed with yum update >>(i.e. apache, sendmail, etc) what is interesting is that with some of these >>theres very few dependencies to do the upgrade. (i.e. dependency for >>sendmail was tcpwrappers, and thats it) >> >>My question is, is this a bad thing to do, and would it really break >>anything by upgrading some things to the Redhat 9 versions? >> >> > >Personally I've just upgraded my server with apt-get upgrade from RH 8 >to RH 9. Works so far, with 0 downtime. > >Bas Vermeulen > > > > > At the monthly LUG hackfest I was talking to a couple people about upgrading redhat 8 --> rh9 and it was mentioned to boot the rh8 system with the redhat 9 install cd #1 and select upgrade anybody see any pitfalls in this method versus apt-get or yum. I do have physical access to the redhat 8 server. thx's From mkratz at internode.com.au Thu Jun 10 02:40:57 2004 From: mkratz at internode.com.au (Michael Kratz) Date: Thu, 10 Jun 2004 12:10:57 +0930 Subject: Redhat 8 to 9 References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au><20040608115745.6dag04gossw004sg@mail.ph.utexas.edu><40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> Message-ID: <00fc01c44e94$5c19d660$26e753c0@internode.com.au> > In my limited experience, an RH 8.0 to RH 9 upgrade via apt-get works well, > but isn't for the faint of heart. I've also done some other upgrades. My > results are: > > RH 6.1 to RH 6.2 via apt-get Works really well, no problems. > RH 6.2 to RH 7.x via apt-get Many problems that must be worked around. > RH 7.2 to RH 7.3 via apt-get Works okay, only minor problems. > RH 8.0 to RH 9 via apt-get Works well, except it uninstalls a few things > including apt itself, which must be > re-installed > afterwards. Anyone done a 7.1 to 7.3 upgrade? I'm wanting to do one of these also. Last night I decided to be a bit daring and started upgrading select packages on my RH 8 box to the RH 9 versions, I avoided crucial system stuff, and I haven't done all of them. The only one that broke out of all the ones I did was Squid. When I restarted squid it couldn't find the error files, it was looking in something like /usr/share/squid/errors/ when they were actually in /usr/share/squid/errors/English/ so I just moved them up a directory and squid was happy again. The only other thing I ran into was when I upgraded some stuff to do with RPM, and then I did a rpm --rebuilddb, after that YUM stopped working, so I tried upgrading it to the latest version 2 (instead of version 1) and that fixed that issue. About the only custom stuff I run on both my RH 8 box and my RH 7.1 box is Amavis with Sendmail. Some of the perl stuff for Amavis has been installed using CPAN not RPM's. This is the thing I am most concerned about breaking because it took me ages to get it working. -- Michael From rostetter at mail.utexas.edu Thu Jun 10 02:51:27 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 9 Jun 2004 21:51:27 -0500 Subject: Redhat 8 to 9 In-Reply-To: <40C7C8DF.7000005@bellsouth.net> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <1086689286.2308.25.camel@laptop.blackstar.nl> <40C7C8DF.7000005@bellsouth.net> Message-ID: <20040609215127.mqwlc8kc8osc0gw8@mail.ph.utexas.edu> Quoting ral77 : > At the monthly LUG hackfest I was talking to a couple people about > upgrading redhat 8 --> rh9 > and it was mentioned to boot the rh8 system with the redhat 9 install > cd #1 and select upgrade Yes, that is the proper and recommended way to do it. > anybody see any pitfalls in this method versus apt-get or yum. Downtime, and potential after upgrade exposure with an unpatched RH 9 machine if you don't have a good firewall or local update method. The *only* good reason to do it via apt or yum is to avoid downtime. If you can afford the downtime, you should upgrade from the CD, then install the needed patches in some secure method. > I do have physical access to the redhat 8 server. That certainly makes upgrading via the CD easier. If you can live with some downtime, use the CD. Only try apt/yum if you need to minimize the downtime (or just like experimenting ;) > thx's -- Eric Rostetter From rostetter at mail.utexas.edu Thu Jun 10 02:56:31 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 9 Jun 2004 21:56:31 -0500 Subject: Redhat 8 to 9 In-Reply-To: <00fc01c44e94$5c19d660$26e753c0@internode.com.au> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au><20040608115745.6dag04gossw004sg@mail.ph.utexas.edu><40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> Message-ID: <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> Quoting Michael Kratz : > Anyone done a 7.1 to 7.3 upgrade? I'm wanting to do one of these also. Yes, I did one. Based on the problems I had with it, the next machine did a 7.1 to 7.2 to 7.3 upgrade instead. ;) There were issues going from 7.1 to 7.3 directly. I got it to work, but it was easier, though more time consuming, to do the 7.1-7.2-7.3 sequence (no reboot for 7.2). > The only other thing I ran into was when I upgraded some stuff to do with > RPM, and then I did a rpm --rebuilddb, after that YUM stopped working, so I > tried upgrading it to the latest version 2 (instead of version 1) and that > fixed that issue. Very often I've had issues of apt and yum either uninstalling during an upgrade, or not working afterwards. > About the only custom stuff I run on both my RH 8 box and my RH 7.1 box is > Amavis with Sendmail. Some of the perl stuff for Amavis has been installed > using CPAN not RPM's. This is the thing I am most concerned about breaking > because it took me ages to get it working. Yes, sounds dangerous. I've also seen problems with python during upgrades since it at some point goes from python 1.5 to python 2.x. -- Eric Rostetter From skvidal at phy.duke.edu Thu Jun 10 03:06:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Jun 2004 23:06:48 -0400 Subject: Redhat 8 to 9 In-Reply-To: <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> Message-ID: <1086836808.27528.43.camel@binkley> On Wed, 2004-06-09 at 21:56 -0500, Eric Rostetter wrote: > Quoting Michael Kratz : > > > Anyone done a 7.1 to 7.3 upgrade? I'm wanting to do one of these also. > > Yes, I did one. Based on the problems I had with it, the next machine > did a 7.1 to 7.2 to 7.3 upgrade instead. ;) > > There were issues going from 7.1 to 7.3 directly. I got it to work, > but it was easier, though more time consuming, to do the 7.1-7.2-7.3 > sequence (no reboot for 7.2). > > > The only other thing I ran into was when I upgraded some stuff to do with > > RPM, and then I did a rpm --rebuilddb, after that YUM stopped working, so I > > tried upgrading it to the latest version 2 (instead of version 1) and that > > fixed that issue. > > Very often I've had issues of apt and yum either uninstalling during an > upgrade, or not working afterwards. > i'd be impressed if yum removed something that was not obsoleted during an upgrade. The code that follows out removal dep trees is never encountered during an upgrade request. -sv From rostetter at mail.utexas.edu Thu Jun 10 03:26:08 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 9 Jun 2004 22:26:08 -0500 Subject: Redhat 8 to 9 In-Reply-To: <1086836808.27528.43.camel@binkley> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> Message-ID: <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> Quoting seth vidal : >> Very often I've had issues of apt and yum either uninstalling during an >> upgrade, or not working afterwards. >> > > i'd be impressed if yum removed something that was not obsoleted during > an upgrade. The code that follows out removal dep trees is never > encountered during an upgrade request. That is why there is an "or" in there. For instance, if you upgrade RH 8.0 to RH 9 via apt-get using the FL test version of apt-get, it uninstalls apt during the upgrade! If you can get yum to upgrade to an rpmlib newer than that built into yum, then yum won't work afterwards... In other words, there are ways to cause problems with both programs if you try hard enough... Now, I've never had either one mess anything up without telling me that it would (or least might) do so first, and making me confirm the action after that warning was issued. So, it's up to the user to protect themself from themself. ;) > -sv -- Eric Rostetter From skvidal at phy.duke.edu Thu Jun 10 03:27:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Jun 2004 23:27:51 -0400 Subject: Redhat 8 to 9 In-Reply-To: <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> Message-ID: <1086838071.27528.47.camel@binkley> > That is why there is an "or" in there. For instance, if you upgrade RH 8.0 > to RH 9 via apt-get using the FL test version of apt-get, it uninstalls > apt during the upgrade! If you can get yum to upgrade to an rpmlib > newer than > that built into yum, then yum won't work afterwards... In other words, there > are ways to cause problems with both programs if you try hard enough... > ah, I must have misread. For upgrades from rhl8.0 to 9 I've found a two step process is easiest. 1. yum update rpm rpm-python yum (and a few other items) 2. yum upgrade -sv From pmatilai at welho.com Thu Jun 10 07:38:57 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 10 Jun 2004 10:38:57 +0300 (EEST) Subject: Redhat 8 to 9 In-Reply-To: <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> Message-ID: On Wed, 9 Jun 2004, Eric Rostetter wrote: > Quoting seth vidal : > > >> Very often I've had issues of apt and yum either uninstalling during an > >> upgrade, or not working afterwards. > >> > > > > i'd be impressed if yum removed something that was not obsoleted during > > an upgrade. The code that follows out removal dep trees is never > > encountered during an upgrade request. > > That is why there is an "or" in there. For instance, if you upgrade RH 8.0 > to RH 9 via apt-get using the FL test version of apt-get, it uninstalls > apt during the upgrade! Apt follows it's own extremely strict requirement of leaving no unsatisfied dependencies after any given operation to the point of self-termination. When doing dist-upgrades with apt you should always point it to all the target distro version's third party repositories you're using, not just the OS itself to avoid these things (and actually get a much smoother upgrade). Mm.. that's a bit unclear sentence perhaps, what I mean is that if you're using lets say RHL 9 with freshrpms and want to upgrade to FC1, you need to point apt to FC1 os component AND freshrpms built for FC1 before proceeding with the upgrade. - Panu - From pmatilai at welho.com Thu Jun 10 07:54:32 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 10 Jun 2004 10:54:32 +0300 (EEST) Subject: Redhat 8 to 9 In-Reply-To: <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> Message-ID: On Wed, 9 Jun 2004, Eric Rostetter wrote: > Quoting "Randall J. Parr" : > > > Are there instructions are a how-to for upgrading from RH 8.0 to RH 9.0 > > using yum and/or apt-get? > > No complete ones that I know of. But it is fairly easy to do with apt-get, > and only has a few issues (like uninstalling apt-get as part of the upgrade!) > > > Any pointers and/or references would be greatly appreciated. > > I'll try to write up something when I find the time, but I'm still very busy > and just have not had the time lately to do anything (including reply to > people who have asked me personally for help on this type of upgrade). > > > I have been very leary of taking this course but would love to upgrade > > my systems this way. > > In my limited experience, an RH 8.0 to RH 9 upgrade via apt-get works well, > but isn't for the faint of heart. I've also done some other upgrades. My > results are: > > RH 6.1 to RH 6.2 via apt-get Works really well, no problems. > RH 6.2 to RH 7.x via apt-get Many problems that must be worked around. > RH 7.2 to RH 7.3 via apt-get Works okay, only minor problems. > RH 8.0 to RH 9 via apt-get Works well, except it uninstalls a few things > including apt itself, which must be > re-installed > afterwards. > > All the above are apt (sic) to produce some spurious error messages during > the upgrade, but nothing serious. The only difficult upgrade was the 6.x > to 7.x, where a dist-upgrade fails because of dependencies. I ended up doing > it in three steps (apt-get upgrade with new repo, manual install of glibc > and dependencies, then an apt-get dist-upgrade of the new repo). There are couple of important things that make for a smooth apt-upgrade: - Use a version which uses rpmlib for the transaction processing. That makes all the worlds difference for the safety of the upgrade, you wont be left with a system without glibc that way. - Make it use rpm's ordering instead of it's own on any RH-oriented distribution: set 'RPM::Order "true";' in /etc/apt/apt.conf. Apt's internal ordering works more reliably for Conectiva but then they have different packaging standards... - Panu - From jjasen at realityfailure.org Thu Jun 10 11:14:52 2004 From: jjasen at realityfailure.org (John Jasen) Date: Thu, 10 Jun 2004 07:14:52 -0400 (EDT) Subject: Redhat 8 to 9 In-Reply-To: <00fc01c44e94$5c19d660$26e753c0@internode.com.au> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au><20040608115745.6dag04gossw004sg@mail.ph.utexas.edu><40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> Message-ID: On Thu, 10 Jun 2004, Michael Kratz wrote: > Anyone done a 7.1 to 7.3 upgrade? I'm wanting to do one of these also. I did it in the past using autoupdate (before I discovered the full power of apt-get!), and in a few areas it required either --force or --nodeps for a package or two. Otherwise, its perfectly possible to do live. -- -- 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 rostetter at mail.utexas.edu Thu Jun 10 17:44:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 10 Jun 2004 12:44:17 -0500 Subject: Redhat 8 to 9 In-Reply-To: References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> Message-ID: <20040610124417.8peaccckgg0s44cs@mail.ph.utexas.edu> Quoting Panu Matilainen : > There are couple of important things that make for a smooth apt-upgrade: > - Use a version which uses rpmlib for the transaction processing. That > makes all the worlds difference for the safety of the upgrade, you wont > be left with a system without glibc that way. It would simply refuse to upgrade for me because of glibc. So I had to upgrade glibc manually, then do the dist-upgrade. It in no way removed glibc from my system... > - Make it use rpm's ordering instead of it's own on any RH-oriented > distribution: set 'RPM::Order "true";' in /etc/apt/apt.conf. Apt's > internal ordering works more reliably for Conectiva but then they > have different packaging standards... Now that is interesting news to me. I'll have to check it out. BTW, I've done one real apt-get upgrade on a real server, and that is all I really plan to do. I really needed to mimimize downtime, and the apt-get upgrade worked and made my total downtime just a few minutes for the reboot (needed to get the newest kernel loaded after the upgrade of course). All the other apt-get upgrades I've done have been done more for curiousity/experimentation/etc. I don't recommend doing this kind of thing in general, but there are cases where it may be called for (like my one single server upgrade) due to downtime requirements, etc. I'd recommend not doing this until you test it on a test machine or two. Once you are comfortable on a test machine, then try it on your server. Don't make your server your test machine! > - Panu - -- Eric Rostetter From rostetter at mail.utexas.edu Thu Jun 10 17:50:40 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 10 Jun 2004 12:50:40 -0500 Subject: Redhat 8 to 9 In-Reply-To: References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> Message-ID: <20040610125040.nnc36s0kw0s04c00@mail.ph.utexas.edu> Quoting Panu Matilainen : > Apt follows it's own extremely strict requirement of leaving no > unsatisfied dependencies after any given operation to the point of > self-termination. Which is probably good. > When doing dist-upgrades with apt you should always > point it to all the target distro version's third party repositories > you're using, not just the OS itself to avoid these things (and actually > get a much smoother upgrade). I only use FL stuff. Problem was I was using the FL apt for 8.0 (testing, no release), and there is no RL apt for 9, so it had no chance... This is a big problem with FL right now (missing yum and apt packages for various OS versions) that I really wish was a higher priority than it seems to be. But that's life... > Mm.. that's a bit unclear sentence perhaps, > what I mean is that if you're using lets say RHL 9 with freshrpms and want > to upgrade to FC1, you need to point apt to FC1 os component AND freshrpms > built for FC1 before proceeding with the upgrade. It was clear the first time. My problem is lack of FL support for APT/YUM plain and simple. I appreciate the work done by you and others on getting apt and yum out for FL. Don't get me wrong, I *really* appreciate all your work. Unfortunately, more work needs to be done yet in this area. Since the "official" advise on the FL web site is to use apt or yum, we should make getting an apt/yum for each OS a high priority, IMHO. > - Panu - -- Eric Rostetter From jkeating at j2solutions.net Fri Jun 11 02:14:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 10 Jun 2004 19:14:53 -0700 Subject: Fedora Test Update Notification: cvs Message-ID: <200406101914.56940.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1735 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1735 2004-06-10 - --------------------------------------------------------------------- Name : cvs Version 7.3 : 1.11.1p1-16.legacy.2 Version 9 : 1.11.2-24.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: While investigating a previously fixed vulnerability, Derek Price discovered a flaw relating to malformed "Entry" lines which lead to a missing NULL terminator. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0414 to this issue. Stefan Esser and Sebastian Krahmer conducted an audit of CVS and fixed a number of issues that may have had security consequences. Among the issues deemed likely to be exploitable were: - -- a double-free relating to the error_prog_name string (CAN-2004-0416) - -- an argument integer overflow (CAN-2004-0417) - -- out-of-bounds writes in serv_notify (CAN-2004-0418). An attacker who has access to a CVS server may be able to execute arbitrary code under the UID on which the CVS server is executing. - --------------------------------------------------------------------- Changelog: 7.3: * Wed Jun 09 2004 Dave Botsch 1.11.1p1-16.legacy - - add patches from 2.1AS to fix CAN-2004-0416, 17, 18, 14 to legacy and - - bump release - - fix changelog order for May 25, 21 entries - - add texinfo as buildprereq * Fri May 28 2004 Nalin Dahyabhai 1.11.1p1-16 - - add security fix for CAN-2004-0416,CAN-2004-0417,CAN-2004-0418 (Stefan Esser) * Tue May 25 2004 Jesse Keating 1.11.1p1-14.legacy.3 - - Added tcsh as a buildprereq. 9: * Wed Jun 09 2004 Marc Deslauriers 1.11.2-24.legacy - - add security fix for CVE CAN-2004-0414 (Derek Price) - - add security fix for CAN-2004-0416,CAN-2004-0417,CAN-2004-0418 (Stefan Esser) - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ d309756c60dcf33235581f2174db39fe103bac27 7.3/updates-testing/SRPMS/cvs-1.11.1p1-16.legacy.2.src.rpm 9620756fc080096881f062b6272306a1ba57fb40 7.3/updates-testing/i386/cvs-1.11.1p1-16.legacy.2.i386.rpm ffa2ea4c2689dbbd304364a14517a0e9f1747be2 9/updates-testing/SRPMS/cvs-1.11.2-24.legacy.src.rpm 9f3eac397a31464cc39bad75877e6f5a11c7c31d 9/updates-testing/i386/cvs-1.11.2-24.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) iD8DBQFAyRWg4v2HLvE71NURAgq4AKCKgV2Xra/M6Te6f/FmAHpKr9H+DQCgwF2x om6x9Ixo1nAOI10oA9KMP+0= =lniu -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jun 11 02:20:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 10 Jun 2004 19:20:45 -0700 Subject: Fedora Test Update Notification: wu-ftpd Message-ID: <200406101920.45722.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-06-10 - --------------------------------------------------------------------- Name : wu-ftpd Version 7.3 : 2.6.2-15.7x.legacy 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. This build fixes a missing build requirement. - --------------------------------------------------------------------- Changelog: 7.3: * Fri Jun 04 2004 John Dalbec 2.6.2-15.7x.legacy - - Added pam-devel to buildreqs - - Added bugfix patch to reopen syslog after calling PAM - - Added bugfix patch to fix active-mode SSL data connections * 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/ 5b50aa3a91d8bb30aa860ac05ca7b2ea60f91c05 7.3/updates-testing/SRPMS/wu-ftpd-2.6.2-15.7x.legacy.src.rpm 6215a42cadf71683e87a4b7ffa54fd7b37d106a9 7.3/updates-testing/i386/wu-ftpd-2.6.2-15.7x.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) iD8DBQFAyRb94v2HLvE71NURAlGCAJ0R32vZVeIC0dbLvksP9VkL2RttYgCgidlw ge3hz5viWLaAXYCWrLJHYZg= =82lO -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jun 11 04:04:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 10 Jun 2004 21:04:22 -0700 Subject: Fedora Test Update Notification: ethereal Message-ID: <200406102104.22834.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1419 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1419 2004-06-10 - --------------------------------------------------------------------- Name : ethereal Version 7.3 : 0.10.3-0.73.2.legacy Version 9 : 0.10.3-0.90.3.legacy Summary : Network traffic analyzer Description : Ethereal is a network traffic analyzer for Unix-ish operating systems. This package lays base for libpcap, a packet capture and filtering library, contains command-line utilities, contains plugins and documentation for ethereal. A graphical user interface is packaged separately to GTK+ package. - --------------------------------------------------------------------- Update Information: Ethereal, an open-source network protocol analyzer, has been reported to be vulnerable to 13 buffer overflow conditions in multiple protocol parser functions. Version 0.10.3 is reportedly fixed and no longer vulnerable. - --------------------------------------------------------------------- Changelog: 7.3: * Thu Jun 10 2004 Jesse Keating 0.10.3-0.73.2.legacy - - Missing build-req of python * Fri Jun 04 2004 Marc Deslauriers 0.10.3-0.73.1.legacy - - Updated to version 0.10.3 - - Included backported security fixes from ethereal-0.10.4 * Wed Jan 07 2004 Christian Pearce 0.9.16-0.73.2.legacy - - Security fix CAN-2003-1012, CAN-2003-1013. 9: * Thu Jun 10 2004 Jesse Keating 0.10.3-0.90.3.legacy - - Added elfutils-devel and python as build-reqs. * Fri Jun 04 2004 Marc Deslauriers 0.10.3-0.90.2.legacy - - Included backported security fixes from ethereal-0.10.4 * Mon Mar 29 2004 Mark Cox 0.10.3-0.90.1 - - Updated to latest upstream version 0.10.3 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 8895ed56f2319fe44ae8a48ba9577f82bcf3491a 7.3/updates-testing/SRPMS/ethereal-0.10.3-0.73.2.legacy.src.rpm 1e020d735de16e1d1299dcd3c90541f37e2d2f4e 7.3/updates-testing/i386/ethereal-0.10.3-0.73.2.legacy.i386.rpm f4a4868c3450fa289d64c3e2d1099184525b38f1 7.3/updates-testing/i386/ethereal-gnome-0.10.3-0.73.2.legacy.i386.rpm 8182abd65f2e36bdc29c01b126a13df2945fe096 9/updates-testing/SRPMS/ethereal-0.10.3-0.90.3.legacy.src.rpm 8f24a03dbefc23c19eb43590f6e1e8ef2e17d417 9/updates-testing/i386/ethereal-0.10.3-0.90.3.legacy.i386.rpm 89bcb4a2b7dfd06f664c3e5795dceef6bcbf333f 9/updates-testing/i386/ethereal-gnome-0.10.3-0.90.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) iD8DBQFAyS9G4v2HLvE71NURAr3NAKCSgSLHRe4XQj8ctjCi44PS8ejICQCeP8Md amlrnlq/JyYjTW8XHK2Gybo= =fXgA -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jun 11 04:48:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 10 Jun 2004 21:48:12 -0700 Subject: Fedora Test Update Notification: tcpdump Message-ID: <200406102148.12755.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1468 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1468 2004-06-11 - --------------------------------------------------------------------- Name : tcpdump Version 7.3 : 3.6.3-17.7.3.6.legacy Version 9 : 3.7.2-7.9.3.legacy Summary : A network traffic monitoring tool. Description : Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. Install tcpdump if you need a program to monitor network traffic. - --------------------------------------------------------------------- Update Information: tcpdump 3.8.2 and previous have been identified as having packet decoding runtime overflow for ISAKMP packets. A hostile remote user could crash a running instance of tcpdump or execute arbitrary code. tcpdump 3.8.3 has been released to correct the problem. Ref: http://www.rapid7.com/advisories/R7-0017.html - --------------------------------------------------------------------- Changelog: 7.3: * Thu Jun 10 2004 Jesse Keating - - Added flex, byacc, autoconf as BuildReqs. * Sat May 29 2004 Marc Deslauriers 14:17.7.3.5.legacy - - CAN-2004-0183/0184 fixed 9: * Thu Jun 10 2004 Jesse Keating - - Added flex, byacc, autoconf as buildreqs. * Thu May 27 2004 Marc Deslauriers 14:3.7.2-7.9.2.legacy - - CAN-2004-0183/0184 fixed - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 3c236622c2f0815b257eb6df89470875844ab051 7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm 1d7866f944b95a9350098803c1be9a9439ef9de1 7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm 827884c667461dcd1624b666d29d83e50e4611cc 7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm 2e77a8344ce68a80fe484fae4e9e371b92dc25c2 7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm 2a63dfe8422c135d41ec0655d1957b2ac6e348a2 9/updates-testing/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa 9/updates-testing/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm 3e7aad82c73a3250828b05e1308eb63a43c0d35e 9/updates-testing/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm 39b28a5fc7bda074426736cfdbc6a2186979daa2 9/updates-testing/i386/tcpdump-3.7.2-7.9.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) iD8DBQFAyTmM4v2HLvE71NURAqUrAJwNqb2ajqP4aXU4ww9d5VPE+tal7gCfRSSq EgohXpvTMCIWzogEQo3VlFs= =EXCh -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jun 11 05:23:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 10 Jun 2004 22:23:13 -0700 Subject: Bug Sort List Message-ID: <200406102223.13070.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bugs needing QA to be fully released: 1324 1325 1371 1372 1376 1419 1468 1569 Bugs needing QA to go into updates-testing: 1719 1726 1550 1373 Bugs needing Packages to QA: 1174 1237 1257 1269 1604 1728 Bugs waiting on Jesse to build them for updates-testing: 1289 1325 1484 1532 1547 1548 1549 1552 1553 1581 1708 Misc Stuff: 1614 -> Duplicate? 1652 -> Edit FAQ 1693 -> Edit webpage - -- 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) iD8DBQFAyUHB4v2HLvE71NURAuW3AJ0WUvMQBM42n9uncRXTXumHhDma6ACdH1fI FJFJjyxMiELhL3rX04d7v4E= =WixV -----END PGP SIGNATURE----- From dom at earth.li Fri Jun 11 10:59:13 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 11 Jun 2004 11:59:13 +0100 Subject: Bug Sort List In-Reply-To: <200406102223.13070.jkeating@j2solutions.net> References: <200406102223.13070.jkeating@j2solutions.net> Message-ID: <20040611105913.GS11946@tirian.magd.ox.ac.uk> On Thu, Jun 10, 2004 at 10:23:13PM -0700, Jesse Keating wrote: [a bug todo list] I wonder. Could this be put on the wiki instead, and then mailed out regularly? This would make it easier to navigate straight to the bugzilla bugs in question by hyperlinking and would let people help to update the todo list rapidly. Cheers, Dominic. From pmatilai at welho.com Fri Jun 11 12:58:13 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 11 Jun 2004 15:58:13 +0300 (EEST) Subject: Redhat 8 to 9 In-Reply-To: <20040610124417.8peaccckgg0s44cs@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <20040610124417.8peaccckgg0s44cs@mail.ph.utexas.edu> Message-ID: On Thu, 10 Jun 2004, Eric Rostetter wrote: > Quoting Panu Matilainen : > > > There are couple of important things that make for a smooth apt-upgrade: > > - Use a version which uses rpmlib for the transaction processing. That > > makes all the worlds difference for the safety of the upgrade, you wont > > be left with a system without glibc that way. > > It would simply refuse to upgrade for me because of glibc. So I had to > upgrade glibc manually, then do the dist-upgrade. It in no way removed > glibc from my system... That sounds REALLY weird.. but ok I've seen some weird stuff happen with older apt versions. The "remove glibc" is one of those "seen freaky things happen" with old apt-versions because they did rpm -e rpm -Uvh which could result in really nasty mess if the rpm -Uvh step happened to have for example file conflicts and abort. Hence the *heavy* recommendation of using a version of apt which uses rpmlib for transaction processing where things like that can not happen. > > > - Make it use rpm's ordering instead of it's own on any RH-oriented > > distribution: set 'RPM::Order "true";' in /etc/apt/apt.conf. Apt's > > internal ordering works more reliably for Conectiva but then they > > have different packaging standards... > > Now that is interesting news to me. I'll have to check it out. Doesn't make much of a difference for most dist-upgrades but for example FC1 -> FC2 upgrade is an utter disaster with apt's own ordering (that's how I found out apt's again using it's own ordering, my original rpmlib support used rpm ordering because of this) > > BTW, I've done one real apt-get upgrade on a real server, and that is all > I really plan to do. I really needed to mimimize downtime, and the apt-get > upgrade worked and made my total downtime just a few minutes for the reboot > (needed to get the newest kernel loaded after the upgrade of course). > > All the other apt-get upgrades I've done have been done more for > curiousity/experimentation/etc. I don't recommend doing this kind of > thing in general, but there are cases where it may be called for (like my > one single server upgrade) due to downtime requirements, etc. I've had to *support* doing upgrades for years now because our laptop users have encrypted disks, root and all so anaconda wont do... Been "fun" an times :) > > I'd recommend not doing this until you test it on a test machine or two. > Once you are comfortable on a test machine, then try it on your server. > Don't make your server your test machine! Yep. It's generally quite safe to do, or lets say not really any unsafer than upgrading with anaconda for any given RHL (upgrade to FC2 is another issue) but it's certainly a good idea to try it out on a similar-to-production test system for the first times. - Panu - From pmatilai at welho.com Fri Jun 11 13:16:49 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 11 Jun 2004 16:16:49 +0300 (EEST) Subject: Redhat 8 to 9 In-Reply-To: <20040610125040.nnc36s0kw0s04c00@mail.ph.utexas.edu> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> <20040610125040.nnc36s0kw0s04c00@mail.ph.utexas.edu> Message-ID: On Thu, 10 Jun 2004, Eric Rostetter wrote: > Quoting Panu Matilainen : > > > Apt follows it's own extremely strict requirement of leaving no > > unsatisfied dependencies after any given operation to the point of > > self-termination. > > Which is probably good. > > > When doing dist-upgrades with apt you should always > > point it to all the target distro version's third party repositories > > you're using, not just the OS itself to avoid these things (and actually > > get a much smoother upgrade). > > I only use FL stuff. Problem was I was using the FL apt for 8.0 (testing, > no release), and there is no RL apt for 9, so it had no chance... This > is a big problem with FL right now (missing yum and apt packages for > various OS versions) that I really wish was a higher priority than it seems > to be. But that's life... Ok - that's obviously a problem without a solution currently :( > > > Mm.. that's a bit unclear sentence perhaps, > > what I mean is that if you're using lets say RHL 9 with freshrpms and want > > to upgrade to FC1, you need to point apt to FC1 os component AND freshrpms > > built for FC1 before proceeding with the upgrade. > > It was clear the first time. My problem is lack of FL support for APT/YUM > plain and simple. I appreciate the work done by you and others on getting > apt and yum out for FL. Don't get me wrong, I *really* appreciate all your > work. Unfortunately, more work needs to be done yet in this area. > > Since the "official" advise on the FL web site is to use apt or yum, we > should make getting an apt/yum for each OS a high priority, IMHO. Indeed. I've been watching the FL apt package being stuck in QA for a long, long time for no particularly good reason and Jason has probably gotten totally fed up with the situation. I personally dont unfortunately have time or resources to test and verify on old RHL versions, but as far as I can tell by just looking at the package in QA it's perfectly ready for publishing. It might not be perfect but it still beats the hell out of telling people to use apt from freshrpms or so because all the other packagings of apt lack a significant amount of functionality compared to the fedora.us/fedoralegacy version. Or to cut it short: publish the damn apt package in QA, there's nothing terribly wrong with it. You can always publish update to it later (news at eleven, bugs are found and new version gets released) - Panu - From jkeating at j2solutions.net Fri Jun 11 14:16:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 11 Jun 2004 07:16:16 -0700 Subject: Bug Sort List In-Reply-To: <20040611105913.GS11946@tirian.magd.ox.ac.uk> References: <200406102223.13070.jkeating@j2solutions.net> <20040611105913.GS11946@tirian.magd.ox.ac.uk> Message-ID: <200406110716.16314.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 11 June 2004 03:59, Dominic Hargreaves wrote: > I wonder. Could this be put on the wiki instead, and then mailed out > regularly? This would make it easier to navigate straight to the > bugzilla bugs in question by hyperlinking and would let people help to > update the todo list rapidly. > > Cheers, If somebody wants to take my list and do this, thats fine. However it takes long enough to dig through the lengthy bug list to generate just a simple list like this. The more complicated you make it for me, the longer it'll take, and the more time is taken away from building packages. - -- 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) iD8DBQFAyb6w4v2HLvE71NURAhUeAKC52WckFaH0kTnd4kip8WFO9wsaCACgvS8p ZFZ6i8wVkz4Xo9yoQHqbKDo= =auku -----END PGP SIGNATURE----- From mattdm at mattdm.org Fri Jun 11 14:25:12 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 11 Jun 2004 10:25:12 -0400 Subject: Bug Sort List In-Reply-To: <20040611105913.GS11946@tirian.magd.ox.ac.uk> References: <200406102223.13070.jkeating@j2solutions.net> <20040611105913.GS11946@tirian.magd.ox.ac.uk> Message-ID: <20040611142512.GA8267@jadzia.bu.edu> On Fri, Jun 11, 2004 at 11:59:13AM +0100, Dominic Hargreaves wrote: > I wonder. Could this be put on the wiki instead, and then mailed out > regularly? This would make it easier to navigate straight to the > bugzilla bugs in question by hyperlinking and would let people help to > update the todo list rapidly. It could also be done via bugzilla itself -- keywords or various states, and then a dynamic search to bring on the current list. Who runs the fedora.us server? I made an offer a while ago of help creating actual components for each package in RHL, which would make bugzilla work much more smoothly, but I got no response.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dom at earth.li Fri Jun 11 15:07:00 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 11 Jun 2004 16:07:00 +0100 Subject: Bug Sort List In-Reply-To: <20040611142512.GA8267@jadzia.bu.edu> References: <200406102223.13070.jkeating@j2solutions.net> <20040611105913.GS11946@tirian.magd.ox.ac.uk> <20040611142512.GA8267@jadzia.bu.edu> Message-ID: <20040611150700.GX11946@tirian.magd.ox.ac.uk> On Fri, Jun 11, 2004 at 10:25:12AM -0400, Matthew Miller wrote: > It could also be done via bugzilla itself -- keywords or various states, and > then a dynamic search to bring on the current list. > > Who runs the fedora.us server? I made an offer a while ago of help creating > actual components for each package in RHL, which would make bugzilla work > much more smoothly, but I got no response.... I've gone through and added a bunch of keywords to some packages, and also made this: All we need to complete the contents of Jesse's excellent email report are the following keywords to be added to the bugzilla system: legacy-testing (to indicate that updates-testing packages have been built) Can we get this done? Cheers, Dominic. From rostetter at mail.utexas.edu Fri Jun 11 17:30:34 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 11 Jun 2004 12:30:34 -0500 Subject: Redhat 8 to 9 In-Reply-To: References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <20040608115745.6dag04gossw004sg@mail.ph.utexas.edu> <40C7397E.3050701@TemporalArts.com> <20040609165225.3wvackww0go8wckc@mail.ph.utexas.edu> <00fc01c44e94$5c19d660$26e753c0@internode.com.au> <20040609215631.pae4g0ok8wo8o4w8@mail.ph.utexas.edu> <1086836808.27528.43.camel@binkley> <20040609222608.y1udc0gg8kocsgkc@mail.ph.utexas.edu> <20040610125040.nnc36s0kw0s04c00@mail.ph.utexas.edu> Message-ID: <20040611123034.lskg8gggg8sws00c@mail.ph.utexas.edu> Quoting Panu Matilainen : >> Since the "official" advise on the FL web site is to use apt or yum, we >> should make getting an apt/yum for each OS a high priority, IMHO. > > Indeed. I've been watching the FL apt package being stuck in QA for a > long, long time for no particularly good reason and Jason has probably > gotten totally fed up with the situation. I QA'd the RH 8.0 apt twice, and had no major problems. It was hung up for some strange reasons (we don't want to release it now because we want to improve it) which shouldn't hold it up IMHO (just publish an updated version later instead). > I personally dont unfortunately > have time or resources to test and verify on old RHL versions, but as far > as I can tell by just looking at the package in QA it's perfectly ready > for publishing. I've QA'd it, but to no avail. > It might not be perfect but it still beats the hell out of > telling people to use apt from freshrpms or so because all the other > packagings of apt lack a significant amount of functionality compared to > the fedora.us/fedoralegacy version. I agree. > Or to cut it short: publish the damn apt package in QA, there's nothing > terribly wrong with it. You can always publish update to it later (news at > eleven, bugs are found and new version gets released) I Agree. But I guess FL seems poised to kill RH 8.0 so it doesn't matter for that one. Unless we can change Jesse's mind on killing off RH 8.0. > - Panu - -- Eric Rostetter From mattdm at mattdm.org Fri Jun 11 18:10:16 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 11 Jun 2004 14:10:16 -0400 Subject: Bug Sort List In-Reply-To: <20040611150700.GX11946@tirian.magd.ox.ac.uk> References: <200406102223.13070.jkeating@j2solutions.net> <20040611105913.GS11946@tirian.magd.ox.ac.uk> <20040611142512.GA8267@jadzia.bu.edu> <20040611150700.GX11946@tirian.magd.ox.ac.uk> Message-ID: <20040611181016.GA15724@jadzia.bu.edu> On Fri, Jun 11, 2004 at 04:07:00PM +0100, Dominic Hargreaves wrote: > All we need to complete the contents of Jesse's excellent email report > are the following keywords to be added to the bugzilla system: It'd also be super-super-nice to have component = src package.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From brian.t.brunner at gai-tronics.com Fri Jun 11 18:06:20 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Fri, 11 Jun 2004 14:06:20 -0400 Subject: Redhat 8 to 9 Message-ID: This is easy: commit to do the work of supporting 8.0, and then do it. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> rostetter at mail.utexas.edu 06/11/04 01:30PM >>> Unless we can change Jesse's mind on killing off RH 8.0. ******************************************************************* 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 ral77 at bellsouth.net Fri Jun 11 19:41:03 2004 From: ral77 at bellsouth.net (ral77) Date: Fri, 11 Jun 2004 15:41:03 -0400 Subject: Redhat 8 to 9 In-Reply-To: <40C7C8DF.7000005@bellsouth.net> References: <004d01c44d3f$73cfe7a0$6501a8c0@internode.com.au> <1086689286.2308.25.camel@laptop.blackstar.nl> <40C7C8DF.7000005@bellsouth.net> Message-ID: <40CA0ACF.7090509@bellsouth.net> ral77 wrote: > Bas Vermeulen wrote: > >> On Tue, 2004-06-08 at 12:00, Michael Kratz wrote: >> >> >>> I've got a redhat 8 server, and out of interest I configured yum to >>> use the >>> redhat 9 repositories, then toyed with yum update >> package> >>> (i.e. apache, sendmail, etc) what is interesting is that with some >>> of these >>> theres very few dependencies to do the upgrade. (i.e. dependency for >>> sendmail was tcpwrappers, and thats it) >>> >>> My question is, is this a bad thing to do, and would it really break >>> anything by upgrading some things to the Redhat 9 versions? >>> >> >> >> Personally I've just upgraded my server with apt-get upgrade from RH 8 >> to RH 9. Works so far, with 0 downtime. >> >> Bas Vermeulen >> >> >> >> >> > At the monthly LUG hackfest I was talking to a couple people about > upgrading redhat 8 --> rh9 > and it was mentioned to boot the rh8 system with the redhat 9 install > cd #1 and select upgrade anybody see any pitfalls in this method > versus apt-get or yum. I do have physical access to the redhat 8 server. > > thx's > > > > A follow-up on my successful rh8 --> rh9 upgrade. The server is behind a firewall and I am the only user , primary services are samba and nfs, and 3rd party apps mplayer, gkrellm, fluxbox. 1) Booted from cdrom with cd#1 redhat 9 install and selected the upgrade option. (about 48 minutes , used the 3 install cd's) 2) Downloaded from rhn the current rh9 kernel 2.4.20-31.9.i686.rpm rpm -ivh 2.4.20-31.9.i686.rpm and edited /boot/grub/grub.conf [default=0] rebooted 3) Installed yum for rh9 and updated the packages ( I have a /var partition with 600Meg available and yum cached about 380 Meg of updated packages) rebooted 4) rpm -e the rh8 gkrellm and the plugins and reinstalled the 2.1.21 version and plugins. Fixed some entries in the /etc/tripwire/twpol.txt and updated the policy file. Tested samba, fluxbox and mplayer okay as well as the /nfs mounts fine. Best regards, From john.l.villalovos at intel.com Mon Jun 14 17:06:36 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Mon, 14 Jun 2004 10:06:36 -0700 Subject: New Kernel Crash-Exploit discovered Message-ID: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410> Not sure if people have seen this. I'm assuming that a patch will need to be figured out and done. Requires local user shell access. Mentioned on Slashdot today: http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html John From davej at redhat.com Mon Jun 14 17:10:17 2004 From: davej at redhat.com (Dave Jones) Date: Mon, 14 Jun 2004 18:10:17 +0100 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410> References: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410> Message-ID: <20040614171017.GN8779@redhat.com> On Mon, Jun 14, 2004 at 10:06:36AM -0700, Villalovos, John L wrote: > Not sure if people have seen this. I'm assuming that a patch will need > to be figured out and done. > > Requires local user shell access. > > Mentioned on Slashdot today: > > http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html For those interested, here's what I rolled into the FC1 update. Might even apply to the old RHL tree, but haven't tried. Dave --- linux-2.4.22/include/asm-x86_64/i387.h~ 2004-06-14 15:36:18.816344576 +0100 +++ linux-2.4.22/include/asm-x86_64/i387.h 2004-06-14 15:36:36.426667400 +0100 @@ -34,7 +34,7 @@ #define clear_fpu( tsk ) do { \ if ( tsk->flags & PF_USEDFPU ) { \ - asm volatile("fwait"); \ + asm volatile("fnclex ; fwait"); \ tsk->flags &= ~PF_USEDFPU; \ stts(); \ } \ --- linux-2.4.22/include/asm-i386/i387.h~ 2004-06-14 15:36:40.427059248 +0100 +++ linux-2.4.22/include/asm-i386/i387.h 2004-06-14 15:36:53.369091760 +0100 @@ -34,7 +34,7 @@ #define clear_fpu( tsk ) do { \ if ( tsk->flags & PF_USEDFPU ) { \ - asm volatile("fwait"); \ + asm volatile("fnclex ; fwait"); \ tsk->flags &= ~PF_USEDFPU; \ stts(); \ } \ From jkeating at j2solutions.net Mon Jun 14 17:18:25 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 14 Jun 2004 10:18:25 -0700 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040614171017.GN8779@redhat.com> References: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410> <20040614171017.GN8779@redhat.com> Message-ID: <200406141018.31621.jkeating@j2solutions.net> On Monday 14 June 2004 10:10, Dave Jones wrote: > For those interested, here's what I rolled into the FC1 update. > Might even apply to the old RHL tree, but haven't tried. Thanks Dave! Even if these don't directly apply it does give us an idea as to what needs to change. As always you're a great help! -- 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 Mon Jun 14 17:33:48 2004 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 14 Jun 2004 11:33:48 -0600 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410>; from john.l.villalovos@intel.com on Mon, Jun 14, 2004 at 10:06:36AM -0700 References: <60C14C611F1DDD4198D53F2F43D8CA3B0106665A@orsmsx410> Message-ID: <20040614113348.A28002@mail.harddata.com> On Mon, Jun 14, 2004 at 10:06:36AM -0700, Villalovos, John L wrote: > Not sure if people have seen this. Most likely. If you want to get technical that is neither an exploit or crash but you can throw 2.4 and 2.6 kernels into an infinite FPU exception loop on x86 and x86_64 architectures. Bad enough, obviously, but "local" and denial-of-service and not a security risk. LARTing should be pretty effective as a short term paliative if you will run into lusers having a questionable fun. > I'm assuming that a patch will need > to be figured out and done. Last time I looked there was not yet a clear agreement how to fix that without causing other undesirable side effects. Anyway, this should do the job (nearly always?) so you can patch what you run currently if you are in a hurry. This is x86 for now and for 2.4.x this will be similar. Signed-Off-By: Sergey Vlasov --- linux-2.6.6/include/asm-i386/i387.h.fp-lockup 2004-05-10 06:33:06 +0400 +++ linux-2.6.6/include/asm-i386/i387.h 2004-06-12 22:02:58 +0400 @@ -48,10 +48,17 @@ save_init_fpu( tsk ); \ } while (0) +/* + * There might be some pending exceptions in the FP state at this point. + * However, it is too late to report them: this code is called during execve() + * (when the original executable is already gone) and during sigreturn() (when + * the signal handler context is already lost). So just clear them to prevent + * problems later. + */ #define __clear_fpu( tsk ) \ do { \ if ((tsk)->thread_info->status & TS_USEDFPU) { \ - asm volatile("fwait"); \ + asm volatile("fnclex"); \ (tsk)->thread_info->status &= ~TS_USEDFPU; \ stts(); \ } \ Michal From euckew at sierraelectronics.com Mon Jun 14 18:14:15 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Mon, 14 Jun 2004 11:14:15 -0700 Subject: A question on apt-get relative to kernel versions Message-ID: <00c601c4523b$673b63b0$3f01a8c0@Eucke> Hello all! Perhaps I missed something in what and how apt-get updates but my test machine is still booting to 2.4.20-8. Isn't the latest available for RH9 somewhere around 2.4.20-31x or something? Does apt-get avoid kernel updates or does the fedoralegacy mirrors not include a newer kernel? BTW, the instructions for apt-get for RH9 work like a charm! Thanks all. I'd love to help in the FL project but my credentials and abilities are limited. I do have the ability via VMWARE to test stuff...so I offer that if I can help... -Eucke -------------- next part -------------- An HTML attachment was scrubbed... URL: From joey at clean.q7.com Tue Jun 15 01:40:04 2004 From: joey at clean.q7.com (Joe Pruett) Date: Mon, 14 Jun 2004 18:40:04 -0700 (PDT) Subject: A question on apt-get relative to kernel versions In-Reply-To: <00c601c4523b$673b63b0$3f01a8c0@Eucke> Message-ID: yep, apt-get from fedora.us won't upgrade the kernel. you should do: apt-get install kernel#2.4.20-31.9 or kernel-smp, kernel-bigmem, etc. it won't make the new kernel the default either. edit your boot loader config files to make that happen. From mattdm at mattdm.org Tue Jun 15 02:00:34 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 14 Jun 2004 22:00:34 -0400 Subject: A question on apt-get relative to kernel versions In-Reply-To: References: <00c601c4523b$673b63b0$3f01a8c0@Eucke> Message-ID: <20040615020034.GA22434@jadzia.bu.edu> On Mon, Jun 14, 2004 at 06:40:04PM -0700, Joe Pruett wrote: > yep, apt-get from fedora.us won't upgrade the kernel. you should do: > apt-get install kernel#2.4.20-31.9 > or kernel-smp, kernel-bigmem, etc. it won't make the new kernel the > default either. edit your boot loader config files to make that happen. And if you're brave, hook in the "upgradevirt.lua" script -- I've been doing it for a while, with no ill effects. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From simon at nzservers.com Tue Jun 15 14:36:53 2004 From: simon at nzservers.com (Simon Weller) Date: Tue, 15 Jun 2004 09:36:53 -0500 Subject: New Kernel Crash-Exploit discovered Message-ID: <200406150936.53692.simon@nzservers.com> >On Mon, Jun 14, 2004 at 10:06:36AM -0700, Villalovos, John L wrote: > Not sure if people have seen this. > >Most likely. If you want to get technical that is neither an >exploit or crash but you can throw 2.4 and 2.6 kernels into an >infinite FPU exception loop on x86 and x86_64 architectures. Bad >enough, obviously, but "local" and denial-of-service and not a >security risk. LARTing should be pretty effective as a short term >paliative if you will run into lusers having a questionable fun. > > I'm assuming that a patch will need > to be figured out and done. > >Last time I looked there was not yet a clear agreement how to fix >that without causing other undesirable side effects. Anyway, this >should do the job (nearly always?) so you can patch what you run >currently if you are in a hurry. This is x86 for now and for 2.4.x >this will be similar. Linus appears to have now approved a patch: http://linux.bkbits.net:8080/linux-2.4/gnupatch%4040cdf6f8V7sOe5n96HA5Q7r9uDRvJQ It's supposedly compatible with 2.4.2x This is the same patch as posted by Dave Jones, but just the x86 patch. - Si > > >Signed-Off-By: Sergey Vlasov > >--- linux-2.6.6/include/asm-i386/i387.h.fp-lockup 2004-05-10 06:33:06 >+0400 >+++ linux-2.6.6/include/asm-i386/i387.h 2004-06-12 22:02:58 +0400 >@@ -48,10 +48,17 @@ > save_init_fpu( tsk ); \ > } while (0) > >+/* >+ * There might be some pending exceptions in the FP state at this point. >+ * However, it is too late to report them: this code is called >during .execve() >+ * (when the original executable is already gone) and during sigreturn() >(when >+ * the signal handler context is already lost). So just clear them to >prevent >+ * problems later. >+ */ > #define __clear_fpu( tsk ) \ > do { \ > if ((tsk)->thread_info->status & TS_USEDFPU) { \ >- asm volatile("fwait"); \ >+ asm volatile("fnclex"); \ > (tsk)->thread_info->status &= ~TS_USEDFPU; \ > stts(); \ > } \ > > Michal -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From dom at earth.li Tue Jun 15 14:40:48 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 15 Jun 2004 15:40:48 +0100 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <200406150936.53692.simon@nzservers.com> References: <200406150936.53692.simon@nzservers.com> Message-ID: <20040615144048.GN11946@tirian.magd.ox.ac.uk> On Tue, Jun 15, 2004 at 09:36:53AM -0500, Simon Weller wrote: > Linus appears to have now approved a patch: > > http://linux.bkbits.net:8080/linux-2.4/gnupatch%4040cdf6f8V7sOe5n96HA5Q7r9uDRvJQ s/Linus/Marcelo/ > It's supposedly compatible with 2.4.2x > > This is the same patch as posted by Dave Jones, but just the x86 patch. I've rolled the patch in and will be posting URLs on shortly. Cheers, Dominic. From simon at nzservers.com Tue Jun 15 14:48:40 2004 From: simon at nzservers.com (Simon Weller) Date: Tue, 15 Jun 2004 09:48:40 -0500 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040615144048.GN11946@tirian.magd.ox.ac.uk> References: <200406150936.53692.simon@nzservers.com> <20040615144048.GN11946@tirian.magd.ox.ac.uk> Message-ID: <200406150948.40673.simon@nzservers.com> On Tuesday 15 June 2004 09:40 am, Dominic Hargreaves wrote: > On Tue, Jun 15, 2004 at 09:36:53AM -0500, Simon Weller wrote: > > Linus appears to have now approved a patch: > > > > http://linux.bkbits.net:8080/linux-2.4/gnupatch%4040cdf6f8V7sOe5n96HA5Q7r > >9uDRvJQ > > s/Linus/Marcelo/ yeah, good point...looks like I need another coffee ;-) > > > It's supposedly compatible with 2.4.2x > > > > This is the same patch as posted by Dave Jones, but just the x86 patch. > > I've rolled the patch in and will be posting URLs on > shortly. excellent. - Si > > Cheers, > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From bhirt at mobygames.com Tue Jun 15 15:25:24 2004 From: bhirt at mobygames.com (Brian Hirt) Date: Tue, 15 Jun 2004 09:25:24 -0600 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <200406150936.53692.simon@nzservers.com> References: <200406150936.53692.simon@nzservers.com> Message-ID: <39010F6A-BEE0-11D8-A8CE-000D93AD2E74@mobygames.com> On Jun 15, 2004, at 8:36 AM, Simon Weller wrote: >> Signed-Off-By: Sergey Vlasov >> >> --- linux-2.6.6/include/asm-i386/i387.h.fp-lockup 2004-05-10 >> 06:33:06 >> +0400 >> +++ linux-2.6.6/include/asm-i386/i387.h 2004-06-12 22:02:58 +0400 >> @@ -48,10 +48,17 @@ >> save_init_fpu( tsk ); \ >> } while (0) >> >> +/* >> + * There might be some pending exceptions in the FP state at this >> point. >> + * However, it is too late to report them: this code is called >> during .execve() >> + * (when the original executable is already gone) and during >> sigreturn() >> (when >> + * the signal handler context is already lost). So just clear them >> to >> prevent >> + * problems later. >> + */ >> #define __clear_fpu( tsk ) \ >> do { \ >> if ((tsk)->thread_info->status & TS_USEDFPU) { \ >> - asm volatile("fwait"); \ >> + asm volatile("fnclex"); \ >> the patch quoted in this message is different than the one linus approved: http://linux.bkbits.net:8080/linux-2.4/ gnupatch%4040cdf6f8V7sOe5n96HA5Q7r9uDRvJQ #define clear_fpu( tsk ) do { \ if ( tsk->flags & PF_USEDFPU ) { \ - asm volatile("fwait"); \ + asm volatile("fnclex ; fwait"); \ tsk->flags &= ~PF_USEDFPU; \ stts(); \ } \ From jkeating at j2solutions.net Tue Jun 15 16:13:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 15 Jun 2004 09:13:01 -0700 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <39010F6A-BEE0-11D8-A8CE-000D93AD2E74@mobygames.com> References: <200406150936.53692.simon@nzservers.com> <39010F6A-BEE0-11D8-A8CE-000D93AD2E74@mobygames.com> Message-ID: <200406150913.05001.jkeating@j2solutions.net> On Tuesday 15 June 2004 08:25, Brian Hirt wrote: > the patch quoted in this message is different than the one linus > approved: > > http://linux.bkbits.net:8080/linux-2.4/ > gnupatch%4040cdf6f8V7sOe5n96HA5Q7r9uDRvJQ > > #define clear_fpu( tsk ) do { \ > if ( tsk->flags & PF_USEDFPU ) { \ > - asm volatile("fwait"); \ > + asm volatile("fnclex ; fwait"); \ > tsk->flags &= ~PF_USEDFPU; \ > stts(); \ > } \ And ^ is the patch that Dave Jones offered up to us and we're using in our package. -- 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 kevin1a at varlog.net Wed Jun 16 05:43:18 2004 From: kevin1a at varlog.net (Kevin Brouelette) Date: Tue, 15 Jun 2004 22:43:18 -0700 Subject: RH 7.2 from scratch cd install to completly updated system. Message-ID: <1087364598.1646.77.camel@athlon.kblan.com> Hello, I was testing a fresh RH 7.2 install from cdrom and wanted to automate the yum update process to get to a fully updated server. Using the website documentation I had many dependency issues that are not addressed there. This script takes care of the dependency problems that are not yet addressed in the website documentation for 7.2 after a fresh install. After running the script it is recommended that you edit yum.conf to allow kernel* updates and then run 'yum update' again and install the latest secure kernel. You can run 'yum clean' to free up some disk space. Mine is not a 'full' install. My test drive is only 2gig but includes most of the common install items, about 1gig including X, Gnome, Devel games and http, sendmail and bind servers. I would expect the script to work on a full installation. Please test, advise and have fun. Kevin PS thanks for the updates. #!/bin/sh ### 6-16-2004 kevin1a at varlog dot net ### This was created to automatically update a fresh RH 7.2 install ### to the latest updated version. ### uninstall the deps problems. We'll reinstall them at the end. rpm -e iptables rpm-python up2date rhn_register up2date-gnome rhn_register-gnome tkinter rpm-build rpm-devel gnorpm ### These two depend on each other so install them together [rpm and popt]. rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-4.0.4-7x.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/popt-1.6.4-7x.i386.rpm ### Get ready for YUM rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/gnupg-1.0.7-13.i386.rpm rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/python-1.5.2-43.72.i386.rpm rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-python-4.0.4-7x.i386.rpm ### Install YUM ### don't worry it's 7.3, it works fine on 7.2. rpm -Uvh http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386/yum-1.0.3-6.0.7.x.legacy.noarch.rpm ### Run twice as it will tell you it has to restart to read the keys. gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY ### Update the system. ### select 'y' when asked to confirm the update yum update ### Re-install what we originally removed. yum install up2date rhn_register up2date-gnome rhn_register-gnome tkinter rpm-build rpm-devel gnorpm iptables -- Kevin Brouelette kevin1a at varlog.net From jkeating at j2solutions.net Wed Jun 16 16:50:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 09:50:37 -0700 Subject: Package uploads Message-ID: <200406160950.40278.jkeating@j2solutions.net> I'm uploading a bunch of packages today to updates-testing for 7.3 and 9. When I get home tonight I'll write the update notices and touch the tickets. Just wanted to warn you that packages will appear before the notices. Sucks uploading on a cable modem (: -- 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 J.S.Peatfield at damtp.cam.ac.uk Wed Jun 16 19:53:01 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Wed, 16 Jun 2004 20:53:01 +0100 Subject: New Kernel Crash-Exploit discovered Message-ID: RH80 kernels based on the last RH9 update (with NPTL disabled as in previous RH80 updates), and with this patch added can be found at: http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i386/kernel-2.4.20-32.8.JSP.i386.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i386/kernel-doc-2.4.20-32.8.JSP.i386.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i386/kernel-source-2.4.20-32.8.JSP.i386.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i386/kernel-BOOT-2.4.20-32.8.JSP.i386.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/athlon/kernel-2.4.20-32.8.JSP.athlon.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/athlon/kernel-smp-2.4.20-32.8.JSP.athlon.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i586/kernel-2.4.20-32.8.JSP.i586.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i586/kernel-smp-2.4.20-32.8.JSP.i586.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i686/kernel-2.4.20-32.8.JSP.i686.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i686/kernel-smp-2.4.20-32.8.JSP.i686.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/RPMS/i686/kernel-bigmem-2.4.20-32.8.JSP.i686.rpm http://www.damtp.cam.ac.uk/user/jp107/rh80-updates/SRPMS/kernel-2.4.20-32.8.JSP.src.rpm Since people might want the sha1sums (I see they seem to be used here): 3a79a1cbcc79998b98c22526d6e09f501f8c0f4a RPMS/i386/kernel-2.4.20-32.8.JSP.i386.rpm 33d5aea841d1ca542ffd3760fe6b64d440b63172 RPMS/i386/kernel-doc-2.4.20-32.8.JSP.i386.rpm a222398e39c897811f3c8dac86eaa610a7ceb67a RPMS/i386/kernel-source-2.4.20-32.8.JSP.i386.rpm 775f9a4ad1a141d630e103ccfb72861b43b3defb RPMS/i386/kernel-BOOT-2.4.20-32.8.JSP.i386.rpm fad7c109aa22dafc04046c05854fa80ae9016ef8 RPMS/athlon/kernel-2.4.20-32.8.JSP.athlon.rpm 018626e369f22e34989afc7d8fe6713ba4c4a7fc RPMS/athlon/kernel-smp-2.4.20-32.8.JSP.athlon.rpm bbbbd1af7a77477ab4f0cd29708752283587add6 RPMS/i586/kernel-2.4.20-32.8.JSP.i586.rpm 6ef48ed2dfe0faccfd386c19f8af1a836b06cd25 RPMS/i586/kernel-smp-2.4.20-32.8.JSP.i586.rpm 1fef3b9107632451176766932b0f84ecaf18ce36 RPMS/i686/kernel-2.4.20-32.8.JSP.i686.rpm ff94e743d3021c0a658c4d595ba48f7891a71b3d RPMS/i686/kernel-smp-2.4.20-32.8.JSP.i686.rpm 8a4d554d41cfb06646ff45875cdb2bbc6dbc7d1c RPMS/i686/kernel-bigmem-2.4.20-32.8.JSP.i686.rpm d01c17d65f36ad277e7f136f81e9723a16762e8f SRPMS/kernel-2.4.20-32.8.JSP.src.rpm Now for the bit people might not like, the FP exception isn't the only patch in there since I was already about to roll out a new kernel anyway with the following trond NFS server patch (for talking to OSX 10.3 and FreeBSD clients): http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif New changelog bits are: * Tue Jun 15 2004 Jon Peatfield - fix fpu state to prevent kernel crash, see the redhat bugzilla entry: - http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125900 - which has a proposed patch for RHEL/FC1 - http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=101125&action=view * Sat Jun 12 2004 Jon Peatfield - nfs patch from Trond to allow us to serve clients which use - cookies != 8 bytes, OSX 10.3 uses 30 FreeBSD uses 20... - See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 - http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif The specfile diff from my previous RH80 kernels is: --cut-here-- --- kernel-2.4.spec.old-31.8.JSP 2004-04-22 19:46:01.000000000 +0100 +++ kernel-2.4.spec 2004-06-15 08:39:29.000000000 +0100 @@ -21,7 +21,7 @@ # that the kernel isn't the stock RHL kernel, for example by # adding some text to the end of the version number. # -%define release 31.8.JSP +%define release 32.8.JSP %define sublevel 20 %define kversion 2.4.%{sublevel} # /usr/src/%{kslnk} -> /usr/src/linux-%{KVERREL} @@ -288,6 +288,7 @@ Patch940: linux-2.4.22-kmod.patch Patch950: linux-2.4.25pre-selected-bits.patch Patch960: linux-2.4.26pre-selected-bits.patch +Patch961: linux-2.4.x.fpu.patch # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems @@ -333,6 +334,7 @@ Patch1380: linux-2.4.9-fstat.patch Patch1390: linux-2.4.18-irixnfs.patch Patch1391: linux-2.4.18-nfs-default-size.patch +Patch1392: linux-2.4.23-03-fix_osx.dif Patch1410: linux-2.4.20-sbp2-smpfixes.patch Patch1420: linux-2.4.7-suspend.patch Patch1450: linux-2.4.18-orinoco.patch @@ -742,6 +744,9 @@ %patch950 -p1 %patch960 -p1 +# Add in fpu patch +%patch961 -p1 + # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems # @@ -944,6 +949,10 @@ %patch1391 -p1 # +# this fixes the nfs cookie handling to allow over 8-byte cookies +# needed for support of osx 10.3 and freebsd. +%patch1392 -p1 + # # Fix some firewire deadlocks (fixes from upstream maintainter) # @@ -1922,6 +1931,18 @@ # %changelog +* Tue Jun 15 2004 Jon Peatfield +- fix fpu state to prevent kernel crash, see the redhat bugzilla entry: +- http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125900 +- which has a proposed patch for RHEL/FC1 +- http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=101125&action=view + +* Sat Jun 12 2004 Jon Peatfield +- nfs patch from Trond to allow us to serve clients which use +- cookies != 8 bytes, OSX 10.3 uses 30 FreeBSD uses 20... +- See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 +- http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif + * Tue Apr 13 2004 Dave Jones - Yet another additional r128 DRM check. (CAN-2004-0003) - Bounds checking in ISO9660 filesystem. (CAN-2004-0109) --cut-here-- I've been using these kernels on 6 of my RH8 machines since ~2pm (BST) yesterday: 2 Pentium-3 UP kernel i686 1 Pentium-4 UP kernel i686 1 Xeon 4-cpu kernel-smp i686 1 Pentium-MMX kernel i586 1 Athlon kernel athlon As soon as one of our SMP athlons and a hyperthread-aware Intel machine stops running jobs code I'll test on those too. I no longer have access to any i586 SMP machines or any which need i386 kernels. Unless something bad shows up I'll be upgrading the rest of our RH80 machines to this next week (in our regular reboot slot). Sorry for the delay in posting these but I was (finally) upgrading our site firewall yesterday so was spending most of my time reading through logs looking for errors in the config... -- Jon Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: jp107 at damtp.cam.ac.uk Web: http://www.damtp.cam.ac.uk/ From dom at earth.li Wed Jun 16 20:04:30 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 16 Jun 2004 21:04:30 +0100 Subject: New Kernel Crash-Exploit discovered In-Reply-To: References: Message-ID: <20040616200430.GT11946@tirian.magd.ox.ac.uk> On Wed, Jun 16, 2004 at 08:53:01PM +0100, Jon Peatfield wrote: > RH80 kernels based on the last RH9 update (with NPTL disabled as in > previous RH80 updates), and with this patch added can be found at: Hi, I put out kernels that fix this yesterday: see . The rh7 kernels are suitable for 8.x also. You've also lost the previous set of legacy patches (from 32.7.legacy, which was never released). Cheers, Dominic. From J.S.Peatfield at damtp.cam.ac.uk Wed Jun 16 21:39:24 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Wed, 16 Jun 2004 22:39:24 +0100 Subject: New Kernel Crash-Exploit discovered Message-ID: I've now picked up those patches (I hadn't known about them since I'd only been looking on the FL mirrors ). I will include these extra patches in my next kernels (building now). My diff against your 33.7.legacy specfile is now just: --cut-here-- --- kernel-2.4.spec.33.7.legacy 2004-06-16 21:58:41.000000000 +0100 +++ kernel-2.4.spec 2004-06-16 22:01:35.000000000 +0100 @@ -21,7 +21,7 @@ # that the kernel isn't the stock RHL kernel, for example by # adding some text to the end of the version number. # -%define release 33.7.legacy +%define release 34.8.JSP %define sublevel 20 %define kversion 2.4.%{sublevel} # /usr/src/%{kslnk} -> /usr/src/linux-%{KVERREL} @@ -291,7 +291,7 @@ Patch960: linux-2.4.26pre-selected-bits.patch Patch970: linux-2.4.25pre-selected-patches.legacy.patch Patch980: linux-2.4.26pre-selected-patches.legacy.patch -Patch990: linux-2.4.27pre-fix-x86-clear_fpu-macro.patch +Patch990: linux-2.4.x.fpu.patch # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems @@ -338,6 +338,7 @@ Patch1380: linux-2.4.9-fstat.patch Patch1390: linux-2.4.18-irixnfs.patch Patch1391: linux-2.4.18-nfs-default-size.patch +Patch1392: linux-2.4.23-03-fix_osx.dif Patch1410: linux-2.4.20-sbp2-smpfixes.patch Patch1420: linux-2.4.7-suspend.patch Patch1450: linux-2.4.18-orinoco.patch @@ -956,6 +957,10 @@ %patch1391 -p1 # +# this fixes the nfs cookie handling to allow over 8-byte cookies +# needed for support of osx 10.3 and freebsd. +%patch1392 -p1 + # # Fix some firewire deadlocks (fixes from upstream maintainter) # @@ -1936,6 +1941,16 @@ %changelog * Tue Jun 15 2004 Dominic Hargreaves - Fix local DoS in "clear_cpu()" macro. +- See the redhat bugzilla entry: +- http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125900 +- which has a proposed patch for RHEL/FC1 +- http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=101125&action=view + +* Sat Jun 12 2004 Jon Peatfield +- nfs patch from Trond to allow us to serve clients which use +- cookies != 8 bytes, OSX 10.3 uses 30 FreeBSD uses 20... +- See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 +- http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif * Thu May 13 2004 Dominic Hargreaves - Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228) --cut-here-- I still need the NFS fix and the fpu patch I includes (from RHEL/FC) patched the x86_64 (not that I have any but I found that one in redhat bugzilla). I bumped the version number to note the NFS server fix. Of course this has little to do with FL since it doesn't support RH80 :-) Please don't let my witterings delay the release of the next FL kernel update! -- Jon From jkeating at j2solutions.net Thu Jun 17 02:12:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 19:12:10 -0700 Subject: Fedora Test Update Notification: cadaver Message-ID: <200406161912.10809.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1552 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1552 2004-06-16 - --------------------------------------------------------------------- Name : cadaver Version 7.3 : 0.22.1-1.legacy Version 9 : 0.22.1-3.legacy Summary : A command-line WebDAV client. Description : cadaver is a command-line WebDAV client. It supports file upload, download, on-screen display, namespace operations (move/copy), collection creation and deletion, and locking operations. - --------------------------------------------------------------------- Update Information: CAN-2004-0179: Multiple format string vulnerabilities in (1) neon 0.24.4 and earlier, and other producs that use neon including (2) Cadaver, (3) Subversion, or (4) OpenOffice, allow remote malicious WebDAV servers to execute arbitrary code. - --------------------------------------------------------------------- Changelog: 7.3: * Tue Jun 01 2004 Marc Deslauriers 0.22.1-1.legacy - - Bump to 0.22.1 - - Added patch for CAN-2004-0398 - - Added libtool and zlib-devel prereq - - Added krb5-devel buildconflict * Sat May 01 2004 Seth Vidal 0.22.0-1.legacy - - bump to 0.22.0 - - fixes http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0179 - - fix to make sure ssl support is still enabled 9: * Tue Jun 15 2004 Jesse Keating 0.22.1-3.legacy - - Added pkgconfig as a buildreq * Wed Jun 02 2004 Marc Deslauriers 0.22.1-2.legacy - - Bump to 0.22.1 - - Added patch for CAN-2004-0398 - - Added libtool and zlib-devel prereq - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates-testing/SRPMS/cadaver-0.22.1-1.legacy.src.rpm 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates-testing/i386/cadaver-0.22.1-1.legacy.i386.rpm 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates-testing/SRPMS/cadaver-0.22.1-3.legacy.src.rpm 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates-testing/i386/cadaver-0.22.1-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) iD8DBQFA0P364v2HLvE71NURApoVAKCtLtOQqHUByJEjAAYuD2uj8XdZiwCeKZOZ bg+VUNoXRdcFgM2Oi5JVnM4= =HIG3 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 02:18:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 19:18:55 -0700 Subject: Fedora Test Update Notification: sysklogd Message-ID: <200406161918.55801.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1553 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1553 2004-06-16 - --------------------------------------------------------------------- Name : sysklogd Version 7.3 : 1.4.1-14.legacy.7x Version 9 : 1.4.1-14.legacy.9 Summary : System logging and kernel message trapping daemons. Description : The sysklogd package contains two system utilities (syslogd and klogd) which provide support for system logging. Syslogd and klogd run as daemons (background processes) and log system messages to different places, like sendmail logs, security logs, error logs, etc. - --------------------------------------------------------------------- Update Information: During a code review it was discovered that syslogd does not allocate enough memory to store all its pointers in the crunch list. crunch_list is only called from the commandline, so it's not an exploitable security issue (although it is a bug.) - --------------------------------------------------------------------- Changelog: 7.3: * Tue Jun 15 2004 Jesse Keating 1.4.1-14.legacy.7x - - Built for RHL 7.x * Sun May 02 2004 Rok Papez 1.4.1-14.legacy.9 - - crunchlist memory overrun fix, now with more complete owl patch * Sat May 01 2004 Seth Vidal 1.4.1-13.legacy.9 - - crunchlist memory overrun fix 9: * Sun May 02 2004 Rok Papez 1.4.1-14.legacy.9 - - crunchlist memory overrun fix, now with more complete owl patch * Sat May 01 2004 Seth Vidal 1.4.1-13.legacy.9 - - crunchlist memory overrun fix - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 3f8e285b96ae0edac5e13ac79ac399370273aabf 7.3/updates-testing/SRPMS/sysklogd-1.4.1-14.legacy.7x.src.rpm f0f67bd5db849a382f6535363b6233f8e72a45c5 7.3/updates-testing/i386/sysklogd-1.4.1-14.legacy.7x.i386.rpm ed1462e72e4ab23e7bb3ec270a4df7fa3216dd5e 9/updates-testing/SRPMS/sysklogd-1.4.1-14.legacy.9.src.rpm 9a5972d1b3485c875b8f57b7b277341a74958d4b 9/updates-testing/i386/sysklogd-1.4.1-14.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) iD8DBQFA0P+P4v2HLvE71NURAl6zAKC1rtUfSClFGN5Tm8JiWFwLZBnJnACgoFBA AJIyml8kTlvoyGmOSZwcHXQ= =Dzrm -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 03:40:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 20:40:31 -0700 Subject: Fedora Test Update Notification: lha Message-ID: <200406162040.31395.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1547 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1547 2004-06-16 - --------------------------------------------------------------------- Name : lha Version 7.3 : 1.14i-4.7.3.1.legacy Summary : An archiving and compression utility for LHarc format archives. Description : LHA is an archiving and compression utility for LHarc format archives. LHA is mostly used in the DOS world, but can be used under Linux to extract DOS files from LHA archives. Install the lha package if you need to extract DOS files from LHA archives. - --------------------------------------------------------------------- Update Information: CAN-2004-0234: Multiple stack-based buffer overflows in the get_header function in header.c for LHA 1.14 allow remote attackers or local users to execute arbitrary code via long directory or file names in an LHA archive, which triggers the overflow when testing or extracting the archive. CAN-2004-0235: Multiple directory traversal vulnerabilities in LHA 1.14 allow remote attackers or local users to create arbitrary files via an LHA archive containing filenames with (1) .. sequences or (2) absolute pathnames with double leading slashes ("//absolute/path"). - --------------------------------------------------------------------- Changelog: 7.3: * Sat May 01 2004 Jonny Strom 1.14i-4 - - fix security vulnerabilities, CAN-2004-0234, CAN-2004-0235 * Wed Feb 27 2002 Than Ngo 1.14i-4 - - rebuild * Tue Jan 29 2002 Than Ngo 1.14i-3 - - rebuild in rawhide - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ be858cbed37c43d12f2e3c8943fd5aa21331a191 7.3/updates-testing/SRPMS/lha-1.14i-4.7.3.1.legacy.src.rpm 1809b90634cc098bb86823375f7ff07a00ce0693 7.3/updates-testing/i386/lha-1.14i-4.7.3.1.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) iD8DBQFA0RKv4v2HLvE71NURAgPqAJ9HVCv/UsjmQUKp1Y+oDoUWs3O07wCeLkkY hMhg834YyHVcgBvidVe5ecA= =9Cuy -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 03:45:19 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 20:45:19 -0700 Subject: Fedora Test Update Notification: mc Message-ID: <200406162045.19467.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1548 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1548 2004-06-16 - --------------------------------------------------------------------- Name : mc Version 7.3 : 4.5.55-7.legacy Summary : A user-friendly file manager and visual shell. 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. - --------------------------------------------------------------------- Update Information: CAN-2004-0226: Multiple buffer overflows in Midnight Commander (mc) before 4.6.0 may allow attackers to cause a denial of service or execute arbitrary code. CAN-2004-0231: Multiple vulnerabilities in Midnight Commander (mc) before 4.6.0, with unknown impact, related to "Insecure temporary file and directory creations." CAN-2004-0232: Multiple format string vulnerabilities in Midnight Commander (mc) before 4.6.0 may allow attackers to cause a denial of service or execute arbitrary code. - --------------------------------------------------------------------- Changelog: 7.3: * Sun May 02 2004 Jonny Strom - - Fix buffer overflows CAN-2004-0226, a format string vulnerability - - CAN-2004-0232 and some insecure temporary file creations CAN-2004-0231. - - Based on the woody patch. * Sun Jan 25 2004 Michael Schwendt - - Fix up missing build requirements. - - Move PAM dependency to disabled mcserv package. * Sun Jan 18 2004 Jesse Keating - - Version change to -6.legacy - - Changed patch file to be named for the CVE - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ cb94798809ae1c21c884591e1f3d0cab933edada 7.3/updates-testing/SRPMS/mc-4.5.55-7.legacy.src.rpm e5a3355aa808fb41e9d914eb2efb4b737723d157 7.3/updates-testing/i386/mc-4.5.55-7.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) iD8DBQFA0RPP4v2HLvE71NURAt/kAJ9YMVh6anMJC+F6BCPR4Uf7/tpqFACgoxEg NMF+wspkz8ezUI0lQ9nN0Mk= =hkkj -----END PGP SIGNATURE----- From villegas at math.gatech.edu Thu Jun 17 03:46:14 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Wed, 16 Jun 2004 23:46:14 -0400 Subject: bugzilla and signatures Message-ID: <20040617034614.GA4226@math30192.math.gatech.edu> Bugzilla has damaged my signatures a couple of times, I remeber that someone mentioned a list of things to avoid this from happening, but can't find it anywhere. Is it on the web? I remeber some email about it on the mailing list some months ago, but I can't seem to find it... Carlos From jkeating at j2solutions.net Thu Jun 17 03:49:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 20:49:23 -0700 Subject: Fedora Test Update Notification: libpng10 Message-ID: <200406162049.23572.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1550 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1550 2004-06-16 - --------------------------------------------------------------------- Name : libpng10 Version 9 : 1.0.13-11.1.legacy Summary : Old version of libpng, needed to run old binaries. Description : The libpng10 package contains an old version of libpng, a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. This package is needed if you want to run binaries that were linked dynamically with libpng 1.0.x. - --------------------------------------------------------------------- Update Information: CAN-2002-1363: Portable Network Graphics (PNG) libraries (1) libpng 1.2.1 and earlier, and (2) libpng3 1.2.5 and earlier, do not correctly calculate offsets, which allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a buffer overflow attack on the row buffers. - --------------------------------------------------------------------- Changelog: 9: * Tue Jun 08 2004 Marc Deslauriers 1.0.13-11.1.legacy - - Added long lost patch for CAN-2002-1363 * Mon Apr 19 2004 Matthias Clasen - - fix a possible out-of-bounds read in the error message handler. #121229 * Tue Mar 02 2004 Elliot Lee - - rebuilt - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 147dea7dbd723e9260acc770ce93aa7ab68c277c 9/updates-testing/SRPMS/libpng10-1.0.13-11.1.legacy.src.rpm 704af3eb2cdd53c6860cae248c56ce85c410c729 9/updates-testing/i386/libpng10-1.0.13-11.1.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) iD8DBQFA0RTD4v2HLvE71NURArm+AJ9Qo/1CzevtzH0Do9ULx52fwMW26wCeL9Cs f2nKJnhHFk0gkIA0IPqaNXc= =laAc -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 03:55:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 20:55:50 -0700 Subject: Fedora Test Update Notification: tripwire Message-ID: <200406162055.50694.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1719 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1719 2004-06-16 - --------------------------------------------------------------------- Name : tripwire Version 7.3 : 2.3.1-20.legacy.7x Version 9 : 2.3.1-20.legacy.9 Summary : A system integrity assessment tool. Description : Tripwire is a very valuable security tool for Linux systems, if it is installed to a clean system. Tripwire should be installed right after the OS installation, and before you have connected your system to a network (i.e., before any possibility exists that someone could alter files on your system). When Tripwire is initially set up, it creates a database that records certain file information. Then when it is run, it compares a designated set of files and directories to the information stored in the database. Added or deleted files are flagged and reported, as are any files that have changed from their previously recorded state in the database. When Tripwire is run against system files on a regular basis, any file changes will be spotted when Tripwire is run. Tripwire will report the changes, which will give system administrators a clue that they need to enact damage control measures immediately if certain files have been altered. After installing this package, run /etc/tripwire/twinstall.sh to generate cryptographic keys and run tripwire --init to initialize the database. - --------------------------------------------------------------------- Update Information: http://www.securityfocus.com/archive/1/365036/2004-06-01/2004-06-07/2 : Tripwire(tm) is a Security, Intrusion Detection, Damage Assessment and Recovery, Forensics software. A vulnerability in the product allows a user on the local machine under certain circumstances to execute arbitrary code with the rights of the user running the program (typically root). - --------------------------------------------------------------------- Changelog: 7.3: * Tue Jun 15 2004 Jesse Keating 2.3.1-20.legacy.7x - - Added gcc-c++ as a BuildReq - - Changed version number to allow for 7.x to bump w/out touching 9 * Fri Jun 04 2004 Marc Deslauriers 2.3.1-18.legacy - - Added patch for format string vulnerability (FL #1719) 9: * Tue Jun 15 2004 Jesse Keating 2.3.1-20.legacy.9 - - Added gcc-c++ - - Altered version for 7.x/9 independence. * Fri Jun 04 2004 Marc Deslauriers 2.3.1-19.legacy - - Added patch for format string vulnerability (FL #1719) - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ b266219a8b7d05e35e2dba5c7a33bb15d518f7ad 7.3/updates-testing/SRPMS/tripwire-2.3.1-20.legacy.7x.src.rpm e7649912f208a73276c16cffcb4dfb19e23bad9c 7.3/updates-testing/i386/tripwire-2.3.1-20.legacy.7x.i386.rpm c65f628b723c3280d2cce0484ba5e8163081e1e8 9/updates-testing/SRPMS/tripwire-2.3.1-20.legacy.9.src.rpm 321d6537458ef99779be8f5377ea94695c6e1b5f 9/updates-testing/i386/tripwire-2.3.1-20.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) iD8DBQFA0RZG4v2HLvE71NURAqS1AKCnnxwgsO+BQCt5tQXo6amvs+ItSgCgjsNO nGSlPD0Oca2/FTu6H51Bl3I= =abiM -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 03:59:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 20:59:11 -0700 Subject: Fedora Test Update Notification: squid Message-ID: <200406162059.11504.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1732 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1732 2004-06-16 - --------------------------------------------------------------------- Name : squid Version 9 : 2.5.STABLE1-4.10.legacy Summary : The Squid proxy caching server. Description : Squid is a high-performance proxy caching server for Web clients, supporting FTP, gopher, and HTTP data objects. Unlike traditional caching software, Squid handles all requests in a single, non-blocking, I/O-driven process. Squid keeps meta data and especially hot objects cached in RAM, caches DNS lookups, supports non-blocking DNS lookups, and implements negative caching of failed requests. Squid consists of a main server program squid, a Domain Name System lookup program (dnsserver), a program for retrieving FTP data (ftpget), and some management and client tools. - --------------------------------------------------------------------- Update Information: Remote exploitation of a buffer overflow vulnerability in Squid Web Proxy Cache could allow a remote attacker to execute arbitrary code. A remote attacker can compromise a target system if Squid Proxy is configured to use the NTLM authentication helper. The attacker can send an overly long password to overflow the buffer and execute arbitrary code. iDEFENSE has confirmed the existence of this vulnerability in Squid-Proxy 2.5.*-STABLE and 3.*-PRE when Squid-Proxy is compiled with the NTLM helper enabled. - --------------------------------------------------------------------- Changelog: 9: * Tue Jun 15 2004 Jesse Keating 7:2.5.STABLE1-4.10.legacy - - Added openssl-devel cyrus-sasl-devel as buildreqs. * Tue Jun 08 2004 Marc Deslauriers 7:2.5.STABLE1-4.9.legacy - - CAN-2004-0541 security patch (NTLM Authentication Helper Buffer Overflow) * Tue Mar 09 2004 Jay Fenlason 7:2.5.STABLE1-3.9 - - Backport patch for %00 vulnerability - - Backport patch to support the new urllogin acl type so squid can be configured to protect vulnerable Microsoft Internet Explorer users. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ d22a414bdee2eaa3bd7c067afc0c181ee78e0a68 9/updates-testing/SRPMS/squid-2.5.STABLE1-4.10.legacy.src.rpm 3af36a2a723d62f34337a3b56f3b4a0a8705288f 9/updates-testing/i386/squid-2.5.STABLE1-4.10.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) iD8DBQFA0RcP4v2HLvE71NURAnDKAJ9S1ESYbN/Pa7oCXJ3SrYe3GYyRawCeI/JK OIjIASyaYp4/OKcGd+XBBBE= =Sjap -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 04:07:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 21:07:13 -0700 Subject: Fedora Test Update Notification: libpng Message-ID: <200406162107.13486.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1550 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1550 2004-06-17 - --------------------------------------------------------------------- Name : libpng Version 7.3 : 1.0.14-0.7x.5.legacy Summary : A library of functions for manipulating PNG image format files. Description : The libpng package contains a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. PNG is a bit-mapped graphics format similar to the GIF format. PNG was created to replace the GIF format, since GIF uses a patented data compression algorithm. Libpng should be installed if you need to manipulate PNG format image files. - --------------------------------------------------------------------- Update Information: CAN-2004-0421: The Portable Network Graphics library (libpng) 1.0.15 and earlier allows attackers to cause a denial of service (crash) via a malformed PNG image file that triggers an error that causes an out-of-bounds read when creating the error message. - --------------------------------------------------------------------- Changelog: 7.3: * Sat May 01 2004 Seth Vidal 1.0.14-0.7x.5.legacy - - new number :) * Sat May 01 2004 Seth Vidal 1.0.14-0.7x.4.legacy.0 - - build with modified patch from rhl9 (and others) libpng update * Thu Dec 19 2002 Jonathan Blandford - - fix security problem - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 20619750b9d6f5fb4fa4cfaad6ff31f3280372bb 7.3/updates-testing/SRPMS/libpng-1.0.14-0.7x.5.legacy.src.rpm 5a1ff70a2deb721b370bbcacff4ef3a1ee3f79ce 7.3/updates-testing/i386/libpng-1.0.14-0.7x.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) iD8DBQFA0Rjx4v2HLvE71NURArQ8AJ93DyuFRq1iteNJFVJ5EngOWn1c1QCfb1dF ptDaZTeJu6JDw5hlTzPML2E= =271+ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 04:23:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 21:23:10 -0700 Subject: Fedora Test Update Notification: mailman Message-ID: <200406162123.10384.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1734 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1734 2004-06-17 - --------------------------------------------------------------------- Name : mailman Version 9 : 2.1.1-7.legacy Summary : Mailing list manager with built in Web access. Description : Mailman is software to help manage email discussion lists, much like Majordomo and Smartmail. Unlike most similar products, Mailman gives each mailing list a webpage, and allows users to subscribe, unsubscribe, etc. over the Web. Even the list manager can administer his or her list entirely from the Web. Mailman also integrates most things people want to do with mailing lists, including archiving, mail <-> news gateways, and so on. Documentation can be found in: /usr/share/doc/mailman-2.1.1 When the package has finished installing, you will need to perform some additional installation steps, these are described in: /usr/share/doc/mailman-2.1.1/INSTALL.REDHAT - --------------------------------------------------------------------- Update Information: CAN-2004-0412: Mailman before 2.1.5 allows remote attackers to obtain user passwords via a crafted email request to the Mailman server. - --------------------------------------------------------------------- Changelog: 9: * Tue Jun 15 2004 Jesse Keating 3:2.1.1-7.legacy - - Added automake, autoconf, python and python-devel as BuildReqs * Wed Jun 09 2004 Marc Deslauriers 3:2.1.1-6.legacy - - security errata CAN-2004-0412, user password compromise - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 4dee398d2d9b1d107850665f04c082073b4465a5 9/updates-testing/SRPMS/mailman-2.1.1-7.legacy.src.rpm 66cbbfcf168869969b0aaa0298d3680c3b8e5a3c 9/updates-testing/i386/mailman-2.1.1-7.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) iD8DBQFA0Ryu4v2HLvE71NURAqhqAJ4273PT+qQQ/8RFnCxr16iZA5C5CQCeNW4/ EbGVntwVHtsJb6OAi6xx4lE= =iDgM -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 04:25:29 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 21:25:29 -0700 Subject: Fedora Test Update Notification: squirrelmail Message-ID: <200406162125.29565.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1733 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1733 2004-06-17 - --------------------------------------------------------------------- Name : squirrelmail Version 9 : 1.4.3-0.f0.9.1.legacy Summary : SquirrelMail webmail client Description : SquirrelMail is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no Javascript) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation. - --------------------------------------------------------------------- Update Information: It has been reported that SquirrelMail is affected by a cross-site scripting vulnerability in the handling of folder name displays. This issue is due to a failure of the application to properly sanitize user-supplied input prior to including it in dynamic web content. This issue may allow for theft of cookie-based authentication credentials. Other attacks are also possible. - --------------------------------------------------------------------- Changelog: 9: * Tue Jun 08 2004 Marc Deslauriers 1.4.3-0.f0.9.1.legacy - - Rebuilt as Fedora Legacy update for rh9 (XSS vulnerabilities) * Mon Jun 07 2004 Gary Benson 1.4.3-0.f1.1 - - upgrade to 1.4.3a. - - retain stuff after version when adding release to it. * Wed Jun 02 2004 Gary Benson - - upgrade to 1.4.3. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ c11465630aac1834c37b9af25dc77bccfd1785be 9/updates-testing/SRPMS/squirrelmail-1.4.3-0.f0.9.1.legacy.src.rpm de580a0c9f0b5d8129b0dc5b11671ce9c8e8446f 9/updates-testing/i386/squirrelmail-1.4.3-0.f0.9.1.legacy.noarch.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) iD8DBQFA0R054v2HLvE71NURAkrIAJsE0B9DkSGom8ueRQ64GJNTxKJldACgssWa ocfOaEJNPQSyXgIue2exGqU= =+RHc -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 05:43:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 22:43:55 -0700 Subject: Fedora Test Update Notification: flim Message-ID: <200406162243.56013.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1581 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1581 2004-06-17 - --------------------------------------------------------------------- Name : flim Version 7.3 : 1.14.4-4.7x.legacy Version 9 : 1.14.4-4.9.legacy Summary : Library to provide basic features about message for Emacs Description : FLIM is a library to provide basic features about message representation or encoding for Emacs. - --------------------------------------------------------------------- Update Information: CAN-2004-0422: flim before 1.14.3 creates temporary files insecurely, which allows local users to overwrite arbitrary files of the Emacs user via a symlink attack. - --------------------------------------------------------------------- Changelog: 7.3: * Wed Jun 16 2004 Jesse Keating 1.14.4-4.7x.legacy - - Added openmotif as a BuildReq * Sat May 08 2004 Michael Schwendt 1.14.4-3.legacy - - Apply Debian patch for CAN-2004-0422 (mel-u.el.diff). * Wed Jan 22 2003 Tim Powers - - rebuilt 9: * Wed Jun 16 2004 Jesse Keating 1.14.4-4.9.legacy - - Added openmotif as a BuildReq * Sat May 08 2004 Michael Schwendt 1.14.4-3.legacy - - Apply Debian patch for CAN-2004-0422 (mel-u.el.diff). - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ f7236bf2d2a3ed5b024e391918ff286b8f0b10db 7.3/updates-testing/SRPMS/flim-1.14.4-4.7x.legacy.src.rpm c3683fae4e02fa01490a0e7376b0cc680921c3cc 7.3/updates-testing/i386/flim-1.14.4-4.7x.legacy.noarch.rpm b895a2ea9a6c7c52f22cabd273306dfea9d318e4 7.3/updates-testing/i386/flim-xemacs-1.14.4-4.7x.legacy.noarch.rpm 20ab29707a40a754bb7259b8940be283eb82f7d0 9/updates-testing/SRPMS/flim-1.14.4-4.9.legacy.src.rpm 136a864b72fe9600caeec27b0804a55013c27dbc 9/updates-testing/i386/flim-1.14.4-4.9.legacy.noarch.rpm 5ce5f434dd078bfb863f595379897ad1e9b37a59 9/updates-testing/i386/flim-xemacs-1.14.4-4.9.legacy.noarch.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) iD8DBQFA0S+c4v2HLvE71NURAncqAJ0W/0VTQ9dQyRUxY9aqXSAm2s06eQCeL+J1 0voKXMHKRfX4LVzEn/kdaKo= =nJW4 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jun 17 05:47:49 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 16 Jun 2004 22:47:49 -0700 Subject: Fedora Test Update Notification: xchat Message-ID: <200406162247.49115.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1549 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1549 2004-06-17 - --------------------------------------------------------------------- Name : xchat Version 7.3 : 1.8.9-1.73.2.legacy Summary : A GTK+ IRC (chat) client. Description : X-Chat is an IRC client for the X Window System and GTK+. X-Chat is fairly easy to use and includes a nice interface. - --------------------------------------------------------------------- Update Information: CAN-2004-0409: Stack-based buffer overflow in the Socks-5 proxy code for XChat 1.8.0 to 2.0.8, with socks5 traversal enabled, allows remote attackers to execute arbitrary code. - --------------------------------------------------------------------- Changelog: 7.3: * Wed Jun 16 2004 Jesse Keating 1.8.9-2 - - Added in BuildReqs * Sat May 01 2004 Jonny Strom 1.8.9-2 - - Add bugfix from xchat.org xc208-fixsocks5.diff CAN-2004-0409 * Mon May 20 2002 Mike A. Harris 1.8.9-2 - - Updated to xchat 1.8.9 - - Built security erratum for RHL 7.3, 7.2, 7.1, 7.0, 6.2 for DNS issue reported at http://online.securityfocus.com/bid/4376/info/ - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ cf1a4d68df4b21c9f19cc8ac8f87bd6802413e43 7.3/updates-testing/SRPMS/xchat-1.8.9-1.73.2.legacy.src.rpm ec7357872af344cb5e09556ba21865aa78e99e3d 7.3/updates-testing/i386/xchat-1.8.9-1.73.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) iD8DBQFA0TCF4v2HLvE71NURAoQJAJwIhn/8oLONPyVqOxMwEww3vlpIywCeK/HR 17wHfasVasGAMOZT+kxLnmA= =Yz3z -----END PGP SIGNATURE----- From simon at nzservers.com Thu Jun 17 14:00:36 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 17 Jun 2004 09:00:36 -0500 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040616200430.GT11946@tirian.magd.ox.ac.uk> References: <20040616200430.GT11946@tirian.magd.ox.ac.uk> Message-ID: <200406170900.36100.simon@nzservers.com> On Wednesday 16 June 2004 03:04 pm, Dominic Hargreaves wrote: > On Wed, Jun 16, 2004 at 08:53:01PM +0100, Jon Peatfield wrote: > > RH80 kernels based on the last RH9 update (with NPTL disabled as in > > previous RH80 updates), and with this patch added can be found at: > > Hi, > > I put out kernels that fix this yesterday: see > . The rh7 kernels > are suitable for 8.x also. You've also lost the previous set of legacy > patches (from 32.7.legacy, which was never released). > > Cheers, > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list We've been running the smp build on a 7.3 box for about a day now with moderate load, and it seems to be nice and stable. - Si -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From rmy at tigress.co.uk Thu Jun 17 14:01:45 2004 From: rmy at tigress.co.uk (Ron Yorston) Date: Thu, 17 Jun 2004 15:01:45 +0100 (BST) Subject: Self-Introduction: Ron Yorston Message-ID: <200406171401.PAA04650@internal.tigress.co.uk> Hello, I'd like to get some of the outstanding fixes for rh73 pushed through, so here's my introduction so that I can help with the effort: Name: Ronald Macrae Yorston Location: Marlow, UK Profession: Software engineer Company: Tigress Limited Goals: Keep rh73 machines running until they get upgraded or die of old age. Qualifications: Building RPMs; much coding in C, C++, Fortran and Java. GPG id: pub 1024R/8F114745 1995-03-11 Ronald M Yorston Key fingerprint = CA 8E 06 C1 9C AE CF E5 CC AF 0B A5 70 05 65 CD uid Ronald M Yorston Ron Yorston Tigress Limited, phone: +44 1628 402400 Anglers Court, 33-44 Spittal Street, fax: +44 1628 475799 Marlow, Bucks, e-mail: rmy at tigress.co.uk SL7 1DB, UK From tseaver at zope.com Mon Jun 7 19:41:34 2004 From: tseaver at zope.com (Tres Seaver) Date: Mon, 07 Jun 2004 15:41:34 -0400 Subject: does fedoralegacy depend on fedora.us? In-Reply-To: <200406071133.04002.jkeating@j2solutions.net> References: <200406071133.04002.jkeating@j2solutions.net> Message-ID: <40C4C4EE.1090308@zope.com> Jesse Keating wrote: > On Monday 07 June 2004 11:26, Joe Pruett wrote: > >>since there still isn't an official apt or yum for fedora legacy on >>rh9 boxes, we are instructed to use the fedora.us version. further, >>we are only instructed to add the fedoralegacy.org url to the >>sources.list file and not to comment out the fedora.us urls (or the >>macromedia ones in sources.list.d). is this an oversight in the docs >>(like not telling us to install the fedora legacy key)? or are you >>relying on the other rpms that fedora.us would install (10 packages >>that i see via apt-get -s upgrade)? i have assumed this is an >>oversight and not installed the fedora.us rpms, but clarification >>would be good, as well as updating the docs. > > > Oversight. We absolutely do NOT depend on Fedora.us. A 9 version of > yum is in QA mode, apt needs some love. Why not just use the apt from freshrpms? http://ayo.freshrpms.net/redhat/9/i386/SRPMS.freshrpms/apt-0.5.5cnc6-fr1.src.rpm I guess you would want to tweak the sources.list to point to fedoralegacy, but otherwise I can't see any point in not reusing it. Actually, I would pull yum from there for RH9 as well. http://ayo.freshrpms.net/redhat/9/i386/SRPMS.freshrpms/yum-2.0.4-1.rh.fr.src.rpm Tres. -- =============================================================== Tres Seaver tseaver at zope.com Zope Corporation "Zope Dealers" http://www.zope.com From tseaver at zope.com Mon Jun 7 19:41:34 2004 From: tseaver at zope.com (Tres Seaver) Date: Mon, 07 Jun 2004 15:41:34 -0400 Subject: does fedoralegacy depend on fedora.us? In-Reply-To: <200406071133.04002.jkeating@j2solutions.net> References: <200406071133.04002.jkeating@j2solutions.net> Message-ID: <40C4C4EE.1090308@zope.com> Jesse Keating wrote: > On Monday 07 June 2004 11:26, Joe Pruett wrote: > >>since there still isn't an official apt or yum for fedora legacy on >>rh9 boxes, we are instructed to use the fedora.us version. further, >>we are only instructed to add the fedoralegacy.org url to the >>sources.list file and not to comment out the fedora.us urls (or the >>macromedia ones in sources.list.d). is this an oversight in the docs >>(like not telling us to install the fedora legacy key)? or are you >>relying on the other rpms that fedora.us would install (10 packages >>that i see via apt-get -s upgrade)? i have assumed this is an >>oversight and not installed the fedora.us rpms, but clarification >>would be good, as well as updating the docs. > > > Oversight. We absolutely do NOT depend on Fedora.us. A 9 version of > yum is in QA mode, apt needs some love. Why not just use the apt from freshrpms? http://ayo.freshrpms.net/redhat/9/i386/SRPMS.freshrpms/apt-0.5.5cnc6-fr1.src.rpm I guess you would want to tweak the sources.list to point to fedoralegacy, but otherwise I can't see any point in not reusing it. Actually, I would pull yum from there for RH9 as well. http://ayo.freshrpms.net/redhat/9/i386/SRPMS.freshrpms/yum-2.0.4-1.rh.fr.src.rpm Tres. -- =============================================================== Tres Seaver tseaver at zope.com Zope Corporation "Zope Dealers" http://www.zope.com From davej at codemonkey.org.uk Thu Jun 17 11:03:45 2004 From: davej at codemonkey.org.uk (Dave Jones) Date: Thu, 17 Jun 2004 12:03:45 +0100 Subject: another RHL9 kernel patch. Message-ID: <20040617110345.GA5723@redhat.com> There's a nasty memory leak fixed in FC1 which should have been backported to RHL9, as its user exploitable, and can be considered a local DoS. This was CAN-2004-0427 I'm fairly certain this hasn't been picked up yet, so patch below. Dave --- linux-2.4.20/kernel/fork.c~ 2004-06-17 11:49:24.767644168 +0100 +++ linux-2.4.20/kernel/fork.c 2004-06-17 11:49:57.011742320 +0100 @@ -971,6 +971,8 @@ exit_namespace(p); bad_fork_cleanup_mm: exit_mm(p); + if (p->active_mm) + mmdrop(p->active_mm); bad_fork_cleanup_signal: exit_signal(p); bad_fork_cleanup_sighand: From dom at earth.li Thu Jun 17 14:19:22 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 17 Jun 2004 15:19:22 +0100 Subject: another RHL9 kernel patch. In-Reply-To: <20040617110345.GA5723@redhat.com> References: <20040617110345.GA5723@redhat.com> Message-ID: <20040617141922.GX11946@tirian.magd.ox.ac.uk> On Thu, Jun 17, 2004 at 12:03:45PM +0100, Dave Jones wrote: > There's a nasty memory leak fixed in FC1 which should have been > backported to RHL9, as its user exploitable, and can be considered > a local DoS. This was CAN-2004-0427 Cheers for the heads up. Plus there's this thing appeared on bugtraq about an i2c vulnerability. Ho hum. Dominic. From davej at redhat.com Thu Jun 17 14:25:59 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 17 Jun 2004 15:25:59 +0100 Subject: another RHL9 kernel patch. In-Reply-To: <20040617141922.GX11946@tirian.magd.ox.ac.uk> References: <20040617110345.GA5723@redhat.com> <20040617141922.GX11946@tirian.magd.ox.ac.uk> Message-ID: <1087482359.17439.1.camel@delerium.codemonkey.org.uk> On Thu, 2004-06-17 at 15:19, Dominic Hargreaves wrote: > On Thu, Jun 17, 2004 at 12:03:45PM +0100, Dave Jones wrote: > > There's a nasty memory leak fixed in FC1 which should have been > > backported to RHL9, as its user exploitable, and can be considered > > a local DoS. This was CAN-2004-0427 > > Cheers for the heads up. Plus there's this thing appeared on bugtraq > about an i2c vulnerability. Ho hum. That looks bogus. The size_t can't be negative. It's unsigned by its nature, which means passing -1 (0xffffffff) will get trapped by the if (count>4000) check before it gets as far as the kmalloc. Dave From jkeating at j2solutions.net Thu Jun 17 14:57:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 17 Jun 2004 07:57:56 -0700 Subject: Fedora Test Update Notification: mozilla Message-ID: <200406170757.56276.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1532 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1532 2004-06-17 - --------------------------------------------------------------------- Name : mozilla Version 7.3 : 1.4.2-2.1.0.legacy.1 Summary : Web browser and mail reader Description : Mozilla is an open-source web browser, designed for standards compliance, performance and portability. - --------------------------------------------------------------------- Update Information: CAN-2003-0564: Multiple vulnerabilities in multiple vendor implementations of the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol allow remote attackers to cause a denial of service and possibly execute arbitrary code via an S/MIME email message containing certain unexpected ASN.1 constructs, as demonstrated using the NISSC test suite. CAN-2003-0594: Mozilla allows remote attackers to bypass intended cookie access restrictions on a web application via "%2e%2e" (encoded dot dot) directory traversal sequences in a URL, which causes Mozilla to send the cookie outside the specified URL subsets, e.g. to a vulnerable application that runs on the same server as the target application. CAN-2004-0191: Mozilla before 1.4.2 executes Javascript events in the context of a new page while it is being loaded, allowing it to interact with the previous page (zombie document) and enable cross-domain and cross-site scripting (XSS) attacks, as demonstrated using onmousemove events. - --------------------------------------------------------------------- Changelog: 7.3: * Fri Jun 11 2004 Jesse Keating - - Added legacy and added gcc-c++ as a build-req * Wed Mar 24 2004 Chris Blizzard 37:1.4.2-3.0.0.SNAP - - Update to a 1.4.2. - - Time for a new changelog. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 43f3c7ed5c1cb848478937cadab47bd5237c43dd 7.3/updates-testing/SRPMS/mozilla-1.4.2-2.1.0.legacy.1.src.rpm bac721ec26e0fe0a97ce17ca76a229f78e06f027 7.3/updates-testing/i386/mozilla-1.4.2-2.1.0.legacy.1.i386.rpm 7b6f4ae222a80e06940dd2fe6fa100f4d933e92c 7.3/updates-testing/i386/mozilla-chat-1.4.2-2.1.0.legacy.1.i386.rpm f0ae36c8710968fec5b81e1f7eb7c21ca3aae7eb 7.3/updates-testing/i386/mozilla-devel-1.4.2-2.1.0.legacy.1.i386.rpm 194ccdb868d8985f1e3b363229141ed69b1e1211 7.3/updates-testing/i386/mozilla-dom-inspector-1.4.2-2.1.0.legacy.1.i386.rpm 59171244d35d111f9543b45a7399333f7d66c61e 7.3/updates-testing/i386/mozilla-js-debugger-1.4.2-2.1.0.legacy.1.i386.rpm 3cee5e9e7f248d0d94161c2c3e27340a522825b2 7.3/updates-testing/i386/mozilla-mail-1.4.2-2.1.0.legacy.1.i386.rpm ea018091469857131f1c78e296e3e7d6619783bb 7.3/updates-testing/i386/mozilla-nspr-1.4.2-2.1.0.legacy.1.i386.rpm 163f47ff39ce8cad7ca7533c69fab1e213ef73b7 7.3/updates-testing/i386/mozilla-nspr-devel-1.4.2-2.1.0.legacy.1.i386.rpm b956f5a47f52d1ff830ce9f858d393742849c3df 7.3/updates-testing/i386/mozilla-nss-1.4.2-2.1.0.legacy.1.i386.rpm 326828da345d70c4c580c3403343124bed7eab1e 7.3/updates-testing/i386/mozilla-nss-devel-1.4.2-2.1.0.legacy.1.i386.rpm 80d131ed4d9194c22438288ace539c18027594e8 7.3/updates-testing/SRPMS/galeon-1.2.13-0.2.2.legacy.src.rpm f66de028a8b522e3a88dd338bfc6ea99a4f5a7c5 7.3/updates-testing/i386/galeon-1.2.13-0.2.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) iD8DBQFA0bF04v2HLvE71NURAs0iAJwMnZoB+Vbuzm/Sn1mN5IHr0HY44wCfb8yR OkDI8K3gHRTIOu8KPCFboQA= =/AXu -----END PGP SIGNATURE----- From davej at redhat.com Thu Jun 17 14:58:37 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 17 Jun 2004 15:58:37 +0100 Subject: another RHL9 kernel patch. In-Reply-To: <1087482359.17439.1.camel@delerium.codemonkey.org.uk> References: <20040617110345.GA5723@redhat.com> <20040617141922.GX11946@tirian.magd.ox.ac.uk> <1087482359.17439.1.camel@delerium.codemonkey.org.uk> Message-ID: <1087484317.19785.0.camel@delerium.codemonkey.org.uk> On Thu, 2004-06-17 at 15:25, Dave Jones wrote: > On Thu, 2004-06-17 at 15:19, Dominic Hargreaves wrote: > > On Thu, Jun 17, 2004 at 12:03:45PM +0100, Dave Jones wrote: > > > There's a nasty memory leak fixed in FC1 which should have been > > > backported to RHL9, as its user exploitable, and can be considered > > > a local DoS. This was CAN-2004-0427 > > > > Cheers for the heads up. Plus there's this thing appeared on bugtraq > > about an i2c vulnerability. Ho hum. > > That looks bogus. You will however likely need these too. ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 I'm just rebuilding the FC1 update with these added. Dave From jkeating at j2solutions.net Thu Jun 17 15:07:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 17 Jun 2004 08:07:41 -0700 Subject: another RHL9 kernel patch. In-Reply-To: <1087484317.19785.0.camel@delerium.codemonkey.org.uk> References: <20040617110345.GA5723@redhat.com> <1087482359.17439.1.camel@delerium.codemonkey.org.uk> <1087484317.19785.0.camel@delerium.codemonkey.org.uk> Message-ID: <200406170807.41285.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 17 June 2004 07:58, Dave Jones wrote: > You will however likely need these too. > ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 > > I'm just rebuilding the FC1 update with these added. > > ????????Dave Thanks Dave. We'll add these to our pending kernel for 7.3/9. - -- 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) iD8DBQFA0bO94v2HLvE71NURApMNAJsEnrxvdb329kBduhs4MtXMbYCjWwCgnKz7 JSzVm9RAOeT2s8d5Egj10/4= =d98/ -----END PGP SIGNATURE----- From dom at earth.li Thu Jun 17 15:46:07 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 17 Jun 2004 16:46:07 +0100 Subject: another RHL9 kernel patch. In-Reply-To: <1087484317.19785.0.camel@delerium.codemonkey.org.uk> References: <20040617110345.GA5723@redhat.com> <20040617141922.GX11946@tirian.magd.ox.ac.uk> <1087482359.17439.1.camel@delerium.codemonkey.org.uk> <1087484317.19785.0.camel@delerium.codemonkey.org.uk> Message-ID: <20040617154607.GY11946@tirian.magd.ox.ac.uk> On Thu, Jun 17, 2004 at 03:58:37PM +0100, Dave Jones wrote: > You will however likely need these too. > ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 Do you happen to know if there are CAN numbers, or any other references, for these yet? Thanks, Dominic. From davej at redhat.com Thu Jun 17 16:03:41 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 17 Jun 2004 17:03:41 +0100 Subject: another RHL9 kernel patch. In-Reply-To: <20040617154607.GY11946@tirian.magd.ox.ac.uk> References: <20040617110345.GA5723@redhat.com> <20040617141922.GX11946@tirian.magd.ox.ac.uk> <1087482359.17439.1.camel@delerium.codemonkey.org.uk> <1087484317.19785.0.camel@delerium.codemonkey.org.uk> <20040617154607.GY11946@tirian.magd.ox.ac.uk> Message-ID: <1087488221.22399.8.camel@delerium.codemonkey.org.uk> On Thu, 2004-06-17 at 16:46, Dominic Hargreaves wrote: > On Thu, Jun 17, 2004 at 03:58:37PM +0100, Dave Jones wrote: > > > You will however likely need these too. > > ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 > > Do you happen to know if there are CAN numbers, or any other references, > for these yet? Yup, sorry.. CAN-2004-0495 for the lot. FC1 changelog entry was.. "Numerous userspace pointer reference bugs found with the sparse tool by Al Viro" hope this helps. Dave From michal at harddata.com Thu Jun 17 16:04:46 2004 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 17 Jun 2004 10:04:46 -0600 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <200406170900.36100.simon@nzservers.com>; from simon@nzservers.com on Thu, Jun 17, 2004 at 09:00:36AM -0500 References: <20040616200430.GT11946@tirian.magd.ox.ac.uk> <200406170900.36100.simon@nzservers.com> Message-ID: <20040617100446.A9693@mail.harddata.com> On Thu, Jun 17, 2004 at 09:00:36AM -0500, Simon Weller wrote: > On Wednesday 16 June 2004 03:04 pm, Dominic Hargreaves wrote: > > > > I put out kernels that fix this yesterday: see > > . The rh7 kernels > > are suitable for 8.x also. > > We've been running the smp build on a 7.3 box for about a day now with > moderate load, and it seems to be nice and stable. I have these running on four Athlon machines (with substantial differences in hardware underneath) and so far everything is just fine. But I guess that there will be the next round of test kernels really-soon-now. :-) Michal From dom at earth.li Thu Jun 17 16:08:44 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 17 Jun 2004 17:08:44 +0100 Subject: New Kernel Crash-Exploit discovered In-Reply-To: References: Message-ID: <20040617160844.GZ11946@tirian.magd.ox.ac.uk> On Wed, Jun 16, 2004 at 08:53:01PM +0100, Jon Peatfield wrote: > Now for the bit people might not like, the FP exception isn't the only > patch in there since I was already about to roll out a new kernel > anyway with the following trond NFS server patch (for talking to OSX > 10.3 and FreeBSD clients): > > http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif Can the list please give some opinions on whether this fix should be added into the next .legacy kernel which I'm preparing? I'm assuming that the patch has been fairly well tested by now. As always, there is a fine line between adding functionality which could come with it more bugs, and providing wanted fixes. We really really need to get this one out of the door in the next week or so, I think, otherwise we are just going to get left behind with the next round of inevitable fixes. Cheers, Dominic. From michal at harddata.com Thu Jun 17 16:17:38 2004 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 17 Jun 2004 10:17:38 -0600 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040617160844.GZ11946@tirian.magd.ox.ac.uk>; from dom@earth.li on Thu, Jun 17, 2004 at 05:08:44PM +0100 References: <20040617160844.GZ11946@tirian.magd.ox.ac.uk> Message-ID: <20040617101738.B9693@mail.harddata.com> On Thu, Jun 17, 2004 at 05:08:44PM +0100, Dominic Hargreaves wrote: > On Wed, Jun 16, 2004 at 08:53:01PM +0100, Jon Peatfield wrote: > > > > > http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif > > I'm assuming > that the patch has been fairly well tested by now. As always, there is a > fine line between adding functionality which could come with it more > bugs, and providing wanted fixes. This one looks to me like a bug fix in a protocol implementation and not a new functionality. I would be for it. Michal From simon at nzservers.com Thu Jun 17 16:41:05 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 17 Jun 2004 11:41:05 -0500 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040617160844.GZ11946@tirian.magd.ox.ac.uk> References: <20040617160844.GZ11946@tirian.magd.ox.ac.uk> Message-ID: <200406171141.05780.simon@nzservers.com> On Thursday 17 June 2004 11:08 am, Dominic Hargreaves wrote: > On Wed, Jun 16, 2004 at 08:53:01PM +0100, Jon Peatfield wrote: > > Now for the bit people might not like, the FP exception isn't the only > > patch in there since I was already about to roll out a new kernel > > anyway with the following trond NFS server patch (for talking to OSX > > 10.3 and FreeBSD clients): > > > > > > http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03 > >-fix_osx.dif > > Can the list please give some opinions on whether this fix should be > added into the next .legacy kernel which I'm preparing? I'm assuming > that the patch has been fairly well tested by now. As always, there is a > fine line between adding functionality which could come with it more > bugs, and providing wanted fixes. We really really need to get this one > out of the door in the next week or so, I think, otherwise we are just > going to get left behind with the next round of inevitable fixes. My feeling is to put this patch on the back burner and get the latest legacy out as soon as people are happy with the QA. The reason I say this is the FPU exception loop DOS is a nasty one for every company out there running shared webhosting servers with any kind of user functionality. I know most companies don't offer shell access (and rightly so), but with the exec(), system() function(s) et al in perl and php, and the fact the exception can be triggered by any user makes the abuse potential a rather broad problem. If we start rolling in new noncritical patches now, especially ones that probably aren't going to able to be tested that quickly, we could push the next .legacy kernel out to at least a couple of weeks. My 2 cents. regards, Simon > > Cheers, > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From pmatilai at welho.com Thu Jun 17 16:46:58 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 17 Jun 2004 19:46:58 +0300 Subject: does fedoralegacy depend on fedora.us? In-Reply-To: <40C4C4EE.1090308@zope.com> References: <200406071133.04002.jkeating@j2solutions.net> <40C4C4EE.1090308@zope.com> Message-ID: <1087490817.6817.25.camel@weasel.net.laiskiainen.org> On Mon, 2004-06-07 at 22:41, Tres Seaver wrote: > Jesse Keating wrote: > > On Monday 07 June 2004 11:26, Joe Pruett wrote: > > > >>since there still isn't an official apt or yum for fedora legacy on > >>rh9 boxes, we are instructed to use the fedora.us version. further, > >>we are only instructed to add the fedoralegacy.org url to the > >>sources.list file and not to comment out the fedora.us urls (or the > >>macromedia ones in sources.list.d). is this an oversight in the docs > >>(like not telling us to install the fedora legacy key)? or are you > >>relying on the other rpms that fedora.us would install (10 packages > >>that i see via apt-get -s upgrade)? i have assumed this is an > >>oversight and not installed the fedora.us rpms, but clarification > >>would be good, as well as updating the docs. > > > > > > Oversight. We absolutely do NOT depend on Fedora.us. A 9 version of > > yum is in QA mode, apt needs some love. > > Why not just use the apt from freshrpms? It lacks things like GPG-signature verification, automated updating of kernels and various other nice things that are in fedora.us apt (the current one for FC1 and FC2 that is) - Panu - From J.S.Peatfield at damtp.cam.ac.uk Thu Jun 17 17:24:29 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Thu, 17 Jun 2004 18:24:29 +0100 Subject: New Kernel Crash-Exploit discovered Message-ID: > > Now for the bit people might not like, the FP exception isn't the only > > patch in there since I was already about to roll out a new kernel > > anyway with the following trond NFS server patch (for talking to OSX > > 10.3 and FreeBSD clients): > > > > http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif > > Can the list please give some opinions on whether this fix should be > added into the next .legacy kernel which I'm preparing? I'm assuming > that the patch has been fairly well tested by now. As always, there is a > fine line between adding functionality which could come with it more > bugs, and providing wanted fixes. We really really need to get this one > out of the door in the next week or so, I think, otherwise we are just > going to get left behind with the next round of inevitable fixes. Well I'm biased of course :-) Note that http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 considers it to be an "enhancement" rather than a bug fix... This patch has already made it into 2.4.x (well at least 2.4.26 has it), judging by the lack of a version in Trond's later directories I'd guess it made it in some time ago. I'll be happy to keep adding that patch myself if it causes anyone to worry too much about QA issues. Talking of QA I'm in the process of installing a (hopefully fairly plain) RH9 box so that I can test the next set of FL kernel updates (and build RH9 binaries on RH9 if that will help at all). It would have finished by now but the first box I brought out of retirement had the PSU explode about 60% through the install... Hmm maybe only having 64M on this box is going to be a problem, I'll see if I can borrow a little more from somewhere... -- Jon From J.S.Peatfield at damtp.cam.ac.uk Fri Jun 18 16:09:56 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Fri, 18 Jun 2004 17:09:56 +0100 Subject: another RHL9 kernel patch. Message-ID: I'm part way through QA'ing the kernel-2.4.20-33.9.legacy.src.rpm on a RH9 box (well I'm doing an rpmbuild on it atm). However I can't find a way to get it to pass the --checksig checks. I'm clearly doing something wrong but I can't see it. rpm --checksig -v kernel-2.4.20-33.9.legacy.src.rpm kernel-2.4.20-33.9.legacy.src.rpm: Header SHA1 digest: OK (78fb849eb14b27ebf6e2cd1c60860a0db1b88e7c) MD5 digest: OK (4cc45153c0860aed29640e2df3dff349) V3 DSA signature: NOKEY, key ID 5178e2a5 shows the package is signed by the unknown keyid 5178e2a5, which http://pgp.mit.edu:11371/pks/lookup?search=0x5178e2a5&op=index says is "Dominic Hargreaves" key (which seems right). If I download the public key from: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5178E2A5 and rpm --import it I get: rpm -qi gpg-pubkey Name : gpg-pubkey Relocations: (not relocateable) Version : 243a1329 Vendor: (none) Release : 3f2be04f Build Date: Fri Jun 18 17:01:26 2004 Install Date: Fri Jun 18 17:01:26 2004 Build Host: localhost Group : Public Keys Source RPM: (none) Size : 0 License: pubkey Signature : (none) Summary : gpg(Dominic Hargreaves ) Description : -----BEGIN PGP PUBLIC KEY BLOCK----- Version: rpm-4.2 (beecrypt-2.2.0) mQGiBDhC5hoRBADyhJEb4DkUavard0thxSDCOBO1Trf9Ev5MboIpb1ZrNTqICEvtjb29hbaJ 5qexUQ2S+Z+tz/A94U2EuX9ijCiW012CQQvXY6mKryQHd6sPkTLolFO0cAQjahVHhjNHurB1 8UmkbqApY6NioukuR45n6bS4/gbAT3+IFa1i4IHqnwCg/9uabGJ2Iuegw7Jg5q2Vvq+ThS0E and the --checksig -v *still* shows that keyid 5178e2a5 is unknown. What am I doing wrong? Should I get the public key some other way? -- Jon From jkeating at j2solutions.net Fri Jun 18 16:12:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 18 Jun 2004 09:12:48 -0700 Subject: another RHL9 kernel patch. In-Reply-To: References: Message-ID: <200406180912.49050.jkeating@j2solutions.net> On Friday 18 June 2004 09:09, Jon Peatfield wrote: > and the --checksig -v *still* shows that keyid 5178e2a5 is unknown. > > What am I doing wrong? Should I get the public key some other way? Try importing it into root's key, or whoever you're running rpm as. -- 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 villegas at math.gatech.edu Fri Jun 18 18:08:35 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Fri, 18 Jun 2004 14:08:35 -0400 Subject: another RHL9 kernel patch. In-Reply-To: <200406180912.49050.jkeating@j2solutions.net> References: <200406180912.49050.jkeating@j2solutions.net> Message-ID: <20040618180835.GD4420@math30192.math.gatech.edu> On Fri, Jun 18, 2004 at 09:12:48AM -0700, Jesse Keating wrote: > On Friday 18 June 2004 09:09, Jon Peatfield wrote: > > and the --checksig -v *still* shows that keyid 5178e2a5 is unknown. > > > > What am I doing wrong? Should I get the public key some other way? > > Try importing it into root's key, or whoever you're running rpm as. No, that was the case for RH 7.x, he is using RH9. I'm not sure why that happened, but I guess that signature you got from mit is signed, and that's a know problem. However you shouldn't need to do that: 1. You can check that the srpm is the same by verifying the sha1sum in the signed message (and verifying the signature of that message containing the sha1sum). 2. I wouldn't import any individual keys to the rpm db just to check that, maybe I'm too paranoid :) 3. When the rpm is released it will be signed with the Fedora Legacy Key, and as long as that works you're ok. Carlos From jkeating at j2solutions.net Fri Jun 18 18:33:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 18 Jun 2004 11:33:48 -0700 Subject: Fedora Legacy credited w/ libpng update for FC1/2 Message-ID: <200406181133.50925.jkeating@j2solutions.net> If you guys haven't seen it yet, the libpng updates that just got pushed for FC1/2 give us credit for them! --------------------------------------------------------------------- Update Information: During an audit of Red Hat Linux updates, the Fedora Legacy team found a security issue in libpng that had not been fixed in Fedora Core. An attacker could carefully craft a PNG file in such a way that it would cause an application linked to libpng to crash or potentially execute arbitrary code when opened by a victim. Way to go guys! -- 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 dwb7 at ccmr.cornell.edu Fri Jun 18 20:11:07 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Fri, 18 Jun 2004 16:11:07 -0400 Subject: gdm background images gone Message-ID: <20040618201107.GA22305@ccmr.cornell.edu> Well... after updating several rpms yesterday including gdk-pixbuf and libxml2, it seems that upon an X restart the background image at the login screen no longer appears (bg image is specificied in /etc/X11/gdm/gdm.conf and the bg image is a .png) I have yet to try a reboot. Anyone else noticing this? Thoughts? -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7 at ccmr.cornell.edu ******************************** From jkeating at j2solutions.net Fri Jun 18 20:14:29 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 18 Jun 2004 13:14:29 -0700 Subject: gdm background images gone In-Reply-To: <20040618201107.GA22305@ccmr.cornell.edu> References: <20040618201107.GA22305@ccmr.cornell.edu> Message-ID: <200406181314.29215.jkeating@j2solutions.net> On Friday 18 June 2004 13:11, David Botsch wrote: > Well... after updating several rpms yesterday including gdk-pixbuf > and libxml2, it seems that upon an X restart the background image at > the login screen no longer appears (bg image is specificied in > /etc/X11/gdm/gdm.conf and the bg image is a .png) > > I have yet to try a reboot. > > Anyone else noticing this? Thoughts? Could be that the png lib isn't listed as a buildreq, and thus gtk-pixbuf doesn't have the capability of loading it. I'll take a look, if you would please add the above comments to the bugzilla report? -- 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 skvidal at phy.duke.edu Fri Jun 18 20:20:26 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 18 Jun 2004 16:20:26 -0400 Subject: gdm background images gone In-Reply-To: <200406181314.29215.jkeating@j2solutions.net> References: <20040618201107.GA22305@ccmr.cornell.edu> <200406181314.29215.jkeating@j2solutions.net> Message-ID: <1087590025.11223.12.camel@opus> On Fri, 2004-06-18 at 16:14, Jesse Keating wrote: > On Friday 18 June 2004 13:11, David Botsch wrote: > > Well... after updating several rpms yesterday including gdk-pixbuf > > and libxml2, it seems that upon an X restart the background image at > > the login screen no longer appears (bg image is specificied in > > /etc/X11/gdm/gdm.conf and the bg image is a .png) > > > > I have yet to try a reboot. > > > > Anyone else noticing this? Thoughts? > > Could be that the png lib isn't listed as a buildreq, and thus > gtk-pixbuf doesn't have the capability of loading it. I'll take a > look, if you would please add the above comments to the bugzilla > report? That's exactly it. I think I encountered that here, too. -sv From pmatilai at welho.com Sat Jun 19 13:43:52 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 19 Jun 2004 16:43:52 +0300 Subject: another RHL9 kernel patch. In-Reply-To: References: Message-ID: <1087652632.2992.15.camel@weasel.net.laiskiainen.org> On Fri, 2004-06-18 at 19:09, Jon Peatfield wrote: > I'm part way through QA'ing the kernel-2.4.20-33.9.legacy.src.rpm on a > RH9 box (well I'm doing an rpmbuild on it atm). > > However I can't find a way to get it to pass the --checksig checks. > I'm clearly doing something wrong but I can't see it. > > rpm --checksig -v kernel-2.4.20-33.9.legacy.src.rpm > kernel-2.4.20-33.9.legacy.src.rpm: > Header SHA1 digest: OK (78fb849eb14b27ebf6e2cd1c60860a0db1b88e7c) > MD5 digest: OK (4cc45153c0860aed29640e2df3dff349) > V3 DSA signature: NOKEY, key ID 5178e2a5 > > shows the package is signed by the unknown keyid 5178e2a5, which > http://pgp.mit.edu:11371/pks/lookup?search=0x5178e2a5&op=index says is > "Dominic Hargreaves" key (which seems right). If I download the > public key from: > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5178E2A5 > > and rpm --import it I get: > > rpm -qi gpg-pubkey > > > Name : gpg-pubkey Relocations: (not relocateable) > Version : 243a1329 Vendor: (none) > Release : 3f2be04f Build Date: Fri Jun 18 17:01:26 2004 > Install Date: Fri Jun 18 17:01:26 2004 Build Host: localhost > Group : Public Keys Source RPM: (none) > Size : 0 License: pubkey > Signature : (none) > Summary : gpg(Dominic Hargreaves ) > Description : > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: rpm-4.2 (beecrypt-2.2.0) > > mQGiBDhC5hoRBADyhJEb4DkUavard0thxSDCOBO1Trf9Ev5MboIpb1ZrNTqICEvtjb29hbaJ > 5qexUQ2S+Z+tz/A94U2EuX9ijCiW012CQQvXY6mKryQHd6sPkTLolFO0cAQjahVHhjNHurB1 > 8UmkbqApY6NioukuR45n6bS4/gbAT3+IFa1i4IHqnwCg/9uabGJ2Iuegw7Jg5q2Vvq+ThS0E > > > and the --checksig -v *still* shows that keyid 5178e2a5 is unknown. > > What am I doing wrong? Should I get the public key some other way? Bitten by https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90952, nothing wrong in what you do. - Panu - From dom at earth.li Mon Jun 21 16:44:49 2004 From: dom at earth.li (Dominic Hargreaves) Date: Mon, 21 Jun 2004 17:44:49 +0100 Subject: Fedora Test Update Notification: libpng In-Reply-To: <200406162107.13486.jkeating@j2solutions.net> References: <200406162107.13486.jkeating@j2solutions.net> Message-ID: <20040621164449.GG11946@tirian.magd.ox.ac.uk> On Wed, Jun 16, 2004 at 09:07:13PM -0700, Jesse Keating wrote: > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/redhat/ > > 20619750b9d6f5fb4fa4cfaad6ff31f3280372bb > 7.3/updates-testing/SRPMS/libpng-1.0.14-0.7x.5.legacy.src.rpm > 5a1ff70a2deb721b370bbcacff4ef3a1ee3f79ce > 7.3/updates-testing/i386/libpng-1.0.14-0.7x.5.legacy.i386.rpm Missing references to libpng-devel package. Cheers, Dominic. From jkeating at j2solutions.net Mon Jun 21 16:50:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 21 Jun 2004 09:50:12 -0700 Subject: Fedora Test Update Notification: libpng In-Reply-To: <20040621164449.GG11946@tirian.magd.ox.ac.uk> References: <200406162107.13486.jkeating@j2solutions.net> <20040621164449.GG11946@tirian.magd.ox.ac.uk> Message-ID: <200406210950.16358.jkeating@j2solutions.net> On Monday 21 June 2004 09:44, Dominic Hargreaves wrote: > Missing references to libpng-devel package. > > Cheers, > > Dominic. d'oh! The python script that generates these notices doesn't yet have the ability to look at a .src.rpm and determine what all binary rpms are built from it. SO I have to checksum those by hand. Libpng needs to be rebuilt/repushed to updates-testing anyway so the next notice will have this. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 Tue Jun 22 12:13:19 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 22 Jun 2004 13:13:19 +0100 Subject: Kernel package status Message-ID: <20040622121318.GI11946@tirian.magd.ox.ac.uk> Hi, The latest kernel package has been up for QA for a couple of days - this fixes a whopping 16 separate issues compared to the previous FL update. It would be really excellent to get this released ASAP to stop it snowballing - no doubt there will be further kernel issues discovered and announced in the coming months, and some of these issues are now already three months old! There has been a fair amount of QA on intermediate versions so I would say that we are almost in a position to push to updates-testing. I've had all the versions I've built work without problem on my workstation here. If we could get one more QA tester for the current kernel revision (2.4.20-34.x) I think we'll be there. Jesse, could I ask you to push this package up the priority list please - it would be great to get updates-testing packages out by the end of the week. The bugzilla entry is Thanks, Dominic. From michal at harddata.com Tue Jun 22 14:01:56 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 22 Jun 2004 08:01:56 -0600 Subject: Kernel package status In-Reply-To: <20040622121318.GI11946@tirian.magd.ox.ac.uk>; from dom@earth.li on Tue, Jun 22, 2004 at 01:13:19PM +0100 References: <20040622121318.GI11946@tirian.magd.ox.ac.uk> Message-ID: <20040622080156.A23002@mail.harddata.com> On Tue, Jun 22, 2004 at 01:13:19PM +0100, Dominic Hargreaves wrote: > It would be really excellent to get this released ASAP to stop it > snowballing I agree. I have this kernel running on few machines, including some "critical" ones, and I do not see any regressions. Hardly any could be reasonably expected due to a nature of patches. Michal From rmy at tigress.co.uk Tue Jun 22 15:51:33 2004 From: rmy at tigress.co.uk (Ron Yorston) Date: Tue, 22 Jun 2004 16:51:33 +0100 (BST) Subject: Kernel package status Message-ID: <200406221551.QAA10424@internal.tigress.co.uk> I've been having a look at the 34.7.legacy kernel. Can someone explain why the e1000 patch differs from that in Fedora Core 1's 2.4.22-1.2194 kernel? Ron 34.7.legacy --- 1.28/drivers/net/e1000/e1000_ethtool.c 2004-06-17 10:21:22 -07:00 +++ 1.29/drivers/net/e1000/e1000_ethtool.c 2004-06-17 10:21:22 -07:00 @@ -1514,6 +1514,9 @@ if(copy_from_user(®s, addr, sizeof(regs))) return -EFAULT; + memset(regs_buff, 0, sizeof(regs_buff)); + if (regs.len > E1000_REGS_LEN) + regs.len = E1000_REGS_LEN; e1000_ethtool_gregs(adapter, ®s, regs_buff); if(copy_to_user(addr, ®s, sizeof(regs))) return -EFAULT; 2194.nptl --- linux-2.4.22/drivers/net/e1000/e1000_ethtool.c~ 2004-06-04 12:58:57.907123544 +0100 +++ linux-2.4.22/drivers/net/e1000/e1000_ethtool.c 2004-06-04 13:00:08.752353432 +0100 @@ -1351,6 +1351,9 @@ if(copy_from_user(®s, addr, sizeof(regs))) return -EFAULT; + memset(regs_buff, 0, sizeof(regs_buff)); + if (regs.len > E1000_REGS_LEN * sizeof(uint32_t)) + regs.len = E1000_REGS_LEN * sizeof(uint32_t); e1000_ethtool_gregs(adapter, ®s, regs_buff); if(copy_to_user(addr, ®s, sizeof(regs))) return -EFAULT; From dom at earth.li Tue Jun 22 16:40:09 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 22 Jun 2004 17:40:09 +0100 Subject: Kernel package status In-Reply-To: <200406221551.QAA10424@internal.tigress.co.uk> References: <200406221551.QAA10424@internal.tigress.co.uk> Message-ID: <20040622164009.GN11946@tirian.magd.ox.ac.uk> On Tue, Jun 22, 2004 at 04:51:33PM +0100, Ron Yorston wrote: > I've been having a look at the 34.7.legacy kernel. Can someone explain > why the e1000 patch differs from that in Fedora Core 1's 2.4.22-1.2194 > kernel? I'm not sure. I sourced the patch from bitkeeper, and it matches that in the redhat bugzilla (although they didn't use it in the end, rather upgrading the driver itself). Unfortunately I'm not able to test it on a box with an e1000. My untrained eye can't spot the reason for the change in the source files between 2.4.20 and recent 2.4 (where recent is just before the new version that went into bitkeeper shortly after that patch). Am I missing a particular change in FC or Redhat that causes this descrepancy? Well spotted, though :) Cheers, Dominic. From dwb7 at ccmr.cornell.edu Tue Jun 22 16:50:57 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Tue, 22 Jun 2004 12:50:57 -0400 Subject: Kernel package status In-Reply-To: <20040622164009.GN11946@tirian.magd.ox.ac.uk>; from dom@earth.li on Tue, Jun 22, 2004 at 12:40:09 -0400 References: <200406221551.QAA10424@internal.tigress.co.uk> <20040622164009.GN11946@tirian.magd.ox.ac.uk> Message-ID: <20040622165057.GC27926@domino.ccmr.cornell.edu> While we have plenty of boxes with e1000s, we have found that, in general, the driver in the kernel doesn't work with the card. With certain revisions of certain cards it will, but with most, we either have to upgrade to the latest driver avail. from Intel or downgrade to a version 3 driver (depending once again, on which card revision is in the particular box). On 2004.06.22 12:40 Dominic Hargreaves wrote: > On Tue, Jun 22, 2004 at 04:51:33PM +0100, Ron Yorston wrote: > > I've been having a look at the 34.7.legacy kernel. Can someone > explain > > why the e1000 patch differs from that in Fedora Core 1's > 2.4.22-1.2194 > > kernel? > > I'm not sure. I sourced the patch from bitkeeper, and it matches that > in > the redhat bugzilla (although they didn't use it in the end, rather > upgrading the driver itself). Unfortunately I'm not able to test it on > a > box with an e1000. > > My untrained eye can't spot the reason for the change in the source > files between 2.4.20 and recent 2.4 (where recent is just before the > new version that went into bitkeeper shortly after that patch). Am I > missing a particular change in FC or Redhat that causes this > descrepancy? > > Well spotted, though :) > > Cheers, > > Dominic. > > > -- > 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 Tue Jun 22 22:12:11 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 22 Jun 2004 18:12:11 -0400 Subject: Kernel package status In-Reply-To: <200406221551.QAA10424@internal.tigress.co.uk> References: <200406221551.QAA10424@internal.tigress.co.uk> Message-ID: <1087942331.9057.1.camel@mdlinux> On Tue, 2004-06-22 at 11:51, Ron Yorston wrote: > I've been having a look at the 34.7.legacy kernel. Can someone explain > why the e1000 patch differs from that in Fedora Core 1's 2.4.22-1.2194 > kernel? It looks like the patch was modified to work on 64-bit architectures, as Fedora supports a couple of them. I don't think it makes a difference on 32-bit machines. Marc. From simon at nzservers.com Wed Jun 23 00:03:58 2004 From: simon at nzservers.com (Simon Weller) Date: Tue, 22 Jun 2004 19:03:58 -0500 Subject: Kernel package status In-Reply-To: <20040622121318.GI11946@tirian.magd.ox.ac.uk> References: <20040622121318.GI11946@tirian.magd.ox.ac.uk> Message-ID: <200406221903.58187.simon@nzservers.com> On Tuesday 22 June 2004 07:13 am, Dominic Hargreaves wrote: > Hi, > > The latest kernel package has been up for QA for a couple of days - this > fixes a whopping 16 separate issues compared to the previous FL update. > It would be really excellent to get this released ASAP to stop it > snowballing - no doubt there will be further kernel issues discovered > and announced in the coming months, and some of these issues are now > already three months old! > > There has been a fair amount of QA on intermediate versions so I would > say that we are almost in a position to push to updates-testing. I've > had all the versions I've built work without problem on my workstation > here. > > If we could get one more QA tester for the current kernel revision > (2.4.20-34.x) I've just rolling out 2.4.20-34.x SMP on a 7.3 box and I'll report on it tomorrow. regards, Simon > I think we'll be there. Jesse, could I ask you to push > this package up the priority list please - it would be great to get > updates-testing packages out by the end of the week. > > The bugzilla entry is > > > Thanks, > > Dominic. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From michal at harddata.com Wed Jun 23 00:44:10 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 22 Jun 2004 18:44:10 -0600 Subject: Kernel package status In-Reply-To: <1087942331.9057.1.camel@mdlinux>; from marcdeslauriers@videotron.ca on Tue, Jun 22, 2004 at 06:12:11PM -0400 References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> Message-ID: <20040622184410.A10155@mail.harddata.com> On Tue, Jun 22, 2004 at 06:12:11PM -0400, Marc Deslauriers wrote: > On Tue, 2004-06-22 at 11:51, Ron Yorston wrote: > > I've been having a look at the 34.7.legacy kernel. Can someone explain > > why the e1000 patch differs from that in Fedora Core 1's 2.4.22-1.2194 > > kernel? > > It looks like the patch was modified to work on 64-bit architectures, as > Fedora supports a couple of them. No, it does not look that way. > I don't think it makes a difference on 32-bit machines. Actually I think that it does and it fixes the real bug. Looking at this code E1000_REGS_LEN * sizeof(uint32_t) is the same as a sizeof(regs_buff) buffer and a little bit down regs.len is used in copy_to_user() call which allows user space to peek into a content of this buffer. We do not want this a value of regs.len to be too big. Possibly if this code would look instead like this: memset(regs_buff, 0, sizeof(regs_buff)); if (regs.len > sizeof(regs_buff)) regs.len = sizeof(regs_buff); then this would be quite a bit clearer. Without fixing that copy_to_user() will use only up to a quarter of regs_buff buffer and this has nothing to do with 32/64-bit issues. Possibly not a very critical bug (I do not know that really) but a bug nevertheless. It does not look that regs.len is used very extensively. Presumably it is set in a preceding copy_from_user() call and not used really in any other place. Michal From marcdeslauriers at videotron.ca Wed Jun 23 01:13:44 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 22 Jun 2004 21:13:44 -0400 Subject: Kernel package status In-Reply-To: <20040622184410.A10155@mail.harddata.com> References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> <20040622184410.A10155@mail.harddata.com> Message-ID: <1087953224.9673.0.camel@mdlinux> On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > > It looks like the patch was modified to work on 64-bit architectures, as > > Fedora supports a couple of them. > > No, it does not look that way. Argh...disregard my previous post...I think the radiation from my monitor is affecting my brain. :) Marc. From hbo at egbok.com Wed Jun 23 01:39:03 2004 From: hbo at egbok.com (Howard Owen) Date: Tue, 22 Jun 2004 18:39:03 -0700 (PDT) Subject: Kernel package status In-Reply-To: <20040622121318.GI11946@tirian.magd.ox.ac.uk> Message-ID: I have all your patches applied to a customer's internal version of Red Hat 7.3. They all applied without a problem, though the e1000 patch had an offset of over 1000 lines. The modified SRPM built without error. I'm currently running the kernel on my XW4100 workstation. I'm looking to install the kernel on a system with an e1000 tomorrow. I realize this report has limited value since the patches are applied to a different source base, but the fact that they applied so smoothly in the different environment should tell you something. 8) I'll be installing the FL kernel tonight on a home system. On Tue, 22 Jun 2004, Dominic Hargreaves wrote: > Hi, > > The latest kernel package has been up for QA for a couple of days - this > fixes a whopping 16 separate issues compared to the previous FL update. > It would be really excellent to get this released ASAP to stop it > snowballing - no doubt there will be further kernel issues discovered > and announced in the coming months, and some of these issues are now > already three months old! > > There has been a fair amount of QA on intermediate versions so I would > say that we are almost in a position to push to updates-testing. I've > had all the versions I've built work without problem on my workstation > here. > > If we could get one more QA tester for the current kernel revision > (2.4.20-34.x) I think we'll be there. Jesse, could I ask you to push > this package up the priority list please - it would be great to get > updates-testing packages out by the end of the week. > > The bugzilla entry is > > > Thanks, > > Dominic. > > > -- > 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 J.S.Peatfield at damtp.cam.ac.uk Wed Jun 23 02:25:25 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Wed, 23 Jun 2004 03:25:25 +0100 Subject: Kernel package status Message-ID: I've only ot one e1000 which doesn't work with the e100 driver present in the RedHat-9 (and FL) kernels. For that one updating to the very latest version from Intel works fine for me (5.2.52 which was latest when I needed a newer version at least)... Of course I just upgraded the kernel on this box (to one based on the FL kernel srpm), and forgot it needed an extra e1000 driver so it didn't come back... Pity it was where my rpm repository was living... :-( As a result 40+ machines failed to update their kernels automatically tonight (I did them by hand since I came in to fix the dead server). So far 89 have been rebooted and are back running. The rest are scheduled to reboot at ~5am so with luck I'll have ~200 systems running kernels which are almost identical to 2.4.20-34.7.legacy (with the NFS server patch added)... I'm fairly happy with it (but maybe next time I'll update the e1000 driver too!) -- Jon From marcdeslauriers at videotron.ca Wed Jun 23 03:16:29 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 22 Jun 2004 23:16:29 -0400 Subject: Kernel package status In-Reply-To: <20040622184410.A10155@mail.harddata.com> References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> <20040622184410.A10155@mail.harddata.com> Message-ID: <1087960589.9907.14.camel@mdlinux> On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > Possibly not a very critical bug (I do not know that really) > but a bug nevertheless. It does not look that regs.len is > used very extensively. Presumably it is set in a preceding > copy_from_user() call and not used really in any other place. Ethtool is expecting bytes there, so it looks to me that the revised patch is necessary for "ethtool -d" to return correct data... What do you think, Michal? Marc. From michal at harddata.com Wed Jun 23 04:59:36 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 22 Jun 2004 22:59:36 -0600 Subject: Kernel package status In-Reply-To: <1087960589.9907.14.camel@mdlinux>; from marcdeslauriers@videotron.ca on Tue, Jun 22, 2004 at 11:16:29PM -0400 References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> <20040622184410.A10155@mail.harddata.com> <1087960589.9907.14.camel@mdlinux> Message-ID: <20040622225936.A10435@mail.harddata.com> On Tue, Jun 22, 2004 at 11:16:29PM -0400, Marc Deslauriers wrote: > On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > > Possibly not a very critical bug (I do not know that really) > > but a bug nevertheless. It does not look that regs.len is > > used very extensively. Presumably it is set in a preceding > > copy_from_user() call and not used really in any other place. > > Ethtool is expecting bytes there, so it looks to me that the revised > patch is necessary for "ethtool -d" to return correct data... > > What do you think, Michal? Yes, that I think I wrote. :-) Does not matter if E1000_REGS_LEN * sizeof(uint32_t) or sizeof(regs_buff) is used this comes to the same thing. Which way this is done is a matter of taste. The real point is that copy_{from,to}_user() functions expect a size argument in bytes. Michal From rmy at tigress.co.uk Wed Jun 23 13:41:30 2004 From: rmy at tigress.co.uk (Ron Yorston) Date: Wed, 23 Jun 2004 14:41:30 +0100 (BST) Subject: Kernel package status Message-ID: <200406231341.OAA11585@internal.tigress.co.uk> I've built a kernel from Dominic's SRPM and have installed it on a machine with an 82540EM ethernet controller. This is working with the standard e1000 driver, but ethtool -d only shows 32 bytes of data. With the previous kernel (2.4.18-18.7.x) I got 128 bytes. So it seems that the patch from FC1 is correct. I'm currently building a new kernel with that patch. Meanwhile, # uptime 2:36pm up 31 min, 1 user, load average: 0.30, 0.41, 0.33 it look OK... Ron From dom at earth.li Wed Jun 23 13:58:30 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 23 Jun 2004 14:58:30 +0100 Subject: Kernel package status In-Reply-To: <200406231341.OAA11585@internal.tigress.co.uk> References: <200406231341.OAA11585@internal.tigress.co.uk> Message-ID: <20040623135829.GC30964@tirian.magd.ox.ac.uk> On Wed, Jun 23, 2004 at 02:41:30PM +0100, Ron Yorston wrote: > I've built a kernel from Dominic's SRPM and have installed it on a > machine with an 82540EM ethernet controller. This is working with > the standard e1000 driver, but ethtool -d only shows 32 bytes of > data. With the previous kernel (2.4.18-18.7.x) I got 128 bytes. > So it seems that the patch from FC1 is correct. I'm currently > building a new kernel with that patch. Okay, thanks for that. I'll push out new SRPMs later today with the modified patch then. Cheers, Dominic. From davej at redhat.com Thu Jun 24 01:44:30 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 24 Jun 2004 02:44:30 +0100 Subject: Kernel package status In-Reply-To: <1087960589.9907.14.camel@mdlinux> References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> <20040622184410.A10155@mail.harddata.com> <1087960589.9907.14.camel@mdlinux> Message-ID: <20040624014430.GA10990@redhat.com> On Tue, Jun 22, 2004 at 11:16:29PM -0400, Marc Deslauriers wrote: > On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > > Possibly not a very critical bug (I do not know that really) > > but a bug nevertheless. It does not look that regs.len is > > used very extensively. Presumably it is set in a preceding > > copy_from_user() call and not used really in any other place. > > Ethtool is expecting bytes there, so it looks to me that the revised > patch is necessary for "ethtool -d" to return correct data... This was the reason I changed it in the Fedora kernel. The version of the patch you have was in the fedora kernel for a while too, I silently fixed it up in the next revision (as it only hit -testing). Looks like you picked it up before I fixed it up. Good job someone was paying attention 8) In future, I'll try and give you a heads up if I change something like that again without making extra changelog entries. Dave From dwb7 at ccmr.cornell.edu Thu Jun 24 15:25:19 2004 From: dwb7 at ccmr.cornell.edu (David Botsch) Date: Thu, 24 Jun 2004 11:25:19 -0400 Subject: Kernel package status In-Reply-To: <20040624014430.GA10990@redhat.com>; from davej@redhat.com on Wed, Jun 23, 2004 at 21:44:30 -0400 References: <200406221551.QAA10424@internal.tigress.co.uk> <1087942331.9057.1.camel@mdlinux> <20040622184410.A10155@mail.harddata.com> <1087960589.9907.14.camel@mdlinux> <20040624014430.GA10990@redhat.com> Message-ID: <20040624152519.GA8887@domino.ccmr.cornell.edu> Other than breaking ethtool, does the patch currently there break anything? On 2004.06.23 21:44 Dave Jones wrote: > On Tue, Jun 22, 2004 at 11:16:29PM -0400, Marc Deslauriers wrote: > > On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > > > Possibly not a very critical bug (I do not know that really) > > > but a bug nevertheless. It does not look that regs.len is > > > used very extensively. Presumably it is set in a preceding > > > copy_from_user() call and not used really in any other place. > > > > Ethtool is expecting bytes there, so it looks to me that the > revised > > patch is necessary for "ethtool -d" to return correct data... > > This was the reason I changed it in the Fedora kernel. > The version of the patch you have was in the fedora kernel for > a while too, I silently fixed it up in the next revision > (as it only hit -testing). Looks like you picked it up before > I fixed it up. Good job someone was paying attention 8) > In future, I'll try and give you a heads up if I change something > like that again without making extra changelog entries. > > Dave > > > -- > 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 simon at nzservers.com Thu Jun 24 15:32:59 2004 From: simon at nzservers.com (Simon Weller) Date: Thu, 24 Jun 2004 10:32:59 -0500 Subject: Kernel package status In-Reply-To: <20040624152519.GA8887@domino.ccmr.cornell.edu> References: <200406221551.QAA10424@internal.tigress.co.uk> <20040624014430.GA10990@redhat.com> <20040624152519.GA8887@domino.ccmr.cornell.edu> Message-ID: <200406241032.59775.simon@nzservers.com> On Thursday 24 June 2004 10:25 am, David Botsch wrote: > Other than breaking ethtool, does the patch currently there break > anything? There was no log on it, so I'm assuming not...having said that I could be very wrong ;-) It does appear just to be an issue with ethtool not getting the returned data back. - Si > > On 2004.06.23 21:44 Dave Jones wrote: > > On Tue, Jun 22, 2004 at 11:16:29PM -0400, Marc Deslauriers wrote: > > > On Tue, 2004-06-22 at 20:44, Michal Jaegermann wrote: > > > > Possibly not a very critical bug (I do not know that really) > > > > but a bug nevertheless. It does not look that regs.len is > > > > used very extensively. Presumably it is set in a preceding > > > > copy_from_user() call and not used really in any other place. > > > > > > Ethtool is expecting bytes there, so it looks to me that the > > > > revised > > > > > patch is necessary for "ethtool -d" to return correct data... > > > > This was the reason I changed it in the Fedora kernel. > > The version of the patch you have was in the fedora kernel for > > a while too, I silently fixed it up in the next revision > > (as it only hit -testing). Looks like you picked it up before > > I fixed it up. Good job someone was paying attention 8) > > In future, I'll try and give you a heads up if I change something > > like that again without making extra changelog entries. > > > > Dave > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Simon Weller LPIC-2, BCIP Systems Engineer NZServers LTD http://www.nzservers.com/ U.S. Branch <- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. - Scott Granneman, Security Focus -> From ba1020 at homie.homelinux.net Mon Jun 28 08:59:53 2004 From: ba1020 at homie.homelinux.net (J=?iso-8859-15?q?=FCrgen=20Schinker?=) Date: Mon, 28 Jun 2004 08:59:53 -0000 Subject: New Kernel Crash-Exploit discovered Message-ID: <20040628085953.D8FF01B902@gate.schinx.net> hi why is there no kernel update via apt? From jonny.strom at netikka.fi Mon Jun 28 11:02:32 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Mon, 28 Jun 2004 14:02:32 +0300 Subject: New Kernel Crash-Exploit discovered In-Reply-To: <20040628085953.D8FF01B902@gate.schinx.net> References: <20040628085953.D8FF01B902@gate.schinx.net> Message-ID: <40DFFAC8.2050106@netikka.fi> J?rgen Schinker wrote: > hi > > why is there no kernel update via apt? > It is still here: http://bugzilla.fedora.us/show_bug.cgi?id=1484 I don't know when there is going to be an relase dose this issue need more QA before going into testing? > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jvergeer at shoprite.co.za Mon Jun 28 11:40:12 2004 From: jvergeer at shoprite.co.za (Johnny Vergeer) Date: Mon, 28 Jun 2004 13:40:12 +0200 Subject: Kernel panic - Redhat 7.3 - 2.4.20-30.7.legacy Message-ID: <6E11DEF3763017499494F085D201CF2A2BDD28@exchange.shoprite.co.za> Hello, I am finding stability problems running the 2.4.20-30.7.legacy kernel on Redhat 7.3. The problems seem to be more prevalent on Intel Bayfield hardware. On a test system, I have updated the BIOS, removed all non essential loadable modules (lm_sensors, scsi-ide) and tried stopping non essential services, but the system will still crash once every 2 days or so. Attached below is the crash information captured via a serial console connection. Is this information useful as is, or should I provide more details? Best Regards johnny [root at SR007777 root]# ksymoops < crash7 ksymoops 2.4.4 on i686 2.4.20-30.7.legacy. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-30.7.legacy/ (default) -m /boot/System.map-2.4.20-30.7.legacy (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (expand_objects): cannot stat(/lib/ext3.o) for ext3 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/jbd.o) for jbd ksymoops: No such file or directory Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object. Trace may not be reliable. Unable to handle kernel paging request at virtual address 0121a620 c0129d0f *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0121a620 ebx: cdc6dba8 ecx: c119bf04 edx: cdc6dba8 esi: c119bee8 edi: c02dfe68 ebp: 0000023b esp: c0867e34 ds: 0018 es: 0018 ss: 0018 Process tar (pid: 32075, stackpage=c0867000) Stack: cec34380 00000203 c1000030 c1057280 00000000 c119bee8 c013230c c119bee8 c02e00ac 00000000 c1267508 00000006 c02dfe68 00000001 c0136707 00000000 c02e045c 0000df2f c013685f 00000000 0002c0ba c012a75d c12f61e0 c02e0458 Call Trace: [] reclaim_page [kernel] 0x39c (0xc0867e4c)) [] fixup_freespace [kernel] 0x37 (0xc0867e6c)) [] __alloc_pages [kernel] 0x7f (0xc0867e7c)) [] add_to_page_cache_unique [kernel] 0x9d (0xc0867e88)) [] generic_file_write [kernel] 0x485 (0xc0867eac)) [] do_generic_file_read [kernel] 0x45e (0xc0867ee8)) [] generic_file_read [kernel] 0x7e (0xc0867f24)) [] ext3_file_write [ext3] 0x22 (0xc0867f3c)) [] sys_write [kernel] 0x96 (0xc0867f5c)) [] filp_open [kernel] 0x53 (0xc0867f74)) [] schedule [kernel] 0x2df (0xc0867f8c)) [] system_call [kernel] 0x33 (0xc0867fc0)) Code: 89 10 c7 06 00 00 00 00 c7 46 04 00 00 00 00 c7 46 08 00 00 >>EIP; c0129d0f <__remove_inode_page+3f/90> <===== Trace; c013230c Trace; c0136707 Trace; c013685f <__alloc_pages+7f/380> Trace; c012a75d Trace; c012d515 Trace; c012b4ae Trace; c012b82e Trace; cf81bbd2 <[ext3].text.start+1b72/af8f> Trace; c013de06 Trace; c013d4f3 Trace; c011589f Trace; c01088c3 Code; c0129d0f <__remove_inode_page+3f/90> 00000000 <_EIP>: Code; c0129d0f <__remove_inode_page+3f/90> <===== 0: 89 10 mov %edx,(%eax) <===== Code; c0129d11 <__remove_inode_page+41/90> 2: c7 06 00 00 00 00 movl $0x0,(%esi) Code; c0129d17 <__remove_inode_page+47/90> 8: c7 46 04 00 00 00 00 movl $0x0,0x4(%esi) Code; c0129d1e <__remove_inode_page+4e/90> f: c7 46 08 00 00 00 00 movl $0x0,0x8(%esi) 2 warnings and 2 errors issued. Results may not be reliable. Disclaimer http://www.shoprite.co.za/disclaimer.html From mfedyk at matchmail.com Mon Jun 28 20:10:09 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Mon, 28 Jun 2004 13:10:09 -0700 Subject: Kernel panic - Redhat 7.3 - 2.4.20-30.7.legacy In-Reply-To: <6E11DEF3763017499494F085D201CF2A2BDD28@exchange.shoprite.co.za> References: <6E11DEF3763017499494F085D201CF2A2BDD28@exchange.shoprite.co.za> Message-ID: <40E07B21.7020705@matchmail.com> Johnny Vergeer wrote: > Attached below is the crash information captured via a serial console > connection. > Is this information useful as is, or should I provide more details? Run memtest86 on the box with one or two passes in "all tests" mode, and check your filesystems to see if there are errors as the oops looks like it's in the filesystem code. Mike From jcw at wilsonet.com Mon Jun 28 22:57:53 2004 From: jcw at wilsonet.com (Jarod Wilson) Date: Mon, 28 Jun 2004 15:57:53 -0700 Subject: ATrpms FL-based kernels Message-ID: <200406281557.57442.jcw@wilsonet.com> There are new kernels available for download and install on ATrpms.net (even via apt/yum), based off the 35.x Fedora Legacy kernel srpm. The available kernels include the stock 35.x.legacy versions for convenience, and the usual ATrpms-enhanced versions, with XFS support, v4l2, i2c 2.8.x, 3Ware Escalade drivers and updated LVM added on top of the 35.x sources. Such kernels are available for Red Hat Linux 7.3, 8.0 and 9. http://atrpms.net/name/kernel/ http://atrpms.net/name/kernel-redhat/ Have at 'em, all the variants I've tried work without a problem. -- Jarod C. Wilson, RHCE jcw at wilsonet.com -------------- 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 Mon Jun 28 23:25:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 28 Jun 2004 16:25:06 -0700 Subject: ATrpms FL-based kernels In-Reply-To: <200406281557.57442.jcw@wilsonet.com> References: <200406281557.57442.jcw@wilsonet.com> Message-ID: <200406281625.22625.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 28 June 2004 15:57, Jarod Wilson wrote: > There are new kernels available for download and install on > ATrpms.net (even via apt/yum), based off the 35.x Fedora Legacy > kernel srpm. The available kernels include the stock 35.x.legacy > versions for convenience, and the usual ATrpms-enhanced versions, > with XFS support, v4l2, i2c 2.8.x, 3Ware Escalade drivers and updated > LVM added on top of the 35.x sources. Such kernels are available for > Red Hat Linux 7.3, 8.0 and 9. > > http://atrpms.net/name/kernel/ > http://atrpms.net/name/kernel-redhat/ > > Have at 'em, all the variants I've tried work without a problem. Please remember that these are not Fedora Legacy approved kernels. (: - -- 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) iD8DBQFA4Kji4v2HLvE71NURAkigAJwLmNd96GzIDL0mrMIfg0bLWDHwLwCcD32m LCQnWEzzrPD/yo3EK4LGuek= =HqRm -----END PGP SIGNATURE----- From jcw at wilsonet.com Tue Jun 29 01:21:24 2004 From: jcw at wilsonet.com (Jarod Wilson) Date: Mon, 28 Jun 2004 18:21:24 -0700 Subject: ATrpms FL-based kernels In-Reply-To: <200406281625.22625.jkeating@j2solutions.net> References: <200406281557.57442.jcw@wilsonet.com> <200406281625.22625.jkeating@j2solutions.net> Message-ID: <200406281821.24455.jcw@wilsonet.com> On Monday 28 June 2004 16:25, Jesse Keating wrote: > On Monday 28 June 2004 15:57, Jarod Wilson wrote: > > There are new kernels available for download and install on > > ATrpms.net (even via apt/yum), based off the 35.x Fedora Legacy > > kernel srpm. The available kernels include the stock 35.x.legacy > > versions for convenience, and the usual ATrpms-enhanced versions, > > with XFS support, v4l2, i2c 2.8.x, 3Ware Escalade drivers and updated > > LVM added on top of the 35.x sources. Such kernels are available for > > Red Hat Linux 7.3, 8.0 and 9. > > > > http://atrpms.net/name/kernel/ > > http://atrpms.net/name/kernel-redhat/ > > > > Have at 'em, all the variants I've tried work without a problem. > > Please remember that these are not Fedora Legacy approved kernels. (: Sorry, should have made that more clear. Yes, not official FL releases. (Esp. the "enhanced" ones ;-). -- Jarod C. Wilson, RHCE jcw at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jvergeer at shoprite.co.za Tue Jun 29 07:21:53 2004 From: jvergeer at shoprite.co.za (Johnny Vergeer) Date: Tue, 29 Jun 2004 09:21:53 +0200 Subject: Kernel panic - Redhat 7.3 - 2.4.20-30.7.legacy Message-ID: <6E11DEF3763017499494F085D201CF2A2FAD97@exchange.shoprite.co.za> Mike Fedyk wrote: > Run memtest86 on the box with one or two passes in "all tests" mode, and > check your filesystems to see if there are errors as the oops looks like > it's in the filesystem code. > Thanx Mike, will do. Just to clarify, we are running this kernel on about 500 Intel systems with various specs. These systems are at remote locations, so are difficult to monitor. From the log files and reboot stats, we gather the general stability of the systems. We experience occasional crashes on all systems, and a higher crash rate on the new Bayfield systems. Regards johnny Disclaimer http://www.shoprite.co.za/disclaimer.html From ba1020 at homie.homelinux.net Tue Jun 29 08:24:14 2004 From: ba1020 at homie.homelinux.net (J=?iso-8859-15?q?=FCrgen=20Schinker?=) Date: Tue, 29 Jun 2004 08:24:14 -0000 Subject: ATrpms FL-based kernels Message-ID: <20040629082414.C1EE41BFC3@gate.schinx.net> Discussion of the Fedora Legacy Project <fedora-legacy-list at redhat.com> wrote: > On Monday 28 June 2004 16:25, Jesse Keating wrote: > > On Monday 28 June 2004 15:57, Jarod Wilson wrote: > > > There are new kernels available for download and install on > > > ATrpms.net (even via apt/yum), based off the 35.x Fedora Legacy > > > kernel srpm. The available kernels include the stock 35.x.legacy > > > versions for convenience, and the usual ATrpms-enhanced versions, > > > with XFS support, v4l2, i2c 2.8.x, 3Ware Escalade drivers and updated > > > LVM added on top of the 35.x sources. Such kernels are available for > > > Red Hat Linux 7.3, 8.0 and 9. > > > > > > http://atrpms.net/name/kernel/ > > > http://atrpms.net/name/kernel-redhat/ > > > > > > Have at 'em, all the variants I've tried work without a problem. > > > > Please remember that these are not Fedora Legacy approved kernels. (: > > Sorry, should have made that more clear. Yes, not official FL releases. (Esp. > the "enhanced" ones ;-). makes no difference to me he is faster with security patches coz the Floating Point Exception was announced on 15.06 and redhat 7.3 has even now no new kernel From okan at sunpack.com Tue Jun 29 16:03:23 2004 From: okan at sunpack.com (N. Okan Guney) Date: Tue, 29 Jun 2004 11:03:23 -0500 Subject: yum for 8.0 Message-ID: Hello, I was going over the procedure to make yum work on 8.0 but it failed stating: Retrieving http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 .72.i386.rpm error: skipping http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 .72.i386.rpm - transfer failed - Unknown or unexpected error It seems like that package had been removed for some reason? Any suggestions on how to proceed? Thanks, Okan From admin at cs.montana.edu Tue Jun 29 17:51:04 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Tue, 29 Jun 2004 11:51:04 -0600 (MDT) Subject: install gcc-3.3 stdc++5 libraries Message-ID: <4536.153.90.198.54.1088531464.squirrel@web1.cs.montana.edu> I recently upgrade a server I nfs mount data from on my webserver. The main server has gcc 3.3, so c++ programs compiled on the main server, will not run on the webserver. The webserver does not have gcc 3.3 stdc++5.0 libraries installed. What is the easiest, best way to solve this? Install gcc-3.3 on the webserver? Install just the stdc++5.0 c++ library on the webserver? Ideas? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From mfedyk at matchmail.com Tue Jun 29 19:34:10 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 29 Jun 2004 19:34:10 -0000 Subject: Kernel panic - Redhat 7.3 - 2.4.20-30.7.legacy In-Reply-To: <6E11DEF3763017499494F085D201CF2A2FAD97@exchange.shoprite.co.za> References: <6E11DEF3763017499494F085D201CF2A2FAD97@exchange.shoprite.co.za> Message-ID: <40BCDA3B.4070808@matchmail.com> Johnny Vergeer wrote: > Just to clarify, we are running this kernel on about 500 Intel systems > with various specs. These systems are at remote locations, so are > difficult to monitor. From the log files and reboot stats, we gather the > general stability of the systems. We experience occasional crashes on > all systems, and a higher crash rate on the new Bayfield systems. If you can correlate lspci output with oops reports for the various machines and report that against the various versions of the kernel, it would probably help the developers get a fix out. Mike From Axel.Thimm at ATrpms.net Tue Jun 29 21:03:09 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 29 Jun 2004 23:03:09 +0200 Subject: ATrpms FL-based kernels In-Reply-To: <20040629082414.C1EE41BFC3@gate.schinx.net> References: <20040629082414.C1EE41BFC3@gate.schinx.net> Message-ID: <20040629210309.GE8035@neu.nirvana> On Tue, Jun 29, 2004 at 08:24:14AM -0000, J?rgen Schinker wrote: > Discussion of the Fedora Legacy Project <fedora-legacy-list at redhat.com> > wrote: > > On Monday 28 June 2004 16:25, Jesse Keating wrote: > > > On Monday 28 June 2004 15:57, Jarod Wilson wrote: > > > > There are new kernels available for download and install on > > > > ATrpms.net (even via apt/yum), based off the 35.x Fedora > > > > Legacy kernel srpm. The available kernels include the stock > > > > 35.x.legacy versions for convenience, and the usual > > > > ATrpms-enhanced versions, with XFS support, v4l2, i2c 2.8.x, > > > > 3Ware Escalade drivers and updated LVM added on top of the > > > > 35.x sources. Such kernels are available for Red Hat Linux > > > > 7.3, 8.0 and 9. > > > > > > > > http://atrpms.net/name/kernel/ > > > > http://atrpms.net/name/kernel-redhat/ > > > > > > > > Have at 'em, all the variants I've tried work without a problem. > > > > > > Please remember that these are not Fedora Legacy approved kernels. (: > > > > Sorry, should have made that more clear. Yes, not official FL releases. (Esp. > > the "enhanced" ones ;-). > > makes no difference to me > he is faster with security patches > coz the Floating Point Exception was announced on 15.06 > and redhat 7.3 has even now no new kernel We need to be fair on that and give credit, where credit is due. The kernel rpms are not yet officially published by FL because they are still in QA. The kernels at ATrpms are derived work of these kernels, so the security patches are all Dominic's and Jarod's work AFAICT. Many thanks to Dominic, Jarod and all the FL team for keeping our kernels from falling apart. :) -- 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 jcw at wilsonet.com Wed Jun 30 00:59:50 2004 From: jcw at wilsonet.com (Jarod Wilson) Date: Tue, 29 Jun 2004 17:59:50 -0700 Subject: ATrpms FL-based kernels In-Reply-To: <20040629210309.GE8035@neu.nirvana> References: <20040629082414.C1EE41BFC3@gate.schinx.net> <20040629210309.GE8035@neu.nirvana> Message-ID: <200406291759.53630.jcw@wilsonet.com> On Tuesday 29 June 2004 14:03, Axel Thimm wrote: > On Tue, Jun 29, 2004 at 08:24:14AM -0000, J?rgen Schinker wrote: > > Discussion of the Fedora Legacy Project > > <fedora-legacy-list at redhat.com> > > > > wrote: > > > On Monday 28 June 2004 16:25, Jesse Keating wrote: > > > > On Monday 28 June 2004 15:57, Jarod Wilson wrote: > > > > > There are new kernels available for download and install on > > > > > ATrpms.net (even via apt/yum), based off the 35.x Fedora > > > > > Legacy kernel srpm. The available kernels include the stock > > > > > 35.x.legacy versions for convenience, and the usual > > > > > ATrpms-enhanced versions, with XFS support, v4l2, i2c 2.8.x, > > > > > 3Ware Escalade drivers and updated LVM added on top of the > > > > > 35.x sources. Such kernels are available for Red Hat Linux > > > > > 7.3, 8.0 and 9. > > > > > > > > > > http://atrpms.net/name/kernel/ > > > > > http://atrpms.net/name/kernel-redhat/ > > > > > > > > > > Have at 'em, all the variants I've tried work without a problem. > > > > > > > > Please remember that these are not Fedora Legacy approved kernels. > > > > (: > > > > > > Sorry, should have made that more clear. Yes, not official FL releases. > > > (Esp. the "enhanced" ones ;-). > > > > makes no difference to me > > he is faster with security patches > > coz the Floating Point Exception was announced on 15.06 > > and redhat 7.3 has even now no new kernel > > We need to be fair on that and give credit, where credit is due. The > kernel rpms are not yet officially published by FL because they are > still in QA. The kernels at ATrpms are derived work of these kernels, > so the security patches are all Dominic's and Jarod's work AFAICT. > > Many thanks to Dominic, Jarod and all the FL team for keeping our > kernels from falling apart. :) Predominantly Dominic's work. While I was working on the same patches, he got 'em done first (save the e1000 fix), so the work is mostly by Fedora Legacy, not ATrpms. I just tidied things up for publishing on ATrpms, then Axel built and posted them. And like Axel said, the official Fedora Legacy kernels haven't finished the QA process, meaning you aren't guaranteed the ATrpms kernels won't destroy your system. If you do use the non-enhanced ATrpms kernels, please do submit feedback to Fedora Legacy to help the official kernels complete their QA. If you use the FL-sources-based enhanced ATrpms kernels, feedback should go to ATrpms. -- Jarod C. Wilson, RHCE jcw at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From J.S.Peatfield at damtp.cam.ac.uk Wed Jun 30 18:13:48 2004 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Wed, 30 Jun 2004 19:13:48 +0100 Subject: Kernel package status Message-ID: > The latest kernel package has been up for QA for a couple of days - this > fixes a whopping 16 separate issues compared to the previous FL update. > It would be really excellent to get this released ASAP to stop it > snowballing - no doubt there will be further kernel issues discovered > and announced in the coming months, and some of these issues are now > already three months old! Any news on how many extra QA testers are still needed for 2.4.20-35... to make it? I did try to pursuade some people here who who RH9 to test/QA the kernels but I'm not sure if they have got very far yet... -- Jon From dom at earth.li Wed Jun 30 18:17:53 2004 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 30 Jun 2004 19:17:53 +0100 Subject: Kernel package status In-Reply-To: References: Message-ID: <20040630181753.GM30964@tirian.magd.ox.ac.uk> On Wed, Jun 30, 2004 at 07:13:48PM +0100, Jon Peatfield wrote: > Any news on how many extra QA testers are still needed for > 2.4.20-35... to make it? As far as I am concerned it should be built for updates-testing now (with reference to ). Jesse, over to you? Cheers, Dominic. From jkeating at j2solutions.net Wed Jun 30 19:05:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 30 Jun 2004 12:05:52 -0700 Subject: Kernel package status In-Reply-To: <20040630181753.GM30964@tirian.magd.ox.ac.uk> References: <20040630181753.GM30964@tirian.magd.ox.ac.uk> Message-ID: <200406301205.56152.jkeating@j2solutions.net> On Wednesday 30 June 2004 11:17, Dominic Hargreaves wrote: > As far as I am concerned it should be built for updates-testing now > (with reference to > ). Jesse, > over to you? Yes, I feel it's ready to build. I'll set off thebuild today, not sure if I"ll have time to upload/announce it tonight after softball. -- 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 jpdalbec at ysu.edu Wed Jun 30 20:03:28 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 30 Jun 2004 16:03:28 -0400 Subject: yum for 8.0 In-Reply-To: <20040630160016.C68AA73F2C@hormel.redhat.com> References: <20040630160016.C68AA73F2C@hormel.redhat.com> Message-ID: <40E31C90.1000704@ysu.edu> "N. Okan Guney" wrote: > Retrieving > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm > error: skipping > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm - transfer failed - Unknown or unexpected error > > It seems like that package had been removed for some reason? Any > suggestions on how to proceed? Looks like a cut-and-paste error. Try http://download.fedoralegacy.org/redhat/8.0/os/i386/python-2.2.1-17.i386.rpm HTH, John P.S. 8.0 is not supported due to lack of community participation. You should consider upgrading to 9 if possible. From okan at sunpack.com Wed Jun 30 20:29:49 2004 From: okan at sunpack.com (N. Okan Guney) Date: Wed, 30 Jun 2004 15:29:49 -0500 Subject: yum for 8.0 Message-ID: Thanks, It's strange though I copied and pasted from the page http://www.fedoralegacy.org/docs/yum-rh8.php which reads: # rpm -Uvh http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/rpm-4.1.1- 1.8x.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/rpm-build- 4.1.1-1.8x.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/rpm-devel- 4.1.1-1.8x.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/rpm-python -4.1.1-1.8x.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/popt-1.7.1 -1.8x.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 .72.i386.rpm \ http://download.fedoralegacy.org/redhat/8.0/updates/i386/gnupg-1.0.7-14. i386.rpm It seems like 8.0 is still supported to some extend, it is kind of scary for me to upgrade to 9.0 the production server, for downtime would mess a lot of things up. Thanks again, Okan -----Original Message----- From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of John Dalbec Sent: Wednesday, June 30, 2004 2:03 PM To: fedora-legacy-list at redhat.com Subject: Re: yum for 8.0 "N. Okan Guney" wrote: > Retrieving > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm > error: skipping > http://download.fedoralegacy.org/redhat/8.0/updates/i386/python-1.5.2-43 > .72.i386.rpm - transfer failed - Unknown or unexpected error > > It seems like that package had been removed for some reason? Any > suggestions on how to proceed? Looks like a cut-and-paste error. Try http://download.fedoralegacy.org/redhat/8.0/os/i386/python-2.2.1-17.i386 .rpm HTH, John P.S. 8.0 is not supported due to lack of community participation. You should consider upgrading to 9 if possible. -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From wimple at gaia.ecs.csus.edu Thu Jun 17 15:25:35 2004 From: wimple at gaia.ecs.csus.edu (Mike Wimple) Date: Thu, 17 Jun 2004 15:25:35 -0000 Subject: another RHL9 kernel patch. In-Reply-To: <8F14CC3BCD38734C9C7F13C364250E970177C22B@hermes.ecs.csus.edu> Message-ID: <200406171525.i5HFPWDD008437@gaia.ecs.csus.edu> Will there be a set of RH9 compiled kernels available from the legacy project soon? -mike >-----Original Message----- >From: fedora-legacy-list-bounces at redhat.com >[mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of >Jesse Keating >Sent: Thursday, June 17, 2004 8:08 AM >To: Discussion of the Fedora Legacy Project >Subject: Re: another RHL9 kernel patch. > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thursday 17 June 2004 07:58, Dave Jones wrote: >> You will however likely need these too. >> ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 >> >> I'm just rebuilding the FC1 update with these added. >> >> ????????Dave > >Thanks Dave. We'll add these to our pending kernel for 7.3/9. > >- -- >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) > >iD8DBQFA0bO94v2HLvE71NURApMNAJsEnrxvdb329kBduhs4MtXMbYCjWwCgnKz7 >JSzVm9RAOeT2s8d5Egj10/4= >=d98/ >-----END PGP SIGNATURE----- > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From wimple at gaia.ecs.csus.edu Thu Jun 17 16:23:47 2004 From: wimple at gaia.ecs.csus.edu (Mike Wimple) Date: Thu, 17 Jun 2004 16:23:47 -0000 Subject: another RHL9 kernel patch. In-Reply-To: <8F14CC3BCD38734C9C7F13C364250E970177C22B@hermes.ecs.csus.edu> Message-ID: <200406171623.i5HGNdDD020010@gaia.ecs.csus.edu> Will there be a set of RH9 compiled kernels available from the legacy project soon? The DoS fix is needed ASAP... -mike >-----Original Message----- >From: fedora-legacy-list-bounces at redhat.com >[mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of >Jesse Keating >Sent: Thursday, June 17, 2004 8:08 AM >To: Discussion of the Fedora Legacy Project >Subject: Re: another RHL9 kernel patch. > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thursday 17 June 2004 07:58, Dave Jones wrote: >> You will however likely need these too. >> ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2 >> >> I'm just rebuilding the FC1 update with these added. >> >> ????????Dave > >Thanks Dave. We'll add these to our pending kernel for 7.3/9. > >- -- >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) > >iD8DBQFA0bO94v2HLvE71NURApMNAJsEnrxvdb329kBduhs4MtXMbYCjWwCgnKz7 >JSzVm9RAOeT2s8d5Egj10/4= >=d98/ >-----END PGP SIGNATURE----- > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list >