From drees at greenhydrant.com Sun Feb 1 01:07:02 2004 From: drees at greenhydrant.com (David Rees) Date: Sat, 31 Jan 2004 17:07:02 -0800 Subject: -testing timeout In-Reply-To: <64691.65.40.133.19.1075584453.squirrel@65.40.133.19> References: <200401311243.04320.jkeating@j2solutions.net> <20040131210936.GG21263@psilocybe.teonanacatl.org> <64691.65.40.133.19.1075584453.squirrel@65.40.133.19> Message-ID: <401C5136.8000500@greenhydrant.com> William Hooper wrote, On 1/31/2004 1:27 PM: > Todd said: > >>One thing I'd be wary of with pushing an update from testing just >>based on a timeout is how we'd know if anyone had bothered using it. >>I don't make use of ethereal on a regular basis, so just because I've >>updated my systems against updates-testing doesn't mean I've even >>picked up ethereal, let alone tested it at all. > > How does this weigh against a package not getting released for months and > a new worm appearing that exploits it? If the vulnerability was that serious, there would be more people interested in testing the package. In the case of ethereal, it seems that not many people are interested in the package, hence the low interest in testing it. I would rather sit on a package until it generates the necessary PUBLISH votes than release an un-tested package. Again as I have mentioned before, I feel the ultimate decision is up to the bug-owner, and if they are not sure, gather feedback from list members. Just the process of gathering feedback will usually generate enough interest in a package to get someone to verify the package. To get more potential testers, it would be extremely helpful to get an easy way for people to get test systems running. Myself, I only have access to some RH73 machines, and I took a look at UML, but the amount of setup to get a UML instance up put me off for a while. -Dave From whooperhsd3 at earthlink.net Sun Feb 1 01:41:42 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Sat, 31 Jan 2004 20:41:42 -0500 (EST) Subject: -testing timeout In-Reply-To: <401C5136.8000500@greenhydrant.com> References: <200401311243.04320.jkeating@j2solutions.net> <20040131210936.GG21263@psilocybe.teonanacatl.org> <64691.65.40.133.19.1075584453.squirrel@65.40.133.19> <401C5136.8000500@greenhydrant.com> Message-ID: <65415.65.40.133.19.1075599702.squirrel@65.40.133.19> David Rees said: > If the vulnerability was that serious, there would be more people > interested in testing the package. In the case of ethereal, it seems > that not many people are interested in the package, hence the low > interest in testing it. http://www.debian.org/News/2003/20031202 Some vulnerabilities only become "Serious" after the fact. So, a package sits in testing for a week, gets pushed to updates. The 1 person that is using it starts to complain about something. This would be a great time to introduce this person to the QA process and get them involved. I think the majority of the time the case would be that a number of people have downloaded that package and not bothered to "official" give it a thumbs up. No news is good news. Using the ethereal example: If you have a serious need for it, then you need to test it. Isn't that part of having "community" updates, that the "community" decides how good the updates are? -- William Hooper From joey at clean.q7.com Sun Feb 1 03:30:39 2004 From: joey at clean.q7.com (Joe Pruett) Date: Sat, 31 Jan 2004 19:30:39 -0800 (PST) Subject: -testing timeout In-Reply-To: <65415.65.40.133.19.1075599702.squirrel@65.40.133.19> Message-ID: this is tangential to this topic, but i'd like to suggest that rpms not be moved into the updates directory (from updates-testing) until they are officially announced. i have some systems using yum to grab updates and some that mirror from the web site and today i noticed that ethereal got updated on the mirrored boxes, but not on the yum boxes. from this discussion i see that ethereal isn't official yet but it is in an area that i (maybe naively) think of as official. On Sat, 31 Jan 2004, William Hooper wrote: > > David Rees said: > > If the vulnerability was that serious, there would be more people > > interested in testing the package. In the case of ethereal, it seems > > that not many people are interested in the package, hence the low > > interest in testing it. > > http://www.debian.org/News/2003/20031202 > > Some vulnerabilities only become "Serious" after the fact. > > So, a package sits in testing for a week, gets pushed to updates. The 1 > person that is using it starts to complain about something. This would be > a great time to introduce this person to the QA process and get them > involved. > > I think the majority of the time the case would be that a number of people > have downloaded that package and not bothered to "official" give it a > thumbs up. No news is good news. > > Using the ethereal example: If you have a serious need for it, then you > need to test it. Isn't that part of having "community" updates, that the > "community" decides how good the updates are? > > From pekkas at netcore.fi Sun Feb 1 07:22:40 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 1 Feb 2004 09:22:40 +0200 (EET) Subject: -testing timeout In-Reply-To: <64691.65.40.133.19.1075584453.squirrel@65.40.133.19> Message-ID: On Sat, 31 Jan 2004, William Hooper wrote: > I think either there needs to be "assigned" people to test and report (not > very workable), or the assumption that if someone hasn't spoke up before > the timeout that it must be OK. or an (automatic) "test me, please!" reminder message sent on this list. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Sun Feb 1 07:37:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 23:37:47 -0800 Subject: -testing timeout In-Reply-To: References: Message-ID: <200401312337.48750.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 31 January 2004 19:30, Joe Pruett wrote: > this is tangential to this topic, but i'd like to suggest that rpms not > be moved into the updates directory (from updates-testing) until they > are officially announced. i have some systems using yum to grab updates > and some that mirror from the web site and today i noticed that ethereal > got updated on the mirrored boxes, but not on the yum boxes. from this > discussion i see that ethereal isn't official yet but it is in an area > that i (maybe naively) think of as official. Actually that was a slip up by me. I was half way through writing the advisory when I realized that nobody had verified it, so I started this thread. I have to move the files before I send the advisory, so that the links are live and the yum/apt metadata is updated. I'm going to push ethereal now. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHKzL4v2HLvE71NURAoW3AJ9PkVPDNExRJssy9zzmIJeXmSWxMgCeIQT8 NViCQ8cXoEMi/vhKVoVKSQE= =QMVJ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sun Feb 1 07:40:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 23:40:10 -0800 Subject: [FLSA-2004:1193] Updated ethereal resolves security vulnerabilites Message-ID: <200401312340.12011.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated ethereal resolves security vulnerabilities Advisory ID: FLSA:1193 Issue date: 2004-01-31 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1193 CVE Names: CAN-2003-1012, CAN-2004-1013 - ----------------------------------------------------------------------- 1. Topic: Updated ethereal packages are now available that fix multiple security vulnerabilities which may allow attackers to make Ethereal crash by injecting an intentionally malformed packet onto the wire or by convincing someone to read a malformed packet trace file. It is not known if these issues could allow arbitrary code execution. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Ethereal is a network traffic analyzer for Unix-ish operating systems. The SMB dissector in Ethereal before 0.10.0 allows remote attackers to cause a denial of service via a malformed SMB packet that triggers a segmentation fault during processing of Selected packets. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-1012 to this issue. The Q.931 dissector in Ethereal before 0.10.0 allows remote attackers to cause a denial of service (crash) via a malformed Q.931, which triggers a null dereference. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-1013 to this issue. Users of tcpdump should update to these update packages, which contain a backported security patch that corrects this issue. Users of ethereal should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1193 - ethereal security patch in rh7x, rh8 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ethereal-0.9.16-0.72.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/ethereal-0.9.16-0.72.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/ethereal-gnome-0.9.16-0.72.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ethereal-0.9.16-0.73.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-0.9.16-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-gnome-0.9.16-0.73.2.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/ethereal-0.9.16-0.80.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/ethereal-0.9.16-0.80.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/ethereal-gnome-0.9.16-0.80.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 9f1a7186859a95604431f52e137943f4a256b89f 7.2/updates/SRPMS/ethereal-0.9.16-0.72.2.legacy.src.rpm 01e991b44ca40f432b639a9cdd25f46ab60a85e7 7.2/updates/i386/ethereal-0.9.16-0.72.2.legacy.i386.rpm c263966f199db31ec551d9dff07363830f575bff 7.2/updates/i386/ethereal-gnome-0.9.16-0.72.2.legacy.i386.rpm 1aebaffacc86561fea139b3dae351722eda761b9 7.3/updates/SRPMS/ethereal-0.9.16-0.73.2.legacy.src.rpm db5326236fe91e7c84be611bbfdafd689187b32b 7.3/updates/i386/ethereal-0.9.16-0.73.2.legacy.i386.rpm d78ca86ff9ca7adb7c0d006c43fe84d138bc87e0 7.3/updates/i386/ethereal-gnome-0.9.16-0.73.2.legacy.i386.rpm 14350e74f4e261002bab186c942bc6caa788fce3 8.0/updates/SRPMS/ethereal-0.9.16-0.80.2.legacy.src.rpm dc94ba568db4239f67cb191d4cf43a1d2f5a4fb7 8.0/updates/i386/ethereal-0.9.16-0.80.2.legacy.i386.rpm a17d1098baf6b4ba2a8588e933a17d96629401cc 8.0/updates/i386/ethereal-gnome-0.9.16-0.80.2.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1012 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1013 http://www.ethereal.com/appnotes/enpa-sa-00012.html https://bugzilla.fedora.us/show_bug.cgi?id=1222 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHK1b4v2HLvE71NURArZxAJ9yi02U4bAhIbAu27BV7DMWEBGcrwCgldqN 1qGT/iWi3pWRhuWEUyrk4XY= =+1te -----END PGP SIGNATURE----- From wipe_out at users.sourceforge.net Sun Feb 1 10:58:05 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Sun, 01 Feb 2004 10:58:05 +0000 Subject: update error.. Message-ID: <401CDBBD.6090604@users.sourceforge.net> Hi, I tried to run an update on my RH7.2 server this morning and goy the output below.. What should I do to fix it? I tried removing the file it mentions and also tried "yum clean".. # yum update Gathering package information from servers Getting headers from: Red Hat Linux 7.2 base Getting headers from: Fedora Legacy utilities for Red Hat Linux 7.2 Getting headers from: Red Hat Linux 7.2 updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: yum.noarch] Is this ok [y/N]: y Getting yum-1.0.3-6.0.7.x.legacy.noarch.rpm Error: GPG Signature check failed for /var/cache/yum/legacy-utils/packages/yum-1.0.3-6.0.7.x.legacy.noarch.rpm You may want to run yum clean or remove the file: /var/cache/yum/legacy-utils/packages/yum-1.0.3-6.0.7.x.legacy.noarch.rpm You may also want to check to make sure you have the right gpg keys Exiting. From drees at greenhydrant.com Sun Feb 1 11:10:04 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 01 Feb 2004 03:10:04 -0800 Subject: update error.. In-Reply-To: <401CDBBD.6090604@users.sourceforge.net> References: <401CDBBD.6090604@users.sourceforge.net> Message-ID: <401CDE8C.5080707@greenhydrant.com> WipeOut wrote, On 2/1/2004 2:58 AM: > > I tried to run an update on my RH7.2 server this morning and goy the > output below.. What should I do to fix it? > > I tried removing the file it mentions and also tried "yum clean".. > > Error: GPG Signature check failed for > /var/cache/yum/legacy-utils/packages/yum-1.0.3-6.0.7.x.legacy.noarch.rpm This is the real problem. You need to import the Fedora GPG key. This command should do it: rpm --import http://www.fedora.us/FEDORA-GPG-KEY -Dave From wipe_out at users.sourceforge.net Sun Feb 1 12:32:09 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Sun, 01 Feb 2004 12:32:09 +0000 Subject: update error.. In-Reply-To: <401CDE8C.5080707@greenhydrant.com> References: <401CDBBD.6090604@users.sourceforge.net> <401CDE8C.5080707@greenhydrant.com> Message-ID: <401CF1C9.30408@users.sourceforge.net> David Rees wrote: > WipeOut wrote, On 2/1/2004 2:58 AM: > >> >> I tried to run an update on my RH7.2 server this morning and goy the >> output below.. What should I do to fix it? >> >> I tried removing the file it mentions and also tried "yum clean".. > > > > >> Error: GPG Signature check failed for >> /var/cache/yum/legacy-utils/packages/yum-1.0.3-6.0.7.x.legacy.noarch.rpm > > > This is the real problem. You need to import the Fedora GPG key. > > This command should do it: > rpm --import http://www.fedora.us/FEDORA-GPG-KEY > > -Dave > rpm on RH7.2 does not appear to have a "--import" option.. I installed the new yum package manually which seemed to work.. Will have to see what happenes when an update is released.. Thanks.. From ms-nospam-0306 at arcor.de Sun Feb 1 12:44:37 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 1 Feb 2004 13:44:37 +0100 Subject: update error.. In-Reply-To: <401CF1C9.30408@users.sourceforge.net> References: <401CDBBD.6090604@users.sourceforge.net> <401CDE8C.5080707@greenhydrant.com> <401CF1C9.30408@users.sourceforge.net> Message-ID: <20040201134437.74e19b0e.ms-nospam-0306@arcor.de> On Sun, 01 Feb 2004 12:32:09 +0000, WipeOut wrote: > > This is the real problem. You need to import the Fedora GPG key. > > > > This command should do it: > > rpm --import http://www.fedora.us/FEDORA-GPG-KEY > > > > -Dave > > > rpm on RH7.2 does not appear to have a "--import" option.. > > I installed the new yum package manually which seemed to work.. Will > have to see what happenes when an update is released.. With the older RPM, you need to import the key into your GPG key-ring. Download it and "gpg --import FILE". -- From mail at jonaspasche.de Sun Feb 1 14:22:35 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Sun, 01 Feb 2004 15:22:35 +0100 Subject: update error.. In-Reply-To: <401CDE8C.5080707@greenhydrant.com> References: <401CDBBD.6090604@users.sourceforge.net> <401CDE8C.5080707@greenhydrant.com> Message-ID: <1075645354.3654.9.camel@leonardo> Hi there, > > Error: GPG Signature check failed for > > /var/cache/yum/legacy-utils/packages/yum-1.0.3-6.0.7.x.legacy.noarch.rpm > > This is the real problem. You need to import the Fedora GPG key. > > This command should do it: > rpm --import http://www.fedora.us/FEDORA-GPG-KEY As this is a package from Fedora Legacy, not from Fedora, I'm sure you need to import the Fedora Legacy key instead, or simply the keys of Red Hat, Fedora and Fedora Legacy at once: gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY If you've never used pgp before as root, you will need to run the command a second time so that gpg can read and use its newly created options file. Jonas -------------- 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 drees at greenhydrant.com Sun Feb 1 18:00:09 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 01 Feb 2004 10:00:09 -0800 Subject: update error.. In-Reply-To: <1075645354.3654.9.camel@leonardo> References: <401CDBBD.6090604@users.sourceforge.net> <401CDE8C.5080707@greenhydrant.com> <1075645354.3654.9.camel@leonardo> Message-ID: <401D3EA9.4050209@greenhydrant.com> Jonas Pasche wrote, On 2/1/2004 6:22 AM: > > As this is a package from Fedora Legacy, not from Fedora, I'm sure you > need to import the Fedora Legacy key instead, or simply the keys of Red > Hat, Fedora and Fedora Legacy at once: Doh, you're right Jonas, thanks for correcting me. -Dave From maillist at jasonlim.com Sun Feb 1 18:15:52 2004 From: maillist at jasonlim.com (Jason Lim) Date: Mon, 2 Feb 2004 02:15:52 +0800 Subject: yum and rpm updates for 8.0 References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261048.13461.jkeating@j2solutions.net> <20040126192354.GF21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> Message-ID: <86c101c3e8ef$6d4b8740$0900a8c0@SYSTEM9> > > This was posted 1/26 - any update on the Yum release? > > Thx, > -Rick > Hehe we're all awaiting this too ;-) From Freedom_Lover at pobox.com Sun Feb 1 18:29:14 2004 From: Freedom_Lover at pobox.com (Todd) Date: Sun, 1 Feb 2004 13:29:14 -0500 Subject: update error.. In-Reply-To: <20040201134437.74e19b0e.ms-nospam-0306@arcor.de> References: <401CDBBD.6090604@users.sourceforge.net> <401CDE8C.5080707@greenhydrant.com> <401CF1C9.30408@users.sourceforge.net> <20040201134437.74e19b0e.ms-nospam-0306@arcor.de> Message-ID: <20040201182914.GH21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Sun, 01 Feb 2004 12:32:09 +0000, WipeOut wrote: [...] >> rpm on RH7.2 does not appear to have a "--import" option.. >> >> I installed the new yum package manually which seemed to work.. >> Will have to see what happenes when an update is released.. > > With the older RPM, you need to import the key into your GPG > key-ring. Download it and "gpg --import FILE". Just to clarify this for the archives (and to make sure I have this right), yum 1 uses root's gpg keyring for checking. yum 2 uses the rpm database. On a stock RH 8.0 install with rpm-4.1 and yum 1, you'd need to use rpm --import if you wanted to check a sig using rpm -K, for example, when you initially install yum on the system (you do check the gpg signature before installing, right? :). Then you'd use gpg --import so that yum could check signatures of packages it was installing. Sort of a mess, really. If you use yum for everything, you'd only need to do one rpm --import and that would be for the key used to sign the yum package. All other keys would be imported using gpg --import. But you'll still get a surprise the first time you go to use rpm -K to check a signature. Perhaps this is something that might be weighed in deciding whether to push out yum 2 and rpm 4.1.1 on RH 8.0? At the least, it'll probably have to be explained in some clearer way for the instructions that end up on the web page. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Eighty three million gun owners didn't shoot someone yesterday. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAHUV6uv+09NZUB1oRAuMPAJ4oCpXyqTjloZPPqNux+VhJoHEYMgCg5Buc TSy7XWQdlKt6lkZoEKajw9k= =pTax -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Mon Feb 2 13:33:40 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 02 Feb 2004 08:33:40 -0500 Subject: fedora-legacy-list digest, Vol 1 #79 - 15 msgs In-Reply-To: <20040131170004.32205.64403.Mailman@listman.back-rdu.redhat.com> References: <20040131170004.32205.64403.Mailman@listman.back-rdu.redhat.com> Message-ID: <401E51B4.6030006@ysu.edu> > Date: Fri, 30 Jan 2004 14:40:09 -0600 > From: Eric Rostetter > To: fedora-legacy-list at redhat.com > Subject: Re: web site updates > Reply-To: fedora-legacy-list at redhat.com > > Quoting John Dalbec : > > >>One alternative would be to import the keys in the postinst. FreshRPMs' yum >>RPM >>does this. >>John > > > Bad idea for anything to be messing with the root user's keychain, really. > I just don't like the sound of that... Well, FreshRPMs.net doesn't seem to have a problem with it. What about printing a message in the postinst to remind the user to import the GPG keys? This would be analogous to the Horde RPMs printing a message in the postinst to remind the user to restart httpd/apache. John > > I'll add the info on how to add the keys to the web site when I get time... > > -- > Eric Rostetter From mail at jonaspasche.de Mon Feb 2 16:15:13 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Mon, 02 Feb 2004 17:15:13 +0100 Subject: Fedora Legacy Schedule Message-ID: <1075738513.3642.293.camel@leonardo> Hi all, for all of you that still didn't exactly grasp the concept of the "1-2-3-out policy" I created a diagram which hopefully answers all questions on this issue (hoping that I for myself have understood that model correctly): http://jonaspasche.de/fedoralegacy/schedule.html Does this help anybody in understanding this model? If yes, we should include it into the website, maybe into the FAQ, or on a separate page that can be linked by every document that uses the phrase "1-2-3-out policy". Or at least we include the diagram with its legend. :) Jonas -------------- 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 wipe_out at users.sourceforge.net Mon Feb 2 16:37:29 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Mon, 02 Feb 2004 16:37:29 +0000 Subject: Fedora Legacy Schedule In-Reply-To: <1075738513.3642.293.camel@leonardo> References: <1075738513.3642.293.camel@leonardo> Message-ID: <401E7CC9.5010108@users.sourceforge.net> Jonas Pasche wrote: >Hi all, > >for all of you that still didn't exactly grasp the concept of the >"1-2-3-out policy" I created a diagram which hopefully answers all >questions on this issue (hoping that I for myself have understood that >model correctly): > >http://jonaspasche.de/fedoralegacy/schedule.html > >Does this help anybody in understanding this model? If yes, we should >include it into the website, maybe into the FAQ, or on a separate page >that can be linked by every document that uses the phrase "1-2-3-out >policy". Or at least we include the diagram with its legend. :) > >Jonas > > I think it definately needs to be included on the website!! Will make it far easier to understand.. Later.. From rostetter at mail.utexas.edu Mon Feb 2 16:46:06 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 2 Feb 2004 10:46:06 -0600 Subject: fedora-legacy-list digest, Vol 1 #79 - 15 msgs In-Reply-To: <401E51B4.6030006@ysu.edu> References: <20040131170004.32205.64403.Mailman@listman.back-rdu.redhat.com> <401E51B4.6030006@ysu.edu> Message-ID: <20040202104606.bcqmm8kwgk008s0c@mail.ph.utexas.edu> Quoting John Dalbec : > >>One alternative would be to import the keys in the postinst. FreshRPMs' > yum > >>RPM > >>does this. > >>John > > > > > > Bad idea for anything to be messing with the root user's keychain, really. > > I just don't like the sound of that... > > Well, FreshRPMs.net doesn't seem to have a problem with it. Good for them. A lot of sysadmins would though. > What about > printing > a message in the postinst to remind the user to import the GPG keys? This That's fine with me. -- Eric Rostetter From jkeating at j2solutions.net Tue Feb 3 00:55:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 2 Feb 2004 16:55:37 -0800 Subject: Server down-time Message-ID: <200402021655.42852.jkeating@j2solutions.net> Our web server and download server needs to be rebooted to move to a different power unit. The outage should only last a few minutes. I'll alert the list when it comes back up. I apologize to any folks currently syncing up.... Actually it looks like I forgot to click send before I rebooted the box... *sigh* sorry folks. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 sean at resultsoverhead.com Tue Feb 3 01:51:11 2004 From: sean at resultsoverhead.com (Sean Kerner) Date: Mon, 2 Feb 2004 20:51:11 -0500 Subject: Small Error at http://fedoralegacy.org/docs/yum-rh7x.php#step2 Message-ID: Hi, Just noticed a small error that should be corrected at: http://fedoralegacy.org/docs/yum-rh7x.php#step2 >To install yum, use the following command as the root user on your machine: > # rpm -ivh http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386/yum->1.0.3-3.0 .7.x.legacy.noarch.rpm >yum automatically uses the correct configuration for your system (7.2 or 7.3), so you >can install the above RPM on any 7.2 or 7.3 systems. The version of YUM that is online right now is not the one listed. Rather it's : yum-1.0.3-6.0.7.x.legacy.noarch.rpm Sean From pmueller at sidestep.com Tue Feb 3 03:23:05 2004 From: pmueller at sidestep.com (Peter Mueller) Date: Mon, 2 Feb 2004 19:23:05 -0800 Subject: Yum-rh7x.php diff Message-ID: <37328159548B4242A34141B1A69CDB73031BAFA2@adsl-66-125-126-85.dsl.pltn13.pacbell.net> Hello, Where do I submit patches to? Minor change for the website.. Cheers, Peter Mueller --- yum-rh7x.php Mon Feb 2 19:10:16 2004 +++ yum-rh7x.php.old Mon Feb 2 19:08:44 2004 @@ -162,7 +162,7 @@
# rpm -ivh -http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386/yum-1.0.3-6.0 .7.x.legacy.noarch.rpm +http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386/yum-1.0.3-3.0 .7.x.legacy.noarch.rpm

yum automatically uses the correct configuration for your system (7.2 or From jkeating at j2solutions.net Tue Feb 3 16:43:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 3 Feb 2004 08:43:12 -0800 Subject: Two new bugzilla entries Message-ID: <200402030843.14050.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 https://bugzilla.fedora.us/show_bug.cgi?id=1257 - Temp file vuln in NetPBM https://bugzilla.fedora.us/show_bug.cgi?id=1256 - Information leak in util-linux - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAH8+g4v2HLvE71NURAn92AJwIEhUlJSd96el6jxoWq7cK0WylUQCgkOFz fCo6HeXvf+DOKmz4aLrp6Nc= =/WNC -----END PGP SIGNATURE----- From mail at jonaspasche.de Tue Feb 3 16:50:14 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Tue, 03 Feb 2004 17:50:14 +0100 Subject: Yum-rh7x.php diff In-Reply-To: <37328159548B4242A34141B1A69CDB73031BAFA2@adsl-66-125-126-85.dsl.pltn13.pacbell.net> References: <37328159548B4242A34141B1A69CDB73031BAFA2@adsl-66-125-126-85.dsl.pltn13.pacbell.net> Message-ID: <1075827013.3684.32.camel@leonardo> Hi, > Where do I submit patches to? Minor change for the website.. This list is the right place; Eric has CVS write access to the website, I'm sure he'll integrate the suggested change. Jonas -------------- 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 rostetter at mail.utexas.edu Tue Feb 3 17:13:06 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 11:13:06 -0600 Subject: Small Error at http://fedoralegacy.org/docs/yum-rh7x.php#step2 In-Reply-To: References: Message-ID: <20040203111306.620aqgcsg0oo4o4c@mail.ph.utexas.edu> Quoting Sean Kerner : > Just noticed a small error that should be corrected at: > > http://fedoralegacy.org/docs/yum-rh7x.php#step2 [...] > The version of YUM that is online right now is not the one listed. Rather > it's : > yum-1.0.3-6.0.7.x.legacy.noarch.rpm Fixed. Thanks! > Sean -- Eric Rostetter From raphael at clifford.net Tue Feb 3 17:25:37 2004 From: raphael at clifford.net (Raphael Clifford) Date: Tue, 03 Feb 2004 17:25:37 +0000 Subject: web site ammendments for yum Message-ID: <401FD991.6070308@clifford.net> Hi, http://www.fedoralegacy.org/download/ doesn't appear to contain clear instructions for how to use yum with fedora-legacy. I was thinking the following changes would be helpful a) A link to the current recommend versions of yum for each redhat release. That seems to be http://download.fedora.us/fedora/redhat/9/i386/RPMS.stable/yum-2.0.3-0.fdr.1.rh90.noarch.rpm and http://download.fedora.us/patches/redhat/8.0/i386/RPMS.stable/yum-2.0.3-0.fdr.1.rh80.noarch.rpm on http://www.fedora.us/wiki/FedoraHOWTO There is also a howto for yum and redhat 7.x at http://www.fedoralegacy.org/docs/yum-rh7x.php that really ought to be linked to. b) The sentence "After installing apt or yum, please see the mirror list and choose the closest and fastest mirror for your location." has a link to a page that does not mention yum at all. It is not clear to a non-expert what to do in this situation. I wonder if there is some overlap between pages that is causing the confusion. All the info needed to get a package management app working ought to be on one page IMHO. Cheers, Raphael From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 3 18:08:15 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 3 Feb 2004 19:08:15 +0100 Subject: Calling rsync testers... In-Reply-To: References: <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: <20040203190815.382fc020@localhost> Pekka Savola wrote : > Well, for me it worked just as simply locally hard-linking the files > before running rsync: > > onedir# for i in /ftp/mirrors/..../RedHat/RPMS/*.rpm; do ln $i; done > otherdir# for j in /ftp/mirrors/..../SRPMS/*.rpm; do ln $j; done Don't forget the wonderful world of "cp -al /source/dirname /destination/" :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2149.nptl Load : 0.07 0.10 0.09 From rostetter at mail.utexas.edu Tue Feb 3 19:37:50 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 13:37:50 -0600 Subject: Yum-rh7x.php diff In-Reply-To: <37328159548B4242A34141B1A69CDB73031BAFA2@adsl-66-125-126-85.dsl.pltn13.pacbell.net> References: <37328159548B4242A34141B1A69CDB73031BAFA2@adsl-66-125-126-85.dsl.pltn13.pacbell.net> Message-ID: <20040203133750.d7q9wk844k4wo0w4@mail.ph.utexas.edu> Quoting Peter Mueller : > Hello, > > Where do I submit patches to? Minor change for the website.. To the mailing list is fine, or to me if you want. > Cheers, > > Peter Mueller > > --- yum-rh7x.php Mon Feb 2 19:10:16 2004 > +++ yum-rh7x.php.old Mon Feb 2 19:08:44 2004 Was already fixed due to a previous message to the mailing list. Thanks anyway! :) -- Eric Rostetter From Craig.Miskell at agresearch.co.nz Tue Feb 3 19:43:50 2004 From: Craig.Miskell at agresearch.co.nz (Miskell, Craig) Date: Wed, 4 Feb 2004 08:43:50 +1300 Subject: Apt for rh7.3 Message-ID: Does anyone know when apt for rh7.3 will be available, and if so, would you let me know please? I would use yum except we use apt for all our other boxes so it would just cause confusion.. Thanks, Craig Miskell, Technical Support, AgResearch Invermay 03 489-9279 "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind- boggling amounts of excrement when you least expect it." -- Gene "spaf" Spafford (1992) ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From rohwedde at codegrinder.com Tue Feb 3 20:18:10 2004 From: rohwedde at codegrinder.com (Jason) Date: Tue, 3 Feb 2004 14:18:10 -0600 Subject: Apt for rh7.3 In-Reply-To: References: Message-ID: <20040203201810.GD2704@codegrinder.com> It's in bugzilla awaiting QA. https://bugzilla.fedora.us/show_bug.cgi?id=1174 -jason rohwedder On Wed, Feb 04, 2004 at 08:43:50AM +1300, Miskell, Craig wrote: > Does anyone know when apt for rh7.3 will be available, and if so, would > you let me know please? I would use yum except we use apt for all our > other boxes so it would just cause confusion.. > > Thanks, > > Craig Miskell, > Technical Support, > AgResearch Invermay > 03 489-9279 > "Usenet is like a herd of performing elephants with diarrhea -- > massive, difficult to redirect, awe-inspiring, entertaining, and > a source of mind- boggling amounts of excrement when you least > expect it." -- Gene "spaf" Spafford (1992) > ======================================================================= > Attention: The information contained in this message and/or attachments > from AgResearch Limited is intended only for the persons or entities > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipients is prohibited by AgResearch > Limited. If you have received this message in error, please notify the > sender immediately. > ======================================================================= > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Freedom_Lover at pobox.com Tue Feb 3 20:26:29 2004 From: Freedom_Lover at pobox.com (Todd) Date: Tue, 3 Feb 2004 15:26:29 -0500 Subject: Apt for rh7.3 In-Reply-To: References: Message-ID: <20040203202629.GA3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miskell, Craig wrote: > Does anyone know when apt for rh7.3 will be available, and if so, > would you let me know please? I would use yum except we use apt for > all our other boxes so it would just cause confusion.. It seems like apt isn't used all that much by anyone that's contributing here. So who knows when it'll get the proper review and be published. If you use apt, perhaps you could check out the bugzilla page for it and help get it to the point where it can be published? https://bugzilla.fedora.us/show_bug.cgi?id=1174 The package needs QA'd and given PUBLISH votes by a few people before it can get pushed out. As far as getting notification, I don't know if something like that would get posted to the announcement list of not. Jesse? - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The mother of idiots is always pregnant..... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIAP0uv+09NZUB1oRAgJJAKDNFYuIXfxgFNpcrWgPWQUSHlR9CgCglkdm 2Cjo5liRbK4oz9XlFonFHXs= =Xiqh -----END PGP SIGNATURE----- From rohwedde at codegrinder.com Tue Feb 3 20:33:15 2004 From: rohwedde at codegrinder.com (Jason) Date: Tue, 3 Feb 2004 14:33:15 -0600 Subject: Apt for rh7.3 In-Reply-To: <20040203202629.GA3731@psilocybe.teonanacatl.org> References: <20040203202629.GA3731@psilocybe.teonanacatl.org> Message-ID: <20040203203315.GE2704@codegrinder.com> On Tue, Feb 03, 2004 at 03:26:29PM -0500, Todd wrote: > It seems like apt isn't used all that much by anyone that's > contributing here. So who knows when it'll get the proper review and Hey now. I resemble that remark. =) -j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Tue Feb 3 20:38:51 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 14:38:51 -0600 Subject: web site ammendments for yum In-Reply-To: <401FD991.6070308@clifford.net> References: <401FD991.6070308@clifford.net> Message-ID: <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> Quoting Raphael Clifford : > http://www.fedoralegacy.org/download/ doesn't appear to contain clear > instructions for how to use yum with fedora-legacy. Nor apt, nor without apt/yum, etc. > a) A link to the current recommend versions of yum for each redhat release. I'll try to add some links to yum/apt when I get time. I'm not sure how this will be done, as it could potentially grow into a large list that is hard to maintain if I list each separately. So I may just make some kind of more generic link, or something... > There is also a howto for yum and redhat 7.x at > http://www.fedoralegacy.org/docs/yum-rh7x.php that really ought to be > linked to. The very last line of the page says: See also the Documentation page for more information on using yum. Which if you follow that Documentation link will show you the yum page you want. > b) The sentence "After installing apt or yum, please see the mirror list > and choose the > closest and fastest mirror for your location." has a link to a page that > does not mention yum at all. It is not clear to a non-expert what to do > in this situation. We're still waiting for mirrors. Until there is an official list of mirrors, that page is kind of pointless... I assumed the list of mirrors would be available in a day or two after that page went up, so I linked it in. But so far no mirror list has been provided... The page is there mostly because it provides info on how to get apt mirrors in. I would love for it to also provide info on yum mirrors, but no one has contributed any such info. I'll try to put something out there about our yum coming preconfigured, etc. and a pointer to the documentation page, but I'm not yet sure how this will all work out in the end. > I wonder if there is some overlap between pages that is causing the > confusion. All the info needed to get a package management app working > ought to be on one page IMHO. Well, the bigger problem is missing content. I suppose we can consolidate and merge stuff, but until we get the missing content we're going to be in trouble no matter how many or how few pages we have. Bottom line is I don't use apt, I don't use yum, I am not a mirror, so I can't really document these things. If someone who uses apt/yum provides me with accurate content, I'll put it on the web. If someone sets up some mirrors and feeds me the data, I'll post it on the web. But I can't do it all alone... Well, actually I will try to do it alone if no one else steps up, but it will take a long time to do it... So please, if you can help, step up and help! None the less, you comments are useful, and provide me with some ideas. I'll see what I can do about the situations you mention. > Cheers, > Raphael -- Eric Rostetter From Freedom_Lover at pobox.com Tue Feb 3 20:54:03 2004 From: Freedom_Lover at pobox.com (Todd) Date: Tue, 3 Feb 2004 15:54:03 -0500 Subject: Apt for rh7.3 In-Reply-To: <20040203203315.GE2704@codegrinder.com> References: <20040203202629.GA3731@psilocybe.teonanacatl.org> <20040203203315.GE2704@codegrinder.com> Message-ID: <20040203205403.GD3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason wrote: > On Tue, Feb 03, 2004 at 03:26:29PM -0500, Todd wrote: >> It seems like apt isn't used all that much by anyone that's >> contributing here. So who knows when it'll get the proper review >> and > > Hey now. I resemble that remark. =) Hehe. I've looked at the apt bugzilla entry a few times, but I just don't think I use apt enough to give it the proper QA. I was thinking someone else surely used it enough to QA the packages you've worked on. If no QA's get done on that soon, I'll try to give it a whirl. So far, it seems that nothing gets a package published quicker than when I start to work on it. It's when I'm just about done with a QA report that I see Jesse email the list with an announcement. :) - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Life is the art of drawing sufficient conclusions from insignificant premises -- Samuel Butler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIApruv+09NZUB1oRAhj5AKDZ3ak8YzYX1fD0b6/QbZlJRYRMPACeIgoq QQgaGWTPW1ZRIn+TbTxyVp0= =ELlb -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Feb 3 21:04:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 3 Feb 2004 13:04:13 -0800 Subject: Apt for rh7.3 In-Reply-To: <20040203205403.GD3731@psilocybe.teonanacatl.org> References: <20040203203315.GE2704@codegrinder.com> <20040203205403.GD3731@psilocybe.teonanacatl.org> Message-ID: <200402031304.18400.jkeating@j2solutions.net> On Tuesday 03 February 2004 12:54, Todd wrote: > So far, it seems that nothing gets a package published quicker than > when I start to work on it. It's when I'm just about done with a QA > report that I see Jesse email the list with an announcement. :) HAHA! I'll hold back on this one, I swear! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 admin at cs.montana.edu Tue Feb 3 21:27:18 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Tue, 3 Feb 2004 14:27:18 -0700 (MST) Subject: Apt for rh7.3 In-Reply-To: <20040203205403.GD3731@psilocybe.teonanacatl.org> References: <20040203202629.GA3731@psilocybe.teonanacatl.org> <20040203203315.GE2704@codegrinder.com> <20040203205403.GD3731@psilocybe.teonanacatl.org> Message-ID: <3377.153.90.196.197.1075843638.squirrel@webtest.cs.montana.edu> > Jason wrote: >> On Tue, Feb 03, 2004 at 03:26:29PM -0500, Todd wrote: >>> It seems like apt isn't used all that much by anyone that's >>> contributing here. So who knows when it'll get the proper review >>> and I use apt for updating all my clients and servers. Never used yum. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From admin at cs.montana.edu Tue Feb 3 21:27:49 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Tue, 3 Feb 2004 14:27:49 -0700 (MST) Subject: Apt for rh7.3 In-Reply-To: References: Message-ID: <3384.153.90.196.197.1075843669.squirrel@webtest.cs.montana.edu> Miskell, Craig said: > Does anyone know when apt for rh7.3 will be available, and if so, would > you let me know please? I would use yum except we use apt for all our > other boxes so it would just cause confusion.. > I just use the freshrpms apt, works fine. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From Craig.Miskell at agresearch.co.nz Tue Feb 3 21:39:23 2004 From: Craig.Miskell at agresearch.co.nz (Miskell, Craig) Date: Wed, 4 Feb 2004 10:39:23 +1300 Subject: Apt for rh7.3 Message-ID: > -----Original Message----- > From: Lucas Albers [mailto:admin at cs.montana.edu] > Sent: Wednesday, 4 February 2004 10:28 a.m. > To: fedora-legacy-list at redhat.com > Subject: Re: Apt for rh7.3 > > > > Miskell, Craig said: > > Does anyone know when apt for rh7.3 will be available, and > if so, would > > you let me know please? I would use yum except we use apt > for all our > > other boxes so it would just cause confusion.. > > > I just use the freshrpms apt, works fine. Cheers - I appreciate the desire for the FL apt package to be QA'd, but for now, I'm using the freshrpms apt. However, in the interests of being friendly, I'll see if I can find some time to do the QA on the FL package later today. Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From dawson at fnal.gov Tue Feb 3 22:13:28 2004 From: dawson at fnal.gov (Troy Dawson) Date: Tue, 03 Feb 2004 16:13:28 -0600 Subject: web site ammendments for yum In-Reply-To: <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> Message-ID: <40201D08.1070304@fnal.gov> Eric Rostetter wrote: >Quoting Raphael Clifford : > > > > > >>b) The sentence "After installing apt or yum, please see the mirror list >> and choose the >>closest and fastest mirror for your location." has a link to a page that >>does not mention yum at all. It is not clear to a non-expert what to do >>in this situation. >> >> > >We're still waiting for mirrors. Until there is an official list of >mirrors, that page is kind of pointless... I assumed the list of mirrors >would be available in a day or two after that page went up, so I linked >it in. But so far no mirror list has been provided... > >The page is there mostly because it provides info on how to get apt mirrors >in. I would love for it to also provide info on yum mirrors, but no one >has contributed any such info. I'll try to put something out there about >our yum coming preconfigured, etc. and a pointer to the documentation page, >but I'm not yet sure how this will all work out in the end. > > > Not wanting to rush anyone, but wasn't there many responses to the call to send mirror info to mirrors at fedoralegacy.org ? I know I send our mirror info, which should work for both apt and yum. But this sounds like it's going to be a while before the page goes up. If people are busy, that's understandable, or was there some other problem? Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From jkeating at j2solutions.net Tue Feb 3 22:27:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 3 Feb 2004 14:27:50 -0800 Subject: web site ammendments for yum In-Reply-To: <40201D08.1070304@fnal.gov> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <40201D08.1070304@fnal.gov> Message-ID: <200402031427.54966.jkeating@j2solutions.net> On Tuesday 03 February 2004 14:13, Troy Dawson wrote: > Not wanting to rush anyone, but wasn't there many responses to the > call to send mirror info to mirrors at fedoralegacy.org ? I know I send > our mirror info, which should work for both apt and yum. But this > sounds like it's going to be a while before the page goes up. If > people are busy, that's understandable, or was there some other > problem? Troy There is no problem. I have been collecting these notices, and giving mirrors a chance to fully sync before I publish anything. I have some free time tonight, I'll try to compile a list of what I have right now. I didn't want to publish a list, get a few more servers, republish the list, get a few more, re publish.... etc.... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 mail at jonaspasche.de Tue Feb 3 22:44:00 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Tue, 03 Feb 2004 23:44:00 +0100 Subject: web site ammendments for yum In-Reply-To: <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> Message-ID: <1075848240.3684.116.camel@leonardo> Hi there, > > http://www.fedoralegacy.org/download/ doesn't appear to contain clear > > instructions for how to use yum with fedora-legacy. > > Nor apt, nor without apt/yum, etc. I really have conflicting feelings about the Download page. Fedora Legacy isn't something to download; it is something to _use_, and the howto-style documentation tells users how to use it. Therefore I plead for turning the current Download page into a reference page that tells: 1) "If you are new to this stuff and don't know how to use apt/yum, please go the documentation section. This page isn't for you." 2) A link to download.fedoralegacy.org, for people that simply want to download updates manually by HTTP 3) A list of full yum/apt repository configurations 4) A list of mirrors to use instead of download.fedoralegacy.org IMHO, the download page should be used by users who already know how to use yum/apt and just want to put the right repositories into their configuration. Anybody who'd be not be able to do that should follow the detailed documentation instead. I'd prefer not including instructions on how to download/install yum/apt. If a user doesn't have yum/apt he should use the howto-style documentation. The first paragraph should make this clear. > I'm not sure how > this will be done, as it could potentially grow into a large list that > is hard to maintain if I list each separately. So I may just make some > kind of more generic link, or something... Suggestion #1: Just link the _directory_ and tell the user to download the most current versions of yum/apt from there. Suggestion #2: As the pages are already written in PHP, why not include a conf.php which ships variables like... $current_yum_rh7_url $current_apt_rh7_url $current_yum_rh8_url $current_apt_rh8_url That would you'd always have a handy URL at your fingertips. > We're still waiting for mirrors. Until there is an official list of > mirrors, that page is kind of pointless... I assumed the list of mirrors > would be available in a day or two after that page went up, so I linked > it in. But so far no mirror list has been provided... AFAIK, Jesse has an eye on this. For the repository listings (see above): --- cut --- If you're using apt, please add the line that matches your distribution to your /etc/apt/sources.list: Red Hat Linux 7.2: rpm http://download.fedoralegacy.org/apt redhat/7.2/i386 os updates legacy-utils Red Hat Linux 7.3: rpm http://download.fedoralegacy.org/apt redhat/7.3/i386 os updates legacy-utils Red Hat Linux 8.0: rpm http://download.fedoralegacy.org/apt redhat/8.0/i386 os updates legacy-utils If you're using yum, please add the following blocks to your /etc/yum.conf (these work for all supported releases of Red Hat Linux): [base] name=Red Hat Linux $releasever base baseurl=http://download.fedoralegacy.org/redhat/$releasever/os/$basearch [updates] name=Red Hat Linux $releasever updates baseurl=http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch If you are already using another repository for official Red Hat packages and updates, please note the following: - You only need one repository providing the "os" aka "base" channel. If you already have a repository providing it, you may want to keep only one. The contents of this channels will never change. - "updates" is the channel we're using for Fedora Legacy updates. If you already have a repository providing a Red Hat "updates" channel, make sure that you keep only the "updates" channel from us and remove that channel from your other repository. Your former "updates" channel only provided Red Hat official updates. YOUR SYSTEM WILL NOT RECEIVE LEGACY UPDATES if you're using any other repository providing only official Red Hat updates! You have been warned. --- cut --- Jonas -------------- 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 rostetter at mail.utexas.edu Tue Feb 3 23:30:16 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 17:30:16 -0600 Subject: web site ammendments for yum In-Reply-To: <401FD991.6070308@clifford.net> References: <401FD991.6070308@clifford.net> Message-ID: <20040203173016.lmqww0goo800kw44@mail.ph.utexas.edu> Quoting Raphael Clifford : > http://www.fedoralegacy.org/download/ doesn't appear to contain clear > instructions for how to use yum with fedora-legacy. I was thinking the It now simply points you to the documentation page for info on using yum and apt. > a) A link to the current recommend versions of yum for each redhat release. Still now sure about this. I think the docs will be enough, since they tell you how to install it, etc. But comments/suggestions/patches will be gladly accepted on this issue. > There is also a howto for yum and redhat 7.x at > http://www.fedoralegacy.org/docs/yum-rh7x.php that really ought to be > linked to. It was indirectly. I've made a apt-rh8.php page also now, even though the FL apt doesn't actually exist yet... > b) The sentence "After installing apt or yum, please see the mirror list > and choose the > closest and fastest mirror for your location." has a link to a page that > does not mention yum at all. It is not clear to a non-expert what to do > in this situation. Yum is now mentioned there. > I wonder if there is some overlap between pages that is causing the > confusion. All the info needed to get a package management app working > ought to be on one page IMHO. I've merged the apt/yum command summaries into their documentation files and removed them from the downloads page. The download page now just tells you to see to documentation pages for help. > Cheers, > Raphael Thanks for your suggestions! -- Eric Rostetter From rostetter at mail.utexas.edu Tue Feb 3 23:38:19 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 17:38:19 -0600 Subject: web site ammendments for yum In-Reply-To: <40201D08.1070304@fnal.gov> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <40201D08.1070304@fnal.gov> Message-ID: <20040203173819.81xbgokg044owoo4@mail.ph.utexas.edu> Quoting Troy Dawson : > Not wanting to rush anyone Why not? *grin* > but wasn't there many responses to the call > to send mirror info to mirrors at fedoralegacy.org ? I know I send our > mirror info, which should work for both apt and yum. But this sounds > like it's going to be a while before the page goes up. If people are > busy, that's understandable, or was there some other problem? The info goes ultimately to Jesse. I think he's been busy, and I don't know where he is with the mirroring process. All I can say is that he hasn't sent me any info, so I haven't put anything on the web site. I've not asked him about progress or anything yet. I can say Jesse is doing a great job running this project, and we should cut him as much slack as possible, while still nagging him to do more. Of course additional volunteers to help with the project would be great too ;) Maybe take over some of the work that he's saddled with... > Troy -- Eric Rostetter From rostetter at mail.utexas.edu Tue Feb 3 23:49:02 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Feb 2004 17:49:02 -0600 Subject: web site ammendments for yum In-Reply-To: <1075848240.3684.116.camel@leonardo> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <1075848240.3684.116.camel@leonardo> Message-ID: <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> Quoting Jonas Pasche : > I really have conflicting feelings about the Download page. Fedora > Legacy isn't something to download; it is something to _use_, and the > howto-style documentation tells users how to use it. Therefore I plead > for turning the current Download page into a reference page that tells: Yes, I feel your pain. > 1) "If you are new to this stuff and don't know how to use apt/yum, > please go the documentation section. This page isn't for you." Interesting idea... (Links are there, but no language like your above language). > 2) A link to download.fedoralegacy.org, for people that simply want to > download updates manually by HTTP There, but should be more obvious... > 3) A list of full yum/apt repository configurations Not sure what that means (how it differs from the mirror list files for apt/yum on the mirrors page). > 4) A list of mirrors to use instead of download.fedoralegacy.org Is linked to from that page (as a separate mirror page). > IMHO, the download page should be used by users who already know how to > use yum/apt and just want to put the right repositories into their > configuration. Anybody who'd be not be able to do that should follow the > detailed documentation instead. Yes. But I like having the mirror page separate, if for no other reason than to make it easier to update/automate/etc. > I'd prefer not including instructions on how to download/install > yum/apt. If a user doesn't have yum/apt he should use the howto-style > documentation. The first paragraph should make this clear. Okay, I can understand that. (and it makes my life easy, so why not). > Suggestion #1: Just link the _directory_ and tell the user to download > the most current versions of yum/apt from there. Yeah, that was the kind of thing I was leaning towards. > Suggestion #2: As the pages are already written in PHP, why not include > a conf.php which ships variables like... Same problem of keeping the conf.php up to date. > AFAIK, Jesse has an eye on this. Jesse's got an eye on everything ;) > --- cut --- > > If you're using apt, please add the line that matches your distribution > to your /etc/apt/sources.list: >From what Jesse told me, I thought there was some way to do this automagically using the files he posted on the mirrors page??? > If you're using yum, please add the following blocks to your > /etc/yum.conf (these work for all supported releases of Red Hat Linux): The defaults are in our yum package, so we don't need to do this until we have mirrors, no? > If you are already using another repository for official Red Hat > packages and updates, please note the following: > > - You only need one repository providing the "os" aka "base" channel. If > you already have a repository providing it, you may want to keep only > one. The contents of this channels will never change. > > - "updates" is the channel we're using for Fedora Legacy updates. If you > already have a repository providing a Red Hat "updates" channel, make > sure that you keep only the "updates" channel from us and remove that > channel from your other repository. Your former "updates" channel only > provided Red Hat official updates. YOUR SYSTEM WILL NOT RECEIVE LEGACY > UPDATES if you're using any other repository providing only official > Red Hat updates! You have been warned. > > --- cut --- Now that info would be useful. So, Jonas: First, see the new pages I just updated. Then, help improve them with your changes above as you see fit. (See what you get for expressing an opinion? Now I expect you to do work...) > Jonas -- Eric Rostetter From jkeating at j2solutions.net Tue Feb 3 23:46:49 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 3 Feb 2004 15:46:49 -0800 Subject: web site ammendments for yum In-Reply-To: <20040203173819.81xbgokg044owoo4@mail.ph.utexas.edu> References: <401FD991.6070308@clifford.net> <40201D08.1070304@fnal.gov> <20040203173819.81xbgokg044owoo4@mail.ph.utexas.edu> Message-ID: <200402031546.54739.jkeating@j2solutions.net> On Tuesday 03 February 2004 15:38, Eric Rostetter wrote: > I can say Jesse is doing a great job running this project, and we > should cut him as much slack as possible, while still nagging him to > do more. Hehe, your nagging keeps me honest (; > Of course additional volunteers to help with the project > would be great too ;) Maybe take over some of the work that he's > saddled with... Maybe a running "Task List" of things that need to be done to further the project. I'm sure a lot of the server side stuff will fall on me, but I do accept help where/when possible. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Feb 3 23:54:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 3 Feb 2004 15:54:05 -0800 Subject: web site ammendments for yum In-Reply-To: <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> References: <401FD991.6070308@clifford.net> <1075848240.3684.116.camel@leonardo> <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> Message-ID: <200402031554.05665.jkeating@j2solutions.net> On Tuesday 03 February 2004 15:49, Eric Rostetter wrote: > > IMHO, the download page should be used by users who already know > > how to use yum/apt and just want to put the right repositories into > > their configuration. Anybody who'd be not be able to do that should > > follow the detailed documentation instead. > > Yes. But I like having the mirror page separate, if for no other > reason than to make it easier to update/automate/etc. The current "mirror list" files are special to apt, and are used when apt is ran for the first time to get a list of mirrors the user can interactively choose from. The future mirror list will be a lot less "sparse" and "cryptic" and will have full information like location, bandwidth, hours of operation (if not 24/7) and example yum/apt conf entries. The current files MUST stay the same way they are/were as they are really behind the scenes apt config files. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 mail at jonaspasche.de Wed Feb 4 00:34:21 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Wed, 04 Feb 2004 01:34:21 +0100 Subject: web site ammendments for yum In-Reply-To: <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <1075848240.3684.116.camel@leonardo> <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> Message-ID: <1075854860.3684.198.camel@leonardo> Hi Eric, > > 1) "If you are new to this stuff and don't know how to use apt/yum, > > please go the documentation section. This page isn't for you." > > Interesting idea... (Links are there, but no language like your above > language). Hehe, this hasn't been a suggestion for publishing "as is". I just wanted to give an idea on what we should tell users here IMHO, to get feedback before turning it into a full-featured paragraph. However, the freshly updated Download page does reflect this while being more honest to the user than me. :) > > 2) A link to download.fedoralegacy.org, for people that simply want to > > download updates manually by HTTP > > There, but should be more obvious... It's quite good right now. > > 3) A list of full yum/apt repository configurations > > Not sure what that means (how it differs from the mirror list files > for apt/yum on the mirrors page). People that are downloading yum (and later, apt) from us have it already preconfigured. I thought about configuration entries for people that are already using a yum/apt from another packager (e.g. freshrpms) for some repositories and simply want to include our repository into their current configuration instead of completely switching to our version of apt/yum. The configuration file snippets are mainly the important part of the configuration files we ship preconfigured with _our_ yum/apt. Putting them on the Download page enables people to use our repositories without downloading and installing _our_ yum/apt. The principle behind this is: People who _don't_ have apt/yum should follow our detailed instructions and use our preconfigured packages. People who already _have_ apt/yum need information about how they can include our repositories into their existing configuration. This information isn't yet available in a clean, simple manner. > > 4) A list of mirrors to use instead of download.fedoralegacy.org > > Is linked to from that page (as a separate mirror page). Yes, quite good (the page itself, not its usefullness without any yet available mirror). > Yes. But I like having the mirror page separate, if for no other reason > than to make it easier to update/automate/etc. That's just fine. The link to that page on the Download page should be enough here. > > Suggestion #2: As the pages are already written in PHP, why not include > > a conf.php which ships variables like... > > Same problem of keeping the conf.php up to date. Not exactly, because you just need to update _one_ file and have the others automatically point to current locations. > > If you're using apt, please add the line that matches your distribution > > to your /etc/apt/sources.list: > > >From what Jesse told me, I thought there was some way to do this automagically > using the files he posted on the mirrors page??? Well, I'm not an apt expert, but IMHO these files cannot be used by a plain apt package. They are repository listings that can be used by mirror-select.lua, an apt "plugin" that cares for mirror selection. However, this plugin is not yet shipped with apt from freshrpms or apt from fedora.us. Without an apt package that has the mirror-select.lua script, these files are not usable! One can only manually extract the needed information and put it into /etc/apt/sources.list. > So, Jonas: First, see the new pages I just updated. Then, help improve them > with your changes above as you see fit. (See what you get for expressing > an opinion? Now I expect you to do work...) From my point of view, only the configuration file snippets need to be included, if you and the list agree with my argumentation on this topic. My last posting included the complete paragraphs that are needed for this. Jonas -------------- 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 mail at jonaspasche.de Wed Feb 4 00:51:06 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Wed, 04 Feb 2004 01:51:06 +0100 Subject: web site ammendments for yum In-Reply-To: <200402031546.54739.jkeating@j2solutions.net> References: <401FD991.6070308@clifford.net> <40201D08.1070304@fnal.gov> <20040203173819.81xbgokg044owoo4@mail.ph.utexas.edu> <200402031546.54739.jkeating@j2solutions.net> Message-ID: <1075855866.3684.216.camel@leonardo> Hi Jesse, > Maybe a running "Task List" of things that need to be done to further > the project. Good idea! Any preferences in where/how to keep it, e.g. on the web, regularly posting it to the list..? Summarizing ongoing discussions, the following things come to my mind (order != priority), but I may have missed an unlimited number of topics because I only track selected threads on this list which are of interest for the documentation area. * preconfigured apt for 8.0 * preconfigured apt for 7.x??? * preconfigured yum for 8.0??? (which would in turn raise the "rpm upgrade or not - yum1 or yum2" issue again) * Documentation on the package submission and publishing policy (my part...) * Integration of my Fedora Legacy schedule diagram somewhere into the website (if appreciated) * QA, QA, QA * Getting mirrors on our mirrors list * Do we need "How to set up a mirror" documentation? Jonas -------------- 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 pmatilai at welho.com Wed Feb 4 09:21:34 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 4 Feb 2004 11:21:34 +0200 (EET) Subject: web site ammendments for yum In-Reply-To: <1075854860.3684.198.camel@leonardo> References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <1075848240.3684.116.camel@leonardo> <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> <1075854860.3684.198.camel@leonardo> Message-ID: On Wed, 4 Feb 2004, Jonas Pasche wrote: > > > 3) A list of full yum/apt repository configurations > > > > Not sure what that means (how it differs from the mirror list files > > for apt/yum on the mirrors page). > > People that are downloading yum (and later, apt) from us have it already > preconfigured. I thought about configuration entries for people that are > already using a yum/apt from another packager (e.g. freshrpms) for some > repositories and simply want to include our repository into their > current configuration instead of completely switching to our version of > apt/yum. > > The configuration file snippets are mainly the important part of the > configuration files we ship preconfigured with _our_ yum/apt. Putting > them on the Download page enables people to use our repositories without > downloading and installing _our_ yum/apt. > > The principle behind this is: > > People who _don't_ have apt/yum should follow our detailed instructions > and use our preconfigured packages. > > People who already _have_ apt/yum need information about how they can > include our repositories into their existing configuration. This > information isn't yet available in a clean, simple manner. Indeed. Same goes for fedora.us itself actually.. I think People should be encouraged to use the FL versions of apt/yum because at least the apt package has various important features like signature checking embedded which plain upstream apt doesn't have. However that's not an excuse for not providing the sources.list/yum.conf information in easy copy-paste format. > > > > 4) A list of mirrors to use instead of download.fedoralegacy.org > > > > Is linked to from that page (as a separate mirror page). > > Yes, quite good (the page itself, not its usefullness without any yet > available mirror). > > > Yes. But I like having the mirror page separate, if for no other reason > > than to make it easier to update/automate/etc. > > That's just fine. The link to that page on the Download page should be > enough here. > > > > Suggestion #2: As the pages are already written in PHP, why not include > > > a conf.php which ships variables like... > > > > Same problem of keeping the conf.php up to date. > > Not exactly, because you just need to update _one_ file and have the > others automatically point to current locations. The apt mirror-list "format" is trivial to parse in php/python/whatever language, with a little munging you can formulate the yum baseurl entries from it as well. So you only have to keep one mirror-list up to date. > > > > If you're using apt, please add the line that matches your distribution > > > to your /etc/apt/sources.list: > > > > >From what Jesse told me, I thought there was some way to do this automagically > > using the files he posted on the mirrors page??? > > Well, I'm not an apt expert, but IMHO these files cannot be used by a > plain apt package. They are repository listings that can be used by > mirror-select.lua, an apt "plugin" that cares for mirror selection. > However, this plugin is not yet shipped with apt from freshrpms or apt > from fedora.us. > > Without an apt package that has the mirror-select.lua script, these > files are not usable! One can only manually extract the needed > information and put it into /etc/apt/sources.list. Yep, apt itself cannot use the mirror list. But like said it's trivial to parse the format in a script to generate both yum and apt configs out of it. - Panu - From raphael at clifford.net Wed Feb 4 09:52:03 2004 From: raphael at clifford.net (Raphael Clifford) Date: Wed, 04 Feb 2004 09:52:03 +0000 Subject: web site ammendments for yum Message-ID: <4020C0C3.5070803@clifford.net> [...] "The very last line of the page says: See also the Documentation page for more information on using yum. Which if you follow that Documentation link will show you the yum page you want. " Yes. That is where I got the link I pasted from. " Bottom line is I don't use apt, I don't use yum, I am not a mirror, so I can't really document these things. If someone who uses apt/yum provides me with accurate content, I'll put it on the web. If someone sets up some mirrors and feeds me the data, I'll post it on the web. But I can't do it all alone... Well, actually I will try to do it alone if no one else steps up, but it will take a long time to do it... So please, if you can help, step up and help! " I am by no means an expert but I am a yum user so I know the basics. If there are any specific questions then please ask and I will do my best. Overall I think it would be good to have a page with an obvious name ("Download" is good. So would be "Getting Started") that a non-expert will go to and will provide all the info needed to get started. A minimalist structure could be like this (I've attached annotations in between XXXs. Sorry this isn't a diff) ---------------------------------------------- a) Installing and Upgrading packages In order to install packages from Fedora Legacy, you could manually download and install individual packages from the fedoralegacy.org (XXX link XXX) tree, however it is recommended instead that you install one of the automatic package management programs apt (XXX link to page with apt packages for fedora-legacy and any info for unsupported redhat versions XXX) or yum (XXX link to page with yum packages for fedora-legacy and any info for unsupported redhat versions XXX). Both apt and yum package managers handle automatic downloading and installation of packages you specify, and are preconfigured to use the Fedora Legacy repositories. After installing apt or yum, you may optionally set it up to use some mirror sites. To setup apt/yum to use mirror(s), please see the mirror list and choose the closest and fastest mirror(s) for your location. Then edit your client's configuration file (apt uses /etc/apt/sources.list while yum uses /etc/yum.conf) to use this mirror. You may skip this step if you downloaded the preconfigured apt/yum packages although it is recommended that you return to it once everything is working correctly. b) Getting started with yum/apt Once you have got the preconfigured yum/apt packages installed you may update packages on your system following the standard instructions here (XXX link XXX) c) Package Repositories Specific packages can be found at http://download.fedoralegacy.org/ with support for the apt and yum update tools (XXX is this true? I mean what can a user do with that piece of information? XXX) (as well as direct downloads). There is a tree for each supported OS version, and each of those trees has a standard set of sub-trees. Fedora Legacy updates will be published in the "updates" sub-tree along with any existing distribution updates. In addition to the Fedora Legacy updates, there is other software available in different sub-trees. The sub-trees for each OS version supported are organized as follows: os Packages from the original distribution. updates All applicable updates from Red Hat, Fedora Core, and/or Fedora Legacy. updates-testing Updates from the Fedora Legacy Project currently in the testing phase before they are published for distribution. legacy-utils Support tools for Legacy servers such as yum, apt-get, etc. d) Links For further documentation on related topics see http://www.fedora.us/wiki/FedoraDocuments ----------------------------------------------------------------------------- I am not at all clear what the relationship between www.fedoralegacy.org and http://www.fedora.us/wiki/FedoraDocuments is. There seems to be a lot of info in the latter that is not in the former but some overlap. Cheers, Raphael From mail at jonaspasche.de Wed Feb 4 13:18:38 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Wed, 04 Feb 2004 14:18:38 +0100 Subject: web site ammendments for yum In-Reply-To: <4020C0C3.5070803@clifford.net> References: <4020C0C3.5070803@clifford.net> Message-ID: <1075900718.3736.95.camel@leonardo> Hi Raphael, > Overall I think it would be good to have a page with an obvious name > ("Download" is good. So would be "Getting Started") that a non-expert > will go to and will provide all the info needed to get started. I fear that "Getting started" is equivalent to "Download" to the average impatient user, just as a "Screenshots" section is obviously the most important page for a GUI application. The first question when hearing something about a project is "Cool, where can I download it?". That's the reason why I heavily insisted on putting a strong advice on the "Download" page to tell the user that he should follow "Documentation" instead, because the "Download" page is only for experts. > [...] > however it is recommended instead that you install one > of the automatic package management programs apt (XXX link to page with > apt packages for fedora-legacy and any info for unsupported redhat > versions XXX) or yum (XXX link to page with yum packages for > fedora-legacy and any info for unsupported redhat versions XXX). > [...] > After installing apt or yum, you may optionally set it up to use some > mirror sites. > [...] > Once you have got the preconfigured yum/apt packages installed you may > update packages on your system following the standard instructions here > (XXX link XXX) > [...] Sorry, but I don't understand how exactly this differs from the instructions that can be found in the Documentation section. "Install apt or yum", "Set up mirrors", "Update your system"... it looks like a short summary of the full documentation to me, leaving out at least the important part of importing the Fedora Legacy GPG key which isn't too obvious even to experienced users. I don't think we should put even more documentation onto the Download page as we have a separate Documentation page. From my point of view, the download page should only used by users that know what to do and just need the according information (e.g. where are the repositories, what channels are provided, what do I have to put in my repository configuration). It does no good if we try to hold the hand of people who are not sure how to handle this information. These people should go to the Documentation page, and the Download page should strongly encourage them to do so. > Specific packages can be found at http://download.fedoralegacy.org/ with > support for the apt and yum update tools (XXX is this true? I mean what > can a user do with that piece of information? XXX) Not too much; an apt/yum user need the repository entries in copy+paste format for his configuration file. However, there might be people that simply want to download a specific package manually. > In addition to the Fedora Legacy updates, there is other software > available in different sub-trees. I know that this has already been in the original file, but it's a bit confusing that we start with "In _addition_ to ... updates" and then listing all the channels _including_ the updates channel. > legacy-utils > Support tools for Legacy servers such as yum, apt-get, etc. I vote for using "apt" instead of "apt-get" here, because the tool is "apt", and "apt-get" is a command of the "apt" tool. > I am not at all clear what the relationship between www.fedoralegacy.org > and http://www.fedora.us/wiki/FedoraDocuments is. There seems to be a > lot of info in the latter that is not in the former but some overlap. - The fedora.us wiki contains the roots of the Fedora Legacy project, so you would find some content there. It should be on our todo list to convert that content to fedoralegacy.org, maybe replacing the according wiki pages with a link to the new and updated pages. - Many of the documents on fedora.us contain information on using the additional packages for 8.0, 9 and FC1. This information is not needed on fedoralegacy.org, and I'd expect it to be converted to pages on fedora.redhat.com some day. We can't use the Fedora Howto because we don't distribute Fedora packages. We can't use the Mirror Howto because our mirror's aren't the same. We _do_ need an adaption of "Policies and Procedure" that matches our requirements; that's my part actually. We don't need most of the packaging standards because we only update packages that already exist, and so on. Jonas -------------- 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 mail at jonaspasche.de Wed Feb 4 13:32:16 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Wed, 04 Feb 2004 14:32:16 +0100 Subject: web site ammendments for yum In-Reply-To: References: <401FD991.6070308@clifford.net> <20040203143851.jrpiscos0gow8s44@mail.ph.utexas.edu> <1075848240.3684.116.camel@leonardo> <20040203174902.moq7c48w0wc88co8@mail.ph.utexas.edu> <1075854860.3684.198.camel@leonardo> Message-ID: <1075901535.3736.109.camel@leonardo> Hi Panu, > I think People should be encouraged to use the FL versions of apt/yum > because at least the apt package has various important features like > signature checking embedded which plain upstream apt doesn't have. Yes, for sure. We should encourage them, but we cannot and should not force them. But we can tell them why our apt/yum is better. :-) > The apt mirror-list "format" is trivial to parse in php/python/whatever > language, with a little munging you can formulate the yum baseurl entries > from it as well. So you only have to keep one mirror-list up to date. That's a job for either the mirror list maintainer or the website maintainer... are there ambitions or maybe already existing code to generate these files automatically out of a mirror list? Jonas -------------- 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 rostetter at mail.utexas.edu Wed Feb 4 17:08:54 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 4 Feb 2004 11:08:54 -0600 Subject: web site ammendments for yum In-Reply-To: <1075855866.3684.216.camel@leonardo> References: <401FD991.6070308@clifford.net> <40201D08.1070304@fnal.gov> <20040203173819.81xbgokg044owoo4@mail.ph.utexas.edu> <200402031546.54739.jkeating@j2solutions.net> <1075855866.3684.216.camel@leonardo> Message-ID: <20040204110854.gw04kg4wwckc4cso@mail.ph.utexas.edu> Quoting Jonas Pasche : > > Maybe a running "Task List" of things that need to be done to further > > the project. > > Good idea! Any preferences in where/how to keep it, e.g. on the web, > regularly posting it to the list..? I'll put it up as a web page under the participate page. > * Documentation on the package submission and publishing policy (my > part...) I've already started such a page... > * Do we need "How to set up a mirror" documentation? Probably. I didn't start one yet since it seemed premature (with no mirrors listed yet, etc). Can go on the mirror page, or separate. > Jonas -- Eric Rostetter From raphael at clifford.net Wed Feb 4 17:34:52 2004 From: raphael at clifford.net (Raphael Clifford) Date: Wed, 04 Feb 2004 17:34:52 +0000 Subject: web site ammendments for yum Message-ID: <40212D3C.2050500@clifford.net> > > >> [...] >> however it is recommended instead that you install one=20 >> of the automatic package management programs apt (XXX link to page with=20 >> apt packages for fedora-legacy and any info for unsupported redhat=20 >> versions XXX) or yum (XXX link to page with yum packages for=20 >> fedora-legacy and any info for unsupported redhat versions XXX). >> [...] >> After installing apt or yum, you may optionally set it up to use some=20 >> mirror sites. >> [...] >> Once you have got the preconfigured yum/apt packages installed you may=20 >> update packages on your system following the standard instructions here=20 >> (XXX link XXX) >> [...] > > " Sorry, but I don't understand how exactly this differs from the instructions that can be found in the Documentation section. "Install apt or yum", "Set up mirrors", "Update your system"... it looks like a short summary of the full documentation to me, leaving out at least the important part of importing the Fedora Legacy GPG key which isn't too obvious even to experienced users. I don't think we should put even more documentation onto the Download page as we have a separate Documentation page. From my point of view, the download page should only used by users that know what to do and just need the according information (e.g. where are the repositories, what channels are provided, what do I have to put in my repository configuration). " That is OK but see comments below.. " It does no good if we try to hold the hand of people who are not sure how to handle this information. These people should go to the Documentation page, and the Download page should strongly encourage them to do so. " The motivation is to have a page a non-expert can go to and by reading it and following the links be able to get yum or apt working on their system. If there is another page that does the same thing then that is great but I haven't seen it. The Documentation page currently has three links and almost nothing else on it. They are * Using Fedora Legacy with yum on Red Hat 7.x * Using Fedora Legacy with apt on Red Hat 8.0 * How can I participate? This page is clearly only of use to people who want to do one of those three things and know what yum and apt are for. There is no mention of yum with redhat 8.0 etc. either. It also doesn't contain any of the introductory text that the "download" page does have currently. In general it isn't an introductory document. Also, much of the info for yum and redhat 7.x will be the same for any redhat version (that is a side issue however). The "Download" page has no links to where you can get apt or yum preconfigured from (for example). I don't mind at all where this page I am referring goes. I am only suggesting it would be good to have one. In that spirit I am suggesting what structure it could have. The idea behind the structure is to give enough info so that, read on its own, one knows which steps are required and that each step is clearly described by following one click. If we can have one page that satisfies that condition I think we would be in much better shape. So how about 1) A documentation page which is introductory in style and contains all the info needed for a non-expert to get started with clearly annotated links for the detailed parts. We could even call it a HOWTO :) The FAQ doesn't help someone trying to get set up either at the moment. 2) A download page that essentially just has links to where to download things from. Cheers, Raphael From mail at jonaspasche.de Wed Feb 4 19:14:41 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Wed, 04 Feb 2004 20:14:41 +0100 Subject: Suggestion for a new Download page Message-ID: <1075922081.3736.277.camel@leonardo> Hi Raphael, > The motivation is to have a page a non-expert can go to and by reading > it and following the links be able to get yum or apt working on their > system. Exactly that's covered by "Using Fedora Legacy with yum on Red Hat 7.x", but... > If there is another page that does the same thing then that is great > but I haven't seen it. ...obviously it isn't obvious enough that this is page you look for. What about renaming it to "Getting started with using Fedora Legacy", or a red-blinking ;-) note saying "Start here"? ;-) > The Documentation page currently has three links and almost nothing else on it. What else did you expect? The first link tells you exactly what you summarized in your last posting: Getting yum, installing yum, importing the Fedora Legacy GPG key, updating your system, staying up to date automatically. > This page is clearly only of use to people who want to do one of those > three things and know what yum and apt are for. Which I read as a strong advise to give these documents better titles. They actually are for people who don't know anything about apt/yum yet and provides step-by-step information to them. > There is no mention of yum with redhat 8.0 etc. either. Right, because yum isn't yet available for 8.0 (and in turn, apt isn't yet available for 7.x), so we don't yet have anything to document. We will add the according documentation as soon as these packages are available. > It also doesn't contain any of the > introductory text that the "download" page does have currently. Right, because the Download page already contains it ;-))) But I'm not sure what exactly you expect. Did you already read the yum introduction for 7.x? Does it fit your needs, or doesn't it? What does it miss? We're open to any suggestions. > In general it isn't an introductory document. Maybe we have a different understanding of the word "introductory", but to me the "yum on 7.x" document seems _very_ introductory as it guides you through every single step that is needed to use Fedora Legacy in a very detailed way. > Also, much of the info for > yum and redhat 7.x will be the same for any redhat version (that is a > side issue however). Partly. For 7.x, the user has to install yum1. For 8.0 and 9 we have the issue that one can choose to install yum1 on the buggy rpm that shipped with 8.0/9, or update rpm and use yum2 because yum1 isn't compatible with the updated rpm package. For FC releases, we can skip parts of the documentation because yum is already included in the official distribution. Regarding apt I expect a single set of instructions match all supported distributions because it has low dependencies. I fear that a document that provides yum information for all distributions will get large and complex because of many "If you have 7.x, do this, but if you have 8.0/9, do that" sections. Splitting it up into different documents makes them easier to the reader; I think we will come up with three docs for yum (7.x, 8.0/9, FC) and one page for apt. > The "Download" page has no links to where you can get apt or yum > preconfigured from (for example). Right, because you should follow the To-be-renamed instructions that can be found in "Using Fedora Legacy with yum on Red Hat 7.x", if you don't yet have yum or apt. Please check my Download page suggestion; see below. From my point of view, the Download page is only for users that (1) already have apt/yum installed and just want to use our repositories, or (2) want to manually download packages by HTTP. > 1) A documentation page which is introductory in style and contains all > the info needed for a non-expert to get started with clearly annotated > links for the detailed parts. We could even call it a HOWTO :) The FAQ > doesn't help someone trying to get set up either at the moment. I have the very strong impression that you actually never read "Using Fedora Legacy with yum on Red Hat 7.x", because it is exactly what you want: Introductory in style, for non-expers, getting started, clearly annotated links, HOWTO-style. Would please check back on this document and give a feedback if it fits your needs, and if not, what can be optimized to do so? Eric, would you mind either changing the title of this document or give it a special marker to better reflect that Joe Average should start reading there? > 2) A download page that essentially just has links to where to download > things from. It has a link to the repository, and it should provide repository configuration examples in the future. As "Installing apt/yum" is not equivalent with "Using Fedora Legacy", I would not simply give links to download yum/apt to prevent users having the impression that installing these RPMs would "make their system use Fedora Legacy", which really isn't the case. I have created an update for the "Download" page that hopefully integrates the results of the ongoing discussion: http://jonaspasche.de/fedoralegacy/download.html Raphael, can you please comment on this? Your input is very valuable; it would be good to know if this page answers your question in a better way than the existing page. Any other list members, please feel free to give feedback as well. Thanks for all your help! Jonas -------------- 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 dick at dickmorrell.com Wed Feb 4 19:23:27 2004 From: dick at dickmorrell.com (Richard Morrell) Date: Wed, 4 Feb 2004 19:23:27 +0000 (GMT) Subject: Suggestion for a new Download page In-Reply-To: <1075922081.3736.277.camel@leonardo> References: <1075922081.3736.277.camel@leonardo> Message-ID: People are making this stuff FAR harder than it needs to be. There is already a tome of guidance online and if you can't figure it frankly you shouldn't be trusted with a terminal - its that basic. Yum isn't hard to figure nor should people using multiple RH OS's have issues between versions. Simply thank the FL crew smile and move on. After 7 yrs admin'ing some of the worlds biggest Linux networks this thread has caused me to bang my head on my desk at least twice today and thats not good on my birthday so lets put this to bed. Dick > > Partly. > > For 7.x, the user has to install yum1. > > For 8.0 and 9 we have the issue that one can choose to install yum1 on > the buggy rpm that shipped with 8.0/9, or update rpm and use yum2 > because yum1 isn't compatible with the updated rpm package. > > For FC releases, we can skip parts of the documentation because yum is > already included in the official distribution. > > Regarding apt I expect a single set of instructions match all supported > distributions because it has low dependencies. > > I fear that a document that provides yum information for all > distributions will get large and complex because of many "If you have > 7.x, do this, but if you have 8.0/9, do that" sections. Splitting it up > into different documents makes them easier to the reader; I think we > will come up with three docs for yum (7.x, 8.0/9, FC) and one page for > apt. > > > The "Download" page has no links to where you can get apt or yum > > preconfigured from (for example). > > Right, because you should follow the To-be-renamed instructions that can > be found in "Using Fedora Legacy with yum on Red Hat 7.x", if you don't > yet have yum or apt. Please check my Download page suggestion; see > below. > > From my point of view, the Download page is only for users that (1) > already have apt/yum installed and just want to use our repositories, or > (2) want to manually download packages by HTTP. > > > 1) A documentation page which is introductory in style and contains all > > the info needed for a non-expert to get started with clearly annotated > > links for the detailed parts. We could even call it a HOWTO :) The FAQ > > doesn't help someone trying to get set up either at the moment. > > I have the very strong impression that you actually never read "Using > Fedora Legacy with yum on Red Hat 7.x", because it is exactly what you > want: Introductory in style, for non-expers, getting started, clearly > annotated links, HOWTO-style. > > Would please check back on this document and give a feedback if it fits > your needs, and if not, what can be optimized to do so? > > Eric, would you mind either changing the title of this document or give > it a special marker to better reflect that Joe Average should start > reading there? > > > 2) A download page that essentially just has links to where to download > > things from. > > It has a link to the repository, and it should provide repository > configuration examples in the future. As "Installing apt/yum" is not > equivalent with "Using Fedora Legacy", I would not simply give links to > download yum/apt to prevent users having the impression that installing > these RPMs would "make their system use Fedora Legacy", which really > isn't the case. > > I have created an update for the "Download" page that hopefully > integrates the results of the ongoing discussion: > > http://jonaspasche.de/fedoralegacy/download.html > > Raphael, can you please comment on this? Your input is very valuable; it > would be good to know if this page answers your question in a better way > than the existing page. Any other list members, please feel free to give > feedback as well. > > Thanks for all your help! > > Jonas > From rostetter at mail.utexas.edu Wed Feb 4 21:15:50 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 4 Feb 2004 15:15:50 -0600 Subject: Suggestion for a new Download page In-Reply-To: References: <1075922081.3736.277.camel@leonardo> Message-ID: <20040204151550.nb3hnokk8gsc4w4k@mail.ph.utexas.edu> Quoting Richard Morrell : > People are making this stuff FAR harder than it needs to be. There is Actually, their just missing the point that this is a "starting phase community-based project" and that if they want better docs they should help right them. A full set of docs doesn't just appear magically at the project startup. It develops over time due to hard work from the community. > versions. Simply thank the FL crew smile and move on. Or help by providing content, patches, QA testing of the packages, etc. > After 7 yrs admin'ing some of the worlds biggest Linux networks this > thread has caused me to bang my head on my desk at least twice today and > thats not good on my birthday so lets put this to bed. Sorry about that (head banging), but Happy Birthday! Best of wishes on your birthday... > Dick -- Eric Rostetter From rostetter at mail.utexas.edu Wed Feb 4 22:43:28 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 4 Feb 2004 16:43:28 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1075922081.3736.277.camel@leonardo> References: <1075922081.3736.277.camel@leonardo> Message-ID: <20040204164328.j4l700owc8csc4k8@mail.ph.utexas.edu> Quoting Jonas Pasche : > Eric, would you mind either changing the title of this document or give > it a special marker to better reflect that Joe Average should start > reading there? Check out the new page. Probably not what you want, but... I've updated the download, mirror, and documentation pages based on the mailing list commnets. I've also updated the participate page to include the "task list" idea. I've also finally set up an easy way to update the web site from cvs so I can update it more frequently than before, without changing the dates on each file (so the "last updated" info on the web page will be correct). > I have created an update for the "Download" page that hopefully > integrates the results of the ongoing discussion: > > http://jonaspasche.de/fedoralegacy/download.html I've not used this yet, but keep it around so I can pull ideas from it... And/or modify it based on the current pages I just posted. > Raphael, can you please comment on this? Your input is very valuable; it > would be good to know if this page answers your question in a better way > than the existing page. Any other list members, please feel free to give > feedback as well. Yes, and on the updated web site also. The comments so far have been most useful, in particular the ones where you don't even think you are helping or contributing... ;) It's amazing what the small comments from those who actually use the yum/apt programs can do for those of us who don't use them... > Thanks for all your help! > > Jonas -- Eric Rostetter From lists at securityspace.com Wed Feb 4 22:55:37 2004 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 04 Feb 2004 17:55:37 -0500 Subject: Suggestion for a new Download page In-Reply-To: References: <1075922081.3736.277.camel@leonardo> Message-ID: <40217869.8070100@securityspace.com> Richard Morrell wrote: > People are making this stuff FAR harder than it needs to be. There is > already a tome of guidance online and if you can't figure it frankly you > shouldn't be trusted with a terminal - its that basic. Yum isn't hard to > figure nor should people using multiple RH OS's have issues between > versions. Simply thank the FL crew smile and move on. Perhaps a perspective from another admin might be in order here. Having administered Linux systems since 1995, built numerous ones from scratch, I have _some_ level of experience here. The FedoraLegacy project is wonderful. It's filling a badly needed hole. And the manner in which it started off has made for a horrid amount of confusion for those of us that were introduced to it in the last couple months. Most of these problems are all a direct result of the start-up nature of the project. But the sentiment that those that can't figure it can't be trusted with a terminal is painting a broad brush and missing two key points: 1) Experienced people WILL have a hard time if they are just being introduced to yum. I certainly had a harder time of it trying to figure out exactly what the software requirements were, how to get RH7/8/9 working, and where to get the friggin RPMS from (in context that 8/9 aren't even available yet in legacy), and just trying to figure out what the difference was between fedora.us and fedoralegacy.org. 2) Your user community consists of MORE than just experienced network admins. It is moving towards a broader, less experienced customer base. I dare say they deserve to keep their system up to date? Eric nailed the point - the project needs improvements and contributions (which I admit here and now I have not provided, although we are looking at the option of providing mirroring services as a way to contribute). But don't be surprised that there are a few growing pains along the way. Perhaps aim the forehead at a wristpad buffer. It'll hurt less than a hard desktop ;-) Jesse, Warren, Eric (and others I'm missing), keep up the good work! Cheers, Thomas From mail at jonaspasche.de Wed Feb 4 23:48:46 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 00:48:46 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040204164328.j4l700owc8csc4k8@mail.ph.utexas.edu> References: <1075922081.3736.277.camel@leonardo> <20040204164328.j4l700owc8csc4k8@mail.ph.utexas.edu> Message-ID: <1075938525.3736.419.camel@leonardo> Hi Eric, > I've updated the download, mirror, and documentation pages based on the > mailing list commnets. Regarding "Download": After Raphael's feedback I'd still suggest to include the "Is this the right place for you?" section of my proposal right on the top of the page. Maybe you are able to find a better title for it. I appreciate that you mention that apt/yum configuration can be found on the mirrors page, but I would give this part a bit more strength, maybe a separate subsection under "Installing packages". I think (and feedback proved) that people are actually looking for these configuration entries, and while appreciating to put them under Mirrors, from the viewpoint of Joe Average I'd look under Download first. There's a broken link where you link to the Mirrors page - it's "/download/mirrors.php", not "/downloads/mirrors.php". Regarding "Documentation": For me it is absolutely enough that you created "Getting started..." and "Getting involved..." sections. Should be enough for now. Good idea! Regarding "Mirrors": The warnings about the "updates" channel repository mixing problem should be placed below the configuration files because they apply to apt as well as to yum. I would chose small caps for YUM and APT. I still vote for copy+paste entries for apt's sources list ;-) (the yum configuration file is just fine). The entries of the mirrors.list file cannot be used through copy+paste; one has to delete the commentary and has to prefix the repository lines with "rpm ". If mirrors become available, what about providing a link to the mirror-select.lua script, telling the users how to include it into their configuration? This can also be put under Documentation, but should be linked from the Mirrors page. I expect the lua script to be included in our own apt packages, or isn't it..? > I've also updated the participate page to include the "task list" idea. Well done! We should make clear the state of the entries that currently have a state of "unknown". Anybody on the list, please help bringing the task list up to date! What about adding the names of the people who volunteered being responsible for a specific task? It might help coordinating work and provides contact persons for any people that might have input on a specific topic. > I've also finally set up an easy way to update the web site from cvs > so I can update it more frequently than before, without changing the dates > on each file (so the "last updated" info on the web page will be correct) From rostetter at mail.utexas.edu Thu Feb 5 04:03:21 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 4 Feb 2004 22:03:21 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1075938525.3736.419.camel@leonardo> References: <1075922081.3736.277.camel@leonardo> <20040204164328.j4l700owc8csc4k8@mail.ph.utexas.edu> <1075938525.3736.419.camel@leonardo> Message-ID: <20040204220321.w6rggswkkws4k0ks@mail.ph.utexas.edu> Quoting Jonas Pasche : > Regarding "Download": > > After Raphael's feedback I'd still suggest to include the "Is this the > right place for you?" section of my proposal right on the top of the > page. Maybe you are able to find a better title for it. Yes, I'll look into this. Didn't have time today to digest your page... > I appreciate that you mention that apt/yum configuration can be found on > the mirrors page, but I would give this part a bit more strength, maybe > a separate subsection under "Installing packages". It is a trade off. If we do that, we remove the encouragement to use our apt/yum packages... I'll see what I can do to make a decent compromise. > There's a broken link where you link to the Mirrors page - it's > "/download/mirrors.php", not "/downloads/mirrors.php". Fixed in cvs > Regarding "Documentation": > > For me it is absolutely enough that you created "Getting started..." and > "Getting involved..." sections. Should be enough for now. Good idea! Okay. We can add more sections as we get more docs... > Regarding "Mirrors": > > The warnings about the "updates" channel repository mixing problem > should be placed below the configuration files because they apply to apt > as well as to yum. Actually, I was told yum would use multiple channels as 'fail-over' channels in the case a server was down, and would use them in the order provided in the config file. Is this not true, or am I missing the point, or what? I do understand we would want ours first if not the only entries for base/os channels, but I'm curious about the working, etc. > I would chose small caps for YUM and APT. Done in cvs. > I still vote for copy+paste entries for apt's sources list ;-) > (the yum configuration file is just fine). The entries of the These are files done by Jesse, so you need to take it up with him. Only way I would go against him would be to add two files (one copy+paste version, and the other Jesse's version). > mirrors.list file cannot be used through copy+paste; one has to delete > the commentary and has to prefix the repository lines with "rpm ". I know nothing about that, as I don't know how to configure apt. So to provide such a thing, I'd need the info (files) provided to me. > If mirrors become available, what about providing a link to the > mirror-select.lua script, telling the users how to include it into their > configuration? I assume this is either in the FL apt packages, or that Jesse will provide it somehow. Jesse will have to clairify that. > linked from the Mirrors page. I expect the lua script to be included in > our own apt packages, or isn't it..? Don't know... > We should make clear the state of the entries that currently have a > state of "unknown". Anybody on the list, please help bringing the task > list up to date! Yes, including adding tasks we forgot about. > What about adding the names of the people who volunteered being > responsible for a specific task? I thought about that, and am willing to do so, as long as the people involved are okay with it. I was thinking maybe just first names for now? (If we hit an duplicate first name, add a last initial or something). -- Eric Rostetter From jkeating at j2solutions.net Thu Feb 5 05:35:19 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 4 Feb 2004 21:35:19 -0800 Subject: Server outage scheduled for tomorrow morning Message-ID: <200402042135.20342.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The server must be taken down again for a few minutes to move racks. The previous outage was to move the power unit, this outage is to move the actual system. Downtime will be between 7:00PST and 8:00PST. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIdYX4v2HLvE71NURAtVKAKCihWn0CL96F9zkFtpbgfni0Rm7LgCgtzz9 cKvf61xEKq9ceKtQigyUGvg= =Rylx -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 5 06:21:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 4 Feb 2004 22:21:58 -0800 Subject: Fedora Legacy Test Update Notification: slocate Message-ID: <200402042221.59242.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1230 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1232 2004-02-04 - --------------------------------------------------------------------- Name : slocate Version 7.2 : 2.7-1.7.2 Version 7.3 : 2.7-1.7.3 Version 8.0 : 2.7-1.8.0 Summary : Finds files on a system via a central database. Description : Slocate is a security-enhanced version of locate. Just like locate, slocate searches through a central database (which is updated nightly) for files that match a given pattern. Slocate allows you to quickly find files anywhere on your system. - --------------------------------------------------------------------- Update Information: CAN-2003-0848: Heap-based buffer overflow in main.c of slocate 2.6, and possibly other versions, may allow local users to gain privileges via a modified slocate database that causes a negative "pathlen" value to be used. - --------------------------------------------------------------------- Changelog: * Wed Feb 04 2004 Jesse Keating - - 2.x.x.legacy - - fixed package version, pushing to updates. - - fixed URL * Thu Jan 22 2004 Michael Schwendt - - Fix automake regeneration (adds buildreq autoconf,automake). - - Clear buildroot at beginning of %install. - - Copyright->License, Prereq->Requires(pre,preun). * Wed Jan 21 2004 Mark Cox - - drop privs for non slocate gid databases (CAN-2003-0848) - - update to 2.7 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates-testing/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates-testing/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates-testing/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates-testing/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates-testing/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates-testing/i386/slocate-2.7-1.8.0.legacy.i386.rpm - --------------------------------------------------------------------- Notes: This is an upgrade rather than a backport. Many bugfixes between 2.6 and 2.7, very very little changes externally. RHEL 2.1 also updated rather than backported. Tests well. Please test and comment in bugzilla. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIeEG4v2HLvE71NURAnsGAJ9repVII+pukj652Bk2VRpIjWs0cwCgpaCh WvaN6N9pDYMXYGOihr3NVHk= =nghA -----END PGP SIGNATURE----- From mail at jonaspasche.de Thu Feb 5 14:01:37 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 15:01:37 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040204220321.w6rggswkkws4k0ks@mail.ph.utexas.edu> References: <1075922081.3736.277.camel@leonardo> <20040204164328.j4l700owc8csc4k8@mail.ph.utexas.edu> <1075938525.3736.419.camel@leonardo> <20040204220321.w6rggswkkws4k0ks@mail.ph.utexas.edu> Message-ID: <1075989697.3582.65.camel@leonardo> Hi Eric, > It is a trade off. If we do that, we remove the encouragement to use our > apt/yum packages... Good point! > Actually, I was told yum would use multiple channels as 'fail-over' channels > in the case a server was down, and would use them in the order provided > in the config file. Is this not true, or am I missing the point, or what? Not exactly true: One can give yum more than one baseurl for a specific channel, which means that one channel cannot failover to another channel, but one channel has different sources where packages of this channel can be retrieved. Normally all these sources contain an equivalent package set. apt downloads package lists from any given repository first. Having the same channel mentioned on more than one repository means that its package list will be downloaded more than once. In cases of big channels like "os", this will take a considerable amount of time; that's why I suggested the removal of duplicate channels in apt's sources.list, at least for "os" which is by far the biggest. For yum, this shouldn't be a problem, because it would only touch the second source for the "base" channel if the first isn't available. However, I see a problem in that channels are not necessarily equivalent. "updates" on freshrpms only provides Red Hat updates; "updates" on Fedora Legacy provides Red Hat updates plus legacy updates. With apt, this shouldn't be a big problem, because apt downloads any package list and then selects the most recent version of a package, which will automatically select legacy packages over Red Hat updates. The only tradeoff, again, is that package lists for equivalent channels have to be downloaded more than once. With yum, the user has to make sure that he lists our update channel _before_ any other update channel that possibly doesn't contain legacy updates. Say you have repository X that provides Red Hat updates (but no legacy updates), and it is listed before ours. yum will download the package list from there and simply wouldn't know that there are even more updates because it doesn't touch the second repository (which might point to download.fedoralegacy.org) until the first _fails_. That's why I suggested to keep only one updates channel. After thinking about this, I see that my annotations are not necessarily equivalent for both apt and yum. I'll see if I can make a better proposal for them, because it think it's important. > I do understand we would want ours first if not the only entries for base/os > channels, but I'm curious about the working, etc. I fear I don't understand what you mean with that. > I know nothing about that, as I don't know how to configure apt. So to > provide such a thing, I'd need the info (files) provided to me. I have posted apt configuration a few days ago. Here again: Red Hat Linux 7.2: rpm http://download.fedoralegacy.org/apt redhat/7.2/i386 os updates legacy-utils Red Hat Linux 7.3: rpm http://download.fedoralegacy.org/apt redhat/7.3/i386 os updates legacy-utils Red Hat Linux 8.0: rpm http://download.fedoralegacy.org/apt redhat/8.0/i386 os updates legacy-utils This is copy+paste information to put into /etc/apt/sources.list. It's a one-liner per distribution release, in contrast to the mirrors.list file that (1) has this one line splitted into three different lines, (2) has mirrors.list-specific additions that cannot be put into the sources.list file and (3) doesn't have a prefix of "rpm " which is needed in the sources.list file, but not in the mirrors.list file (mirror-select.lua would generate sources.list configuration out of the mirrors.list file, but they don't share the same file format). > I thought about that, and am willing to do so, as long as the people involved > are okay with it. I was thinking maybe just first names for now? (If we > hit an duplicate first name, add a last initial or something). Would be okay for me. Jonas -------------- 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 heinlein at cse.ogi.edu Thu Feb 5 16:57:45 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Thu, 5 Feb 2004 08:57:45 -0800 (PST) Subject: util-linux advisory Message-ID: I noticed a new security advisory for Red Hat Enterprise 2.x: https://rhn.redhat.com/errata/RHSA-2004-056.html I poked around the changelog and noted what Bill Nottingham had patched. It appears that Red Hat 8.0 is *not* vulnerable to this info leak. I don't have any more 7.x boxen, but it might be worthwhile for someone to poke at the util-linux packages for the 7.x releases to see if any work needs to be done on them. -- Paul Heinlein From jkeating at j2solutions.net Thu Feb 5 17:14:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 09:14:33 -0800 Subject: util-linux advisory In-Reply-To: References: Message-ID: <200402050914.33092.jkeating@j2solutions.net> On Thursday 05 February 2004 08:57, Paul Heinlein wrote: > I noticed a new security advisory for Red Hat Enterprise 2.x: > > https://rhn.redhat.com/errata/RHSA-2004-056.html > > I poked around the changelog and noted what Bill Nottingham had > patched. It appears that Red Hat 8.0 is *not* vulnerable to this info > leak. I don't have any more 7.x boxen, but it might be worthwhile for > someone to poke at the util-linux packages for the 7.x releases to > see if any work needs to be done on them. Hi Paul. This flaw is only a flaw in RHL 7.2, and there is currently a util-linux package in testing phase. A package exists right now in a testing phase that needs one more vote of PUBLISH before I can push it to updates-testing. https://bugzilla.fedora.us/show_bug.cgi?id=1256 -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 ms-nospam-0306 at arcor.de Thu Feb 5 17:52:25 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 5 Feb 2004 18:52:25 +0100 Subject: util-linux advisory In-Reply-To: References: Message-ID: <20040205185225.47137ea9.ms-nospam-0306@arcor.de> On Thu, 5 Feb 2004 08:57:45 -0800 (PST), Paul Heinlein wrote: > I noticed a new security advisory for Red Hat Enterprise 2.x: > > https://rhn.redhat.com/errata/RHSA-2004-056.html > > I poked around the changelog and noted what Bill Nottingham had > patched. It appears that Red Hat 8.0 is *not* vulnerable to this info > leak. I don't have any more 7.x boxen, but it might be worthwhile for > someone to poke at the util-linux packages for the 7.x releases to see > if any work needs to be done on them. => http://www.fedora.us/LEGACY -- From raphael at clifford.net Thu Feb 5 18:02:39 2004 From: raphael at clifford.net (Raphael Clifford) Date: Thu, 05 Feb 2004 18:02:39 +0000 Subject: Suggestion for a new Download page Message-ID: <4022853F.9080003@clifford.net> i, I should say straight off that there may be something fundamental about yum that I don't understand. I am getting the impression that you need a special version of yum to use fedora-legacy and not just the correct yum.conf with any old version of yum. Is this right? I am using yum on many different redhat machines, some with fedora-legacy and have never knowingly got a special version but notwithstanding that piece of ignorance here are my comments FWIW. " Which I read as a strong advise to give these documents better titles. They actually are for people who don't know anything about apt/yum yet and provides step-by-step information to them. " yes " Right, because yum isn't yet available for 8.0 (and in turn, apt isn't yet available for 7.x), so we don't yet have anything to document. We will add the according documentation as soon as these packages are available. " I'm a little confused by that. I am using yum on redhat 8.0 with fedora-legacy. I first updated rpm to the less broken version on rpm.org. Do you mean there isn't a downloadable yum rpm with yum.conf preconfigured for fedora legacy? There can be documentation for how to use redhat 8.0 with fedora-legacy can't there? a) upgrade rpm b) download yum from the yum home page (or get one with yum.conf for FL already configured for you) c) (if needed) update yum.conf for FL . I would strongly suggest that any new docs tell people to upgrade rpm to a less broken version as the version that comes with redhat 8.0 (at least) is truely awful. " Right, because the Download page already contains it ;-))) But I'm not sure what exactly you expect. Did you already read the yum introduction for 7.x? Does it fit your needs, or doesn't it? What does it miss? We're open to any suggestions. " It is the organisation of the information that I am keen to see rationalised rather than the overall content of all the pages combined. For me, documentation should contain all documentation or links to all the documentation. It should also be readable by someone who doesn't know what fedora-legacy, yum or apt are. I have read the 7.x page and it is very good. Any redhat 7.x user who finds that page and has a basic idea what fedora-legacy and yum are will be happy. " from my point of view, the Download page is only for users that (1) already have apt/yum installed and just want to use our repositories, or... " I think this is first thing I actually disagree with. The download section should surely help you download whatever you need to download. For most people that will be yum/apt preconfigured. A simple line to the effect that "If you are just starting then please go here to get everything preconfigured" would do of course on the download page if you felt that was more appropriate but there should still be links to show where to download yum and apt from as well IMHO. --- Comments on http://jonaspasche.de/fedoralegacy/download.html Overall it is very good looking. -- Comments on the download page I still feel that the basic documentation should be in the documentation section (this doesn't mean anything has to be removed from the download page). It is counter intuitive to have to follow a link via "Download" to find the introductory docs on yum/apt. The Documentation page could be renamed HOWTOs I suppose if we wanted to be all standard about things I suggest for the documentation page the following (the titles are just suggestive ) a) What is fedora-legacy? b) What are these yum and apt things? c) How do I get started? (redhat 7.x, redhat 8.0, redhat 9 instructions) d) What else is there to know? e) How do I participate? --- Comments on http://www.fedoralegacy.org/download/mirrors.php It starts " Mirrors Currently there are no mirror sites available. When mirror sites are available, they will be listed here. " and then appears to go on to list some mirror sites (actually files but would anyone know why the difference is important?). Cheers, Raphael P.S. http://www.fedoralegacy.org/downloads/mirrors.php should be http://www.fedoralegacy.org/download/mirrors.php From jkeating at j2solutions.net Thu Feb 5 18:12:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 10:12:31 -0800 Subject: Suggestion for a new Download page In-Reply-To: <4022853F.9080003@clifford.net> References: <4022853F.9080003@clifford.net> Message-ID: <200402051012.36279.jkeating@j2solutions.net> On Thursday 05 February 2004 10:02, Raphael Clifford wrote: > I should say straight off that there may be something fundamental > about yum that I don't understand. I am getting the impression that > you need a special version of yum to use fedora-legacy and not just > the correct yum.conf with any old version of yum. Is this right? I > am using yum on many different redhat machines, some with > fedora-legacy and have never knowingly got a special version but > notwithstanding that piece of ignorance here are my comments FWIW. No, you do not need a special version of yum for Legacy. All you need is the correct information in your config file. That said, RHL8 is a special case. There may possibly bet two yum and two apt options for RHL8. One for each rpm version. There are many folks (myself included) that are unwilling to install the rpm upgrade as the problems of RPM are not apparent when using yum1 for all your packaging needs. > > I'm a little confused by that. I am using yum on redhat 8.0 with > fedora-legacy. I first updated rpm to the less broken version on > rpm.org. Do you mean there isn't a downloadable yum rpm with > yum.conf preconfigured for fedora legacy? Yes, that is what he means. > There can be documentation > for how to use redhat 8.0 with fedora-legacy can't there? a) upgrade > rpm b) download yum from the yum home page (or get one with yum.conf > for FL already configured for you) c) (if needed) update yum.conf for > FL . I would strongly suggest that any new docs tell people to > upgrade rpm to a less broken version as the version that comes with > redhat 8.0 (at least) is truely awful. Again, these bugs in rpm are not triggered by yum use, only by rpm direct use and apt use. Therefor there are many folk who will not upgrade rpm, and we need to provide tool sets and instructions to handle both camps. If it were up to me, we'd drop 8.0 from legacy all together, as it was a complete crap platform, but community wishes dictate otherwise. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pmatilai at welho.com Thu Feb 5 18:24:46 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 05 Feb 2004 20:24:46 +0200 Subject: Suggestion for a new Download page In-Reply-To: <200402051012.36279.jkeating@j2solutions.net> References: <4022853F.9080003@clifford.net> <200402051012.36279.jkeating@j2solutions.net> Message-ID: <1076005485.4877.29.camel@chip.laiskiainen.org> On Thu, 2004-02-05 at 20:12, Jesse Keating wrote: > On Thursday 05 February 2004 10:02, Raphael Clifford wrote: > > There can be documentation > > for how to use redhat 8.0 with fedora-legacy can't there? a) upgrade > > rpm b) download yum from the yum home page (or get one with yum.conf > > for FL already configured for you) c) (if needed) update yum.conf for > > FL . I would strongly suggest that any new docs tell people to > > upgrade rpm to a less broken version as the version that comes with > > redhat 8.0 (at least) is truely awful. > > Again, these bugs in rpm are not triggered by yum use, only by rpm > direct use and apt use. Therefor there are many folk who will not > upgrade rpm, and we need to provide tool sets and instructions to > handle both camps. If it were up to me, we'd drop 8.0 from legacy all > together, as it was a complete crap platform, but community wishes > dictate otherwise. Hmm, actually you *could* build apt against rpmlib404 on RHL 8.0 and avoid the rpm-hanging-itself issue with apt as well without upgrading rpm itself. That'd mean having separate builds of apt for both old and new lib for those who want to upgrade rpm :-/ - Panu - From mail at jonaspasche.de Thu Feb 5 18:58:16 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 19:58:16 +0100 Subject: Suggestion for a new Download page In-Reply-To: <4022853F.9080003@clifford.net> References: <4022853F.9080003@clifford.net> Message-ID: <1076007496.3582.188.camel@leonardo> Hi Raphael, > I should say straight off that there may be something fundamental about > yum that I don't understand. I am getting the impression that you need > a special version of yum to use fedora-legacy and not just the correct > yum.conf with any old version of yum. Is this right? No, that's not correct. yum repositories are always the same, independent of the yum version of the client. Fedora Legacy provides a yum repository that can be used by both yum1 and yum2. You don't need a special version of yum to use Fedora Legacy, but we want to encourage people to use our packages, mainly because (1) they are preconfigured and thus easier to use and (2) they have GPG checks enabled and thus more secure. > I'm a little confused by that. I am using yum on redhat 8.0 with > fedora-legacy. No problem, yum is available from its original source for every Red Hat distribution. It's simply not available from _us_ in a preconfigured state for every supported distribution. However, there is absolutely no problem to install yum directly from linux.duke.edu and configure it to use our repositories, which is what you did, judging from your description. > Do you mean there isn't a downloadable yum rpm with yum.conf > preconfigured for fedora legacy? There is only a preconfigured yum for 7.x, but not for 8.0. There is no preconfigured apt yet, neither for 7.x nor for 8.0. The word "preconfigured" is the key here - for sure there _are_ working yum and apt packages that can be manually configured to use our repos. > There can be documentation for how to > use redhat 8.0 with fedora-legacy can't there? There could be such documentation, however, it would point people to different locations for yum/apt downloads and then tell them how to configure our repos. As at least an apt package for 8.0 is available through bugzilla waiting for QA, we should focus on publishing it instead of creating documentation for workarounds. > a) upgrade rpm b) > download yum from the yum home page (or get one with yum.conf for FL > already configured for you) c) (if needed) update yum.conf for FL . I > would strongly suggest that any new docs tell people to upgrade rpm to a > less broken version as the version that comes with redhat 8.0 (at least) > is truely awful. There's an ongoing discussion on this issue; please check the list archives. This is no easy decision, and every solution has tradeoffs. > Any redhat 7.x user who finds that page and has a basic > idea what fedora-legacy and yum are will be happy. Can you check back on the site after Eric has made updates? What do you think about is suggestion to put the docs for using yum on 7.x under a "Getting started..." section - would that help you to find the right information? Do you have a better suggestion? I see a small problems for unexperienced users when they find documentation for yum _and_ apt for their distribution because they don't know either of it and thus cannot simply make a decision which one they want to use. On the other hand, we cannot simply focus on one of these tools and declare the other one as unsupported, because both tools have strong user communities. I'm thinking about a sentence like "If you don't know anything about these tools, we suggest you to try yum first, as it comes with fewer options and fewer complexity than apt. You can always choose between both tools, even later, if you want to try apt instead." > > from my point of view, the Download page is only for users that (1) > > already have apt/yum installed and just want to use our repositories, or... > > I think this is first thing I actually disagree with. The download > section should surely help you download whatever you need to download. > For most people that will be yum/apt preconfigured. A simple line to > the effect that "If you are just starting then please go here to get > everything preconfigured" would do of course on the download page if you > felt that was more appropriate but there should still be links to show > where to download yum and apt from as well IMHO. Okay, I don't have a problem to have link to yum or apt on the Download page, as long as there is a strong note that installing yum or apt alone _does not provide any updates_. It only installs a package manager, nothing else, just like paying for a gym membership doesn't make your body slim. :) > I suggest for the documentation page the following (the titles are just > suggestive ) > > a) What is fedora-legacy? > b) What are these yum and apt things? > c) How do I get started? > (redhat 7.x, redhat 8.0, redhat 9 instructions) > d) What else is there to know? > e) How do I participate? Thanks; I'll note these title for further updates to the documentation page. Anyway, at least questions a) and b) could be answered by a single paragraph in the FAQ, which is - from my point of view - the place where short answers should go. > and then appears to go on to list some mirror sites (actually files but > would anyone know why the difference is important?). I'm not sure on this. My suggestion is to wait until mirrors are really available and then talk about the Mirrors page again. Jonas -------------- 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 rostetter at mail.utexas.edu Thu Feb 5 19:05:02 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 13:05:02 -0600 Subject: Suggestion for a new Download page In-Reply-To: <4022853F.9080003@clifford.net> References: <4022853F.9080003@clifford.net> Message-ID: <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> Quoting Raphael Clifford : > I should say straight off that there may be something fundamental about > yum that I don't understand. I am getting the impression that you need > a special version of yum to use fedora-legacy and not just the correct > yum.conf with any old version of yum. Is this right? No, it should work with any functioning yum, as long as yum.conf is set correctly. > Which I read as a strong advise to give these documents better titles. > They actually are for people who don't know anything about apt/yum yet > and provides step-by-step information to them. Probably true... No one has suggested a better title yet that I've liked. Maybe something like "Installing and using yum for Fedora Legacy with Red Hat Linux 7.2" but that gets kind of long, no? > rpm.org. Do you mean there isn't a downloadable yum rpm with yum.conf > preconfigured for fedora legacy? There can be documentation for how to Yes, and hence he can't write complete docs (such as the url to download from, etc) without the program existing within FL. > would strongly suggest that any new docs tell people to upgrade rpm to a > less broken version as the version that comes with redhat 8.0 (at least) > is truely awful. We already document that as a suggestion for RH 8/9 (but not RH 7.x). > I think this is first thing I actually disagree with. The download > section should surely help you download whatever you need to download. It does have links to the FL repository on it. > For most people that will be yum/apt preconfigured. A simple line to For that it points them to the documentation page. > the effect that "If you are just starting then please go here to get > everything preconfigured" would do of course on the download page if you One has been proposed, but I've not had time yet to do anything with it. > felt that was more appropriate but there should still be links to show > where to download yum and apt from as well IMHO. But I'd have to link to each version and constantly update it as we add/drop versions. No fun. There is no single link to all of them, so this would be a pain. Instead, they can either use the FL repository link, or the documentation link. Until someone comes up with a better solution. By better solution, I mean actual description of how to easily do it and easily maintain it, not just saying "there should be links to them here..." -- Eric Rostetter From rostetter at mail.utexas.edu Thu Feb 5 19:20:34 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 13:20:34 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1076007496.3582.188.camel@leonardo> References: <4022853F.9080003@clifford.net> <1076007496.3582.188.camel@leonardo> Message-ID: <20040205132034.joxa8sc8koc4wc0c@mail.ph.utexas.edu> Quoting Jonas Pasche : > I see a small problems for unexperienced users when they find > documentation for yum _and_ apt for their distribution because they > don't know either of it and thus cannot simply make a decision which one > they want to use. This should spawn one or two faq entries. First was are yum and apt. Second, which should I use if I'm not already using either one? Anyone want to write up those FAQ entries, or even a short doc covering those topics? > user communities. I'm thinking about a sentence like "If you don't know > anything about these tools, we suggest you to try yum first, as it comes > with fewer options and fewer complexity than apt. You can always choose > between both tools, even later, if you want to try apt instead." That's kind of what the proposed FAQ entry would say, more or less... > Okay, I don't have a problem to have link to yum or apt on the Download > page, as long as there is a strong note that installing yum or apt alone > _does not provide any updates_. It only installs a package manager, > nothing else, just like paying for a gym membership doesn't make your > body slim. :) Due to the need to link to a version of yum/apt for each OS version, this would have to be a link on the download page to a separate page which listed them all, and had the above disclaimer. Otherwise the download page would be too long, etc. Anyone agree with that? > > a) What is fedora-legacy? With what, other than a link to the "About" page? > > b) What are these yum and apt things? Okay, someone write it up and I'll put it out there. > > c) How do I get started? > > (redhat 7.x, redhat 8.0, redhat 9 instructions) Great. As someone writes up those docs, I'll put them out there. > > d) What else is there to know? What else *is* there to know? > > e) How do I participate? Already there. > Thanks; I'll note these title for further updates to the documentation > page. Anyway, at least questions a) and b) could be answered by a single > paragraph in the FAQ, which is - from my point of view - the place where > short answers should go. Short answers yes. But we've already covered a) in the About page. b) could be covered here, but it should also be covered in the FAQ. To cover it in the docs page, we'd need a longer, more general answer than the FAQ. > Jonas I really do get some good ideas out of these discussions, believe it or not. So thanks. But it would be even better if people wrote these docs they'd like to see and submitted them. I'll try to do it if no one else does; I know I can write them, it is just a matter of finding them time. -- Eric Rostetter From rostetter at mail.utexas.edu Thu Feb 5 19:41:38 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 13:41:38 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1076007496.3582.188.camel@leonardo> References: <4022853F.9080003@clifford.net> <1076007496.3582.188.camel@leonardo> Message-ID: <20040205134138.ihw9w8wg4cg0cskk@mail.ph.utexas.edu> Quoting Jonas Pasche : > Can you check back on the site after Eric has made updates? What do you More updates done (to docs and faq) on the web site. > I see a small problems for unexperienced users when they find > documentation for yum _and_ apt for their distribution because they > don't know either of it and thus cannot simply make a decision which one > they want to use. Added an faq for this based on your text below. > user communities. I'm thinking about a sentence like "If you don't know > anything about these tools, we suggest you to try yum first, as it comes > with fewer options and fewer complexity than apt. You can always choose > between both tools, even later, if you want to try apt instead." Used that as the basis of the faq. > Okay, I don't have a problem to have link to yum or apt on the Download > page, as long as there is a strong note that installing yum or apt alone > _does not provide any updates_. It only installs a package manager, > nothing else, just like paying for a gym membership doesn't make your > body slim. :) Someone else will need to work on that page, or it will have to wait. > > a) What is fedora-legacy? Added, though all it does is provide links which are already available in the menu bar at the left. > > b) What are these yum and apt things? > > c) How do I get started? I think those two should be combined. If someone writes up a good "what are these yum and apt things" I'll put it in the "Getting started..." section. > > d) What else is there to know? Beats me. No idea what would go here. > > e) How do I participate? Already there. -- Eric Rostetter From Freedom_Lover at pobox.com Thu Feb 5 20:00:13 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 5 Feb 2004 15:00:13 -0500 Subject: Suggestion for a new Download page In-Reply-To: <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> Message-ID: <20040205200013.GY3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rostetter wrote: > Quoting Raphael Clifford : >> Which I read as a strong advise to give these documents better >> titles. They actually are for people who don't know anything about >> apt/yum yet and provides step-by-step information to them. > > Probably true... No one has suggested a better title yet that I've > liked. Maybe something like "Installing and using yum for Fedora > Legacy with Red Hat Linux 7.2" but that gets kind of long, no? Sorry to only respond to one small part of this thread, I know there's a lot of other things being discussed here. But just to point out that since yum configs are version independent, it's not necessary to say "Installing and using yum for Fedora Legacy with Red Hat Linux 7.2." You can simply say "Installing and using yum for Fedora Legacy," can't you? If a potential user can't or won't do a little thinking on their own and pick the proper version for their RH system, how much more hand holding can a few volunteers here do? The instructions on that page would tell you to grab yum for your RH version from download.fedoralegacy.org and then how to issue the commands to make it automatically update. I suppose that technically, if someone wanted to, a shell script could be written that would go out and grab the latest yum and configure it for the user, sort of like what Ximian used to do (and still does, now that I look) with their gnome releases. See an example here: http://www.ximian.com/products/desktop/download.html It seems to me that most -- if not all -- of the required info is already on the site thanks to Eric and Jonas (and all those who contributed ideas or other documentation). But maybe I've not been following this thread closely enough to understand exactly what changes are being suggested. If so, sorry for the interruption, I'll go back to lurking and *trying* to make some time to do QA on those apt packages... - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Tell a man there are 300 billion stars in the universe, he'll believe you. Tell him a bench has wet paint on it and he'll have to touch it to be sure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIqDNuv+09NZUB1oRAnnnAJ9TuC6hSqwL2zbmJILYN20gilUYJQCfchCQ 5uia88NRFBaKTdW5ZG8Kh1Q= =ni4Z -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Thu Feb 5 20:19:48 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 14:19:48 -0600 Subject: Suggestion for a new Download page In-Reply-To: <20040205200013.GY3731@psilocybe.teonanacatl.org> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> Message-ID: <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> Quoting Todd : > Sorry to only respond to one small part of this thread, I know there's > a lot of other things being discussed here. But just to point out > that since yum configs are version independent, it's not necessary to > say "Installing and using yum for Fedora Legacy with Red Hat Linux > 7.2." You can simply say "Installing and using yum for Fedora > Legacy," can't you? Yum configs are not independent (yum1 versus yum2) and the install directions are different for different OS versions. So, no. > If a potential user can't or won't do a little thinking on their own > and pick the proper version for their RH system, how much more hand > holding can a few volunteers here do? As much as is needed. > The instructions on that page would tell you to grab yum for your RH > version from download.fedoralegacy.org and then how to issue the > commands to make it automatically update. You've left out some steps. > I suppose that technically, if someone wanted to, a shell script could > be written that would go out and grab the latest yum and configure it > for the user, sort of like what Ximian used to do (and still does, now > that I look) with their gnome releases. See an example here: > > http://www.ximian.com/products/desktop/download.html We can't even get the apt package QA tested, so there is little hope at this stage we can get a custom installer written, tested, and documented. > It seems to me that most -- if not all -- of the required info is > already on the site thanks to Eric and Jonas (and all those who > contributed ideas or other documentation). But maybe I've not been > following this thread closely enough to understand exactly what > changes are being suggested. Mostly it is about organization, but there has been some missing content from time to time (like FAQ entries). > If so, sorry for the interruption, I'll > go back to lurking and *trying* to make some time to do QA on those > apt packages... Yes, please try to find some time for those QA duties ;) We really need to get more people doing QA testing. -- Eric Rostetter From swsnyder at insightbb.com Thu Feb 5 18:27:20 2004 From: swsnyder at insightbb.com (Steve Snyder) Date: Thu, 5 Feb 2004 13:27:20 -0500 Subject: A request: update to current OpenSSH Message-ID: <200402051327.20265.swsnyder@insightbb.com> I would like to make a request: please provides updates to the OpenSSH packages. The current version of OpenSSH for RH v7.3 is 3.1p1-14 while the current version of OpenSSH itself is 3.7.1p2-1. Given how critical OpenSSH is for system security, can we please get a packaging of the contemporary version of this software? (Yes, I am aware that I can build my own RPMs. I'd prefer, though, to stay in sync with the Legacy packaging.) Thanks. From jkeating at j2solutions.net Thu Feb 5 20:22:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 12:22:32 -0800 Subject: Suggestion for a new Download page In-Reply-To: <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> Message-ID: <200402051222.37185.jkeating@j2solutions.net> On Thursday 05 February 2004 12:19, Eric Rostetter wrote: > Yum configs are not independent (yum1 versus yum2) and the install > directions are different for different OS versions. So, no. Only the basic stuff is non-independent. The repo listings are, with the use of $releasever and $basearch -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Feb 5 20:25:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 12:25:06 -0800 Subject: A request: update to current OpenSSH In-Reply-To: <200402051327.20265.swsnyder@insightbb.com> References: <200402051327.20265.swsnyder@insightbb.com> Message-ID: <200402051225.06369.jkeating@j2solutions.net> On Thursday 05 February 2004 10:27, Steve Snyder wrote: > I would like to make a request: please provides updates to the > OpenSSH packages. > > The current version of OpenSSH for RH v7.3 is 3.1p1-14 while the > current version of OpenSSH itself is 3.7.1p2-1. > > Given how critical OpenSSH is for system security, can we please get > a packaging of the contemporary version of this software? > > (Yes, I am aware that I can build my own RPMs. I'd prefer, though, > to stay in sync with the Legacy packaging.) We don't upgrade packages just to upgrade them. Newer != better. As flaws are found in the OpenSSH that is in use right now, we'll patch the packages. If you'd like to build new packages, feel free to point folks to your packages, but they will not be Legacy supported. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 rohwedde at codegrinder.com Thu Feb 5 20:28:06 2004 From: rohwedde at codegrinder.com (Jason) Date: Thu, 5 Feb 2004 14:28:06 -0600 Subject: Suggestion for a new Download page In-Reply-To: <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> Message-ID: <20040205202806.GM2704@codegrinder.com> On Thu, Feb 05, 2004 at 02:19:48PM -0600, Eric Rostetter wrote: > Quoting Todd : > > > I suppose that technically, if someone wanted to, a shell script could > > be written that would go out and grab the latest yum and configure it > > for the user, sort of like what Ximian used to do (and still does, now > > that I look) with their gnome releases. See an example here: > > > > http://www.ximian.com/products/desktop/download.html > > We can't even get the apt package QA tested, so there is little hope at > this stage we can get a custom installer written, tested, and documented. > The apt package is set up to configure itself upon the first invocation based on the mirror list on the fedoralegacy server. I'll write the docs if need be, but I can't QA the package I built.. well, I could.. but my publish vote wouldn't really count ;) > > If so, sorry for the interruption, I'll > > go back to lurking and *trying* to make some time to do QA on those > > apt packages... > > Yes, please try to find some time for those QA duties ;) We really > need to get more people doing QA testing. What he said. -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Thu Feb 5 20:39:46 2004 From: warren at togami.com (Warren Togami) Date: Thu, 05 Feb 2004 10:39:46 -1000 Subject: A request: update to current OpenSSH In-Reply-To: <200402051225.06369.jkeating@j2solutions.net> References: <200402051327.20265.swsnyder@insightbb.com> <200402051225.06369.jkeating@j2solutions.net> Message-ID: <4022AA12.20501@togami.com> Jesse Keating wrote: > On Thursday 05 February 2004 10:27, Steve Snyder wrote: > >>I would like to make a request: please provides updates to the >>OpenSSH packages. >> >>The current version of OpenSSH for RH v7.3 is 3.1p1-14 while the >>current version of OpenSSH itself is 3.7.1p2-1. >> >>Given how critical OpenSSH is for system security, can we please get >>a packaging of the contemporary version of this software? >> >>(Yes, I am aware that I can build my own RPMs. I'd prefer, though, >>to stay in sync with the Legacy packaging.) > > > We don't upgrade packages just to upgrade them. Newer != better. As > flaws are found in the OpenSSH that is in use right now, we'll patch > the packages. > > If you'd like to build new packages, feel free to point folks to your > packages, but they will not be Legacy supported. > Also be aware that RH avoided one of the recent potential opensshd remote vulnerabilities by NOT upgrading to a newer openssh, but patching an older version. The old version in default RH configuration was not vulnerable to one particular issue. This is another reason why newer version is not always better. In the case of older distributions, sometimes "better tested over time" is often better. Legacy should only upgrade versions if very specific criteria that we defined on this mailing list (are these copied to the web page?) are met, mainly in cases where upgrading would allow syncing versions of multiple similar distributions and testing indicates that there are seemingly no regressions. Upgrading is the exception and not the rule. Warren From rostetter at mail.utexas.edu Thu Feb 5 20:54:20 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 14:54:20 -0600 Subject: A request: update to current OpenSSH In-Reply-To: <4022AA12.20501@togami.com> References: <200402051327.20265.swsnyder@insightbb.com> <200402051225.06369.jkeating@j2solutions.net> <4022AA12.20501@togami.com> Message-ID: <20040205145420.7b400kw0gkg0kkow@mail.ph.utexas.edu> Quoting Warren Togami : > Legacy should only upgrade versions if very specific criteria that we > defined on this mailing list (are these copied to the web page?) are Not, though there is vague mention about them. I've not had time to finish my QA/Policy page yet, nor track down all the threads that happened on the mailing list before the web page was started. -- Eric Rostetter From notting at redhat.com Thu Feb 5 21:28:11 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Feb 2004 16:28:11 -0500 Subject: util-linux advisory In-Reply-To: References: Message-ID: <20040205212811.GE28485@devserv.devel.redhat.com> Paul Heinlein (heinlein at cse.ogi.edu) said: > I noticed a new security advisory for Red Hat Enterprise 2.x: > > https://rhn.redhat.com/errata/RHSA-2004-056.html > > I poked around the changelog and noted what Bill Nottingham had > patched. It appears that Red Hat 8.0 is *not* vulnerable to this info > leak. I don't have any more 7.x boxen, but it might be worthwhile for > someone to poke at the util-linux packages for the 7.x releases to see > if any work needs to be done on them. 7.1 (with errata) and 7.2 are vulnerable. Anything later is not. Bill From Freedom_Lover at pobox.com Thu Feb 5 21:50:03 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 5 Feb 2004 16:50:03 -0500 Subject: Suggestion for a new Download page In-Reply-To: <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> Message-ID: <20040205215003.GA3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rostetter wrote: > Quoting Todd : > >> Sorry to only respond to one small part of this thread, I know >> there's a lot of other things being discussed here. But just to >> point out that since yum configs are version independent, it's not >> necessary to say "Installing and using yum for Fedora Legacy with >> Red Hat Linux 7.2." You can simply say "Installing and using yum >> for Fedora Legacy," can't you? > > Yum configs are not independent (yum1 versus yum2) and the install > directions are different for different OS versions. So, no. Well, until it's determined that FL will be shipping yum2 for RH 8.0 (or until RH 9 goes EOL), I'm working on the assumption that only yum1 needs to be documented. What's the difference in the install instructions? You run rpm, import the keys to your gpg keyring, and optionally enable the yum service. >> If a potential user can't or won't do a little thinking on their >> own and pick the proper version for their RH system, how much more >> hand holding can a few volunteers here do? > > As much as is needed. That's going to be an awful lot of text. There's a point at which the extra documentation that's there to help the completely clueless will bog down those who are just trying to get up and running fast. I don't know exactly where that point is, but it's something to keep in mind. A quick start page and a more in depth instruction page might be quite useful once everything is all documented. That would keep as many people happy as possible. >> The instructions on that page would tell you to grab yum for your >> RH version from download.fedoralegacy.org and then how to issue the >> commands to make it automatically update. > > You've left out some steps. I know, I was just trying to illustrate that the instructions can be general enough to apply to the 3 versions FL is supporting now, IMHO. Once RH 9 goes EOL, then the instructions will have to consider yum2 and any differences that entails, but that's still a few months away. >> I suppose that technically, if someone wanted to, a shell script >> could be written that would go out and grab the latest yum and >> configure it for the user, sort of like what Ximian used to do (and >> still does, now that I look) with their gnome releases. See an >> example here: >> >> http://www.ximian.com/products/desktop/download.html > > We can't even get the apt package QA tested, so there is little hope > at this stage we can get a custom installer written, tested, and > documented. I realize that. I wasn't suggesting that anyone seriously spend a lot of time on this. It's just there to show how far the hand holding could be taken. I'm personally of the opinion that anyone who needs that level of hand holding would be better served upgrading their system to Fedora Core instead of trying to maintain an older RH version. I'm interested in the Legacy project to keep production servers up and running. Desktop stuff is of very low priority to me. Like the Gaim update, that's not going to get my time. > Mostly it is about organization, but there has been some missing > content from time to time (like FAQ entries). I think you guys have done a pretty good job getting things going with the site. > Yes, please try to find some time for those QA duties ;) We really > need to get more people doing QA testing. Yep. I'm surprised that apt hasn't gotten more attention. It must be that anyone who's using it already has it installed and isn't in dire need of getting a FL specific version. To properly QA the package, I have to familiarize myself with it. The SPEC file is much more complex than the yum one. Not that it's all that tough to follow, I just have to make the time to check it out, track down the patches applied, look over the %pre and %post scripts, etc. And since I have no interest in using apt, it's time that feels more like work. :) Thanks again for all the work on the web site. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Ideas are more powerful than guns. We would not let people have guns... why should we let them have ideas? -- Joseph Stalin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIrqLuv+09NZUB1oRAqG3AJ449OvJglA3H/0Ee6g6rAtRGpPstQCfYyq0 A7B6Da/p+4BqYDCWTqlMFrY= =dv3p -----END PGP SIGNATURE----- From mail at jonaspasche.de Thu Feb 5 21:54:28 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 22:54:28 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040205132034.joxa8sc8koc4wc0c@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <1076007496.3582.188.camel@leonardo> <20040205132034.joxa8sc8koc4wc0c@mail.ph.utexas.edu> Message-ID: <1076018068.3582.199.camel@leonardo> Hi Eric, > I really do get some good ideas out of these discussions, believe it > or not. So thanks. But it would be even better if people wrote these > docs they'd like to see and submitted them. Sometimes it's only a matter of discussion. If I have a small suggestion, I only post a paragraph or two directly to the list. If there's more to do, I generate pages on jonaspasche.de/fedoralegacy as suggestions. However, in most cases I first want do discuss e.g. the structure and the content that people need, and then (re)write a proposal for it, just because it is time-consuming to completely rewrite a whole page two or more times. I want to get an idea of what people want, then creating a suggestion, and then hopefully only rework details. Actually, for the Download and Documentation pages, I don't see that there's really much still to do, which in turn brings me to the suggestion that we should shorten things regarding this topics because what we already have is "quite good enough for now", and we have more important things to do than discussings things until we reach a point where any list members not interested in documentation hate us. :) Jonas -------------- 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 mail at jonaspasche.de Thu Feb 5 22:22:46 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 23:22:46 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040205215003.GA3731@psilocybe.teonanacatl.org> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205215003.GA3731@psilocybe.teonanacatl.org> Message-ID: <1076019765.3582.210.camel@leonardo> Hi Todd, > What's the difference in the install instructions? You run rpm, > import the keys to your gpg keyring, and optionally enable the yum > service. Choosing yum1 without rpm upgrade or yum2 with rpm upgrade would be the only difference, right. > That's going to be an awful lot of text. There's a point at which the > extra documentation that's there to help the completely clueless will > bog down those who are just trying to get up and running fast. I > don't know exactly where that point is, but it's something to keep in > mind. A quick start page and a more in depth instruction page might be > quite useful once everything is all documented. That would keep as > many people happy as possible. Here's my proposal: http://jonaspasche.de/fedoralegacy/quickstart.html Basically it's a summary of the detailed instructions, leaving out anything an experienced user might regard as boring. What do you think about it? > > We can't even get the apt package QA tested, so there is little hope > > at this stage we can get a custom installer written, tested, and > > documented. I have the strong feeling that writing a custom installer is _really_ oversized. My patience with unexperienced people is very big, but I don't think that people that don't know how to manually browser through a repository and select a directory based on their operating system release will be interested in Fedora Legacy at all. :) > Yep. I'm surprised that apt hasn't gotten more attention. Me too. > And since I have > no interest in using apt, it's time that feels more like work. :) Hehe, I can understand this very well. However it's work that needs to done and shouldn't be too hard to do. We're all awaiting the apt release, but someone has to verify it. Please. Please! Jonas -------------- 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 mail at jonaspasche.de Thu Feb 5 22:25:01 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 23:25:01 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040205202806.GM2704@codegrinder.com> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205202806.GM2704@codegrinder.com> Message-ID: <1076019901.3582.213.camel@leonardo> Hi Jason, > The apt package is set up to configure itself upon the first invocation > based on the mirror list on the fedoralegacy server. > > I'll write the docs if need be Please be aware that Eric already has put together a documentation proposal for using apt. Before spending time on writing another one, can you please check back on: http://www.fedoralegacy.org/docs/apt-rh8.php Your comments are appreciated! Jonas -------------- 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 Freedom_Lover at pobox.com Thu Feb 5 22:47:35 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 5 Feb 2004 17:47:35 -0500 Subject: Suggestion for a new Download page In-Reply-To: <1076019765.3582.210.camel@leonardo> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205215003.GA3731@psilocybe.teonanacatl.org> <1076019765.3582.210.camel@leonardo> Message-ID: <20040205224735.GC3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Pasche wrote: >> What's the difference in the install instructions? You run rpm, >> import the keys to your gpg keyring, and optionally enable the yum >> service. > > Choosing yum1 without rpm upgrade or yum2 with rpm upgrade would be > the only difference, right. I suppose. But I might be missing something. I'm still hoping that either rpm doesn't get upgraded or that we decide to use the packages from fedora.us and perhaps give them a much lighter round of QA, since those packages have already gotten QA'd before. The other option that looks interesting is to do as Panu suggested and build apt to use the rpm404 libraries so it too avoides the buggy rpm 4.1 on RH 8.0. That would sure save us all some time. > Here's my proposal: > > http://jonaspasche.de/fedoralegacy/quickstart.html > > Basically it's a summary of the detailed instructions, leaving out > anything an experienced user might regard as boring. What do you > think about it? That looks pretty good. The only correction I'd make is replacing comfort with comfortable in the first sentence. > I have the strong feeling that writing a custom installer is > _really_ oversized. Yeah, I'd say so too. I was pretty much joking. > Hehe, I can understand this very well. However it's work that needs > to done and shouldn't be too hard to do. We're all awaiting the apt > release, but someone has to verify it. Please. Please! It's on my list of things to do. I have it installed on a 7.3 test box and have done the preliminary verification of the source. I'll slowly get around to checking it out. I won't be disappointed if it gets enough PUBLISH votes to go to -testing before I finish though (hint, hint Jesse :). - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The Constitution continues to remain no threat to our current form of government. -- Joseph Sobran -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIsgHuv+09NZUB1oRAtkgAKCtCca9LeGvXLNg16CKmKwLKYCLnwCgjcQZ a2XHPsbWVqwoO8CfSbA1ZPQ= =LRpw -----END PGP SIGNATURE----- From mail at jonaspasche.de Thu Feb 5 22:55:17 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Thu, 05 Feb 2004 23:55:17 +0100 Subject: Regarding QA Message-ID: <1076021717.3582.243.camel@leonardo> Hi again, I dived through the list archives to find self-introductions of people who explicitly said they were willing to do QA, which brought up quite a couple of people, and I shamelessly ripped out a small quote for anybody I've found: 2003-12-30 Jason Rohwedder "could potentially do some QA for the project if necessary" 2004-01-05 Charles R. Anderson "Do you want to do QA? - Yes." 2004-01-06 Christian Pearce "Do you want to do QA? - Yes" 2004-01-15 Todd Zullinger "I will because it's needed and the more folks that kick in a little time the easier the task will be for everyone" 2004-01-15 David Rees "I'd like to assist with the process of getting important security fixes QAd" 2004-01-15 Troy Dawson "Do you want to do QA? - Yes. I am very good at that." 2004-01-16 Jesse Keating "QA: As much as I possibly can" 2004-01-16 Johnny Strom "can work on RH 7.3 packages now and I have more computers running on RH 9 that I can do backporting work on and testing later" 2004-01-23 John Dalbec "still not sure how much testing is needed" @Jason, Charles, Christian, Todd, David, Troy, Jesse, Johnny, John: I don't know any of you personally, some of you through their postings. I don't have a clue what is needed to help you as I'm definitely no QA expert. I just have the strong feeling that "something" is missing, because nearly every second posting contains a phrase like "We need QA". So, here we are, having people willing to do QA, and having packages that need QA. I know that there's a "How to do QA" document still in the pipeline, but as I don't know anything on the QA process I still need help. I guess that at least a few of you have done QA before. Would you mind shouting "Here I am" to help the unexperienced with guidance and with answering questions? It would be a great help for the project if a few of you can review at least the apt package for 8.0 for now. We can step forward with the documentation for 8.0 then. I have the strong impression that we already did quite a lot of work that really rocks. Please help us continuing! Thanks, Jonas -------------- 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 Freedom_Lover at pobox.com Thu Feb 5 22:58:23 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 5 Feb 2004 17:58:23 -0500 Subject: apt using rpmlib404 (was Re: Suggestion for a new Download page) In-Reply-To: <1076005485.4877.29.camel@chip.laiskiainen.org> References: <4022853F.9080003@clifford.net> <200402051012.36279.jkeating@j2solutions.net> <1076005485.4877.29.camel@chip.laiskiainen.org> Message-ID: <20040205225823.GD3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Panu Matilainen wrote: > Hmm, actually you *could* build apt against rpmlib404 on RHL 8.0 and > avoid the rpm-hanging-itself issue with apt as well without > upgrading rpm itself. Know anyone that's done this? If that's an option, it might well be worth considering here. > That'd mean having separate builds of apt for both old and new lib > for those who want to upgrade rpm :-/ Not necessarily. If FL isn't providing updated version of rpm for RH 8.0, then anyone who upgrades on their own can also upgrade apt at the same time. That said, as RH 9 goes EOL and FL picks up support there, we'll be supporting apt using rpm 4.1.1 anyway and then adding packages for RH 8.0 might not be much more work. I don't have any RH 8.0 or 9 boxes around, other than to test FL packages with, so I don't have much daily usage experience with either. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The history of liberty is a history of resistance. -- Woodrow Wilson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAIsqOuv+09NZUB1oRAph9AKCqyj1HWVdKP0Ca+U0FP45P6U5vXACdGonQ Lm53G/aO+ij/gRFqAn1hPs8= =jH36 -----END PGP SIGNATURE----- From drees at greenhydrant.com Thu Feb 5 23:08:44 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 5 Feb 2004 15:08:44 -0800 (PST) Subject: Regarding QA In-Reply-To: <1076021717.3582.243.camel@leonardo> References: <1076021717.3582.243.camel@leonardo> Message-ID: <1310.208.48.139.163.1076022524.squirrel@www.greenhydrant.com> On Thu, February 5, 2004 at 2:55 pm, Jonas Pasche wrote: > > 2004-01-15 > David Rees > "I'd like to assist with the process of getting important security fixes > QAd" > > @Jason, Charles, Christian, Todd, David, Troy, Jesse, Johnny, John: I > don't know any of you personally, some of you through their postings. I > don't have a clue what is needed to help you as I'm definitely no QA > expert. I just have the strong feeling that "something" is missing, > because nearly every second posting contains a phrase like "We need QA". > So, here we are, having people willing to do QA, and having packages > that need QA. I've found that saying you'll do QA and then actually finding the time to do it around other responsibilities are two totally different things. ;-) I have managed to QA a few packages and have been meaning to get to apt, but haven't found the time yet. > I know that there's a "How to do QA" document still in the pipeline, but > as I don't know anything on the QA process I still need help. I guess > that at least a few of you have done QA before. Would you mind shouting > "Here I am" to help the unexperienced with guidance and with answering > questions? Here I am! BTW, there is a whole QA document on fedora.us which I found helpful. I also found that reviewing already QA'd bug reports to be helpful as well. It would be nice to see a whole step-by-step of what was done by a QAer to QA a package, noting that the QA process can vary by some amount depending on what's changed with a package. > It would be a great help for the project if a few of you can review at > least the apt package for 8.0 for now. We can step forward with the > documentation for 8.0 then. This is another holdback I'm sure for some users, is getting the appropriate test systems as not all QA people may have access to all systems supported by Legacy. I know that I've been meaning to get UML with RH 7.2, 7.3 and 8.0 so I can QA all packages from one machine. Having UML images of each distro would be helpful. > I have the strong impression that we already did quite a lot of work > that really rocks. Please help us continuing! Definitely! Especially considering the number people who are actively involved. -Dave From jkeating at j2solutions.net Thu Feb 5 23:08:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 15:08:02 -0800 Subject: Regarding QA In-Reply-To: <1076021717.3582.243.camel@leonardo> References: <1076021717.3582.243.camel@leonardo> Message-ID: <200402051508.07233.jkeating@j2solutions.net> On Thursday 05 February 2004 14:55, Jonas Pasche wrote: > @Jason, Charles, Christian, Todd, David, Troy, Jesse, Johnny, John: I > don't know any of you personally, some of you through their postings. > I don't have a clue what is needed to help you as I'm definitely no > QA expert. I just have the strong feeling that "something" is > missing, because nearly every second posting contains a phrase like > "We need QA". So, here we are, having people willing to do QA, and > having packages that need QA. I think the biggest problem is that the majority of us willing to do QA are concerned with 7.3, and possibly 7.2, but really don't have a need for 8.0. I happen to have a dogfood system I can drop any OS on and play with, so I can do the 8.0 and 7.2 work that nobody else seems to want to do, but my time is rather limited. This is one of the reasons I originally didn't want to support 7.2 and 8.0, because I forsaw a lack of community participation on these platforms. Almost every package that needs QA has at least gotten 7.3 QA, and it's just waiting for 7.2 and/or 8.0. So I have to ask again, is there really all that much need for 8.0 support? Is there going to be any help for it? Is there going to be anybody willing to VERIFY these packages once I put them into -testing? I hate to continue to push packages that have only gotten 7.2 and/or 7.3 QA, but no 8.0 QA, but at the same time, I hate holding back packages because nobody is willing to QA them on a crap platform. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 heinlein at cse.ogi.edu Fri Feb 6 00:08:14 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Thu, 5 Feb 2004 16:08:14 -0800 (PST) Subject: Regarding QA In-Reply-To: <200402051508.07233.jkeating@j2solutions.net> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> Message-ID: On Thu, 5 Feb 2004, Jesse Keating wrote: > I think the biggest problem is that the majority of us willing to do > QA are concerned with 7.3, and possibly 7.2, but really don't have a > need for 8.0. I'm getting up to speed on 8.0 testing, not that just one of me is going to be hugely helpful. :-) --Paul Heinlein From shrek-m at gmx.de Fri Feb 6 00:44:42 2004 From: shrek-m at gmx.de (shrek-m at gmx.de) Date: Fri, 6 Feb 2004 01:44:42 +0100 Subject: Mail Transaction Failed Message-ID: <200402060020.i160K0n02917@mx2.redhat.com> Mail transaction failed. Partial message is available. -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 22796 bytes Desc: not available URL: From mail at jonaspasche.de Fri Feb 6 01:14:19 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 06 Feb 2004 02:14:19 +0100 Subject: How to do QA Message-ID: <1076030058.3582.308.camel@leonardo> Hi there, I have put together a page that might help people doing QA: http://jonaspasche.de/fedoralegacy/qa-howto.html As I already mentioned, I don't have any experience with QA, so this is a call to the experienced QA testers: Can you please give feedback on the QA checklist entries? I guess they need to get heavily reworked. This page intentionally does _not_ cover the prodedure on how to build an updated package (finding out the flaw, developing patches, specfile reworks), and it does _not_ cover the procedure that happens _after_ QA. These topics will end up in different documents. We just need to start "somewhere", and this is hopefully a start. Jonas -------------- 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 mail at jonaspasche.de Fri Feb 6 01:25:01 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 06 Feb 2004 02:25:01 +0100 Subject: Regarding QA In-Reply-To: <1310.208.48.139.163.1076022524.squirrel@www.greenhydrant.com> References: <1076021717.3582.243.camel@leonardo> <1310.208.48.139.163.1076022524.squirrel@www.greenhydrant.com> Message-ID: <1076030701.3582.320.camel@leonardo> Hi David, > Here I am! BTW, there is a whole QA document on fedora.us which I found > helpful. I took these document(s) as the base for my "How to do QA" suggestion page; see my other post on this. I'd be glad if you could help reworking them! > I also found that reviewing already QA'd bug reports to be > helpful as well. Good idea! If you have some time, can you check some bug reports and compare them with the QA checklist? > It would be nice to see a whole step-by-step of what was > done by a QAer to QA a package, noting that the QA process can vary by > some amount depending on what's changed with a package. My suggestion is that the entries on the QA checklist get fixed shortnames like "[pristinesources]" that one can use in a QA report, possibly with comments, like "[pristinesources], verified MD5 and GPG". It might help when reviewing the QA approvals. Anyway, as I don't do QA, I don't know if this would really be helpful. > This is another holdback I'm sure for some users, is getting the > appropriate test systems as not all QA people may have access to all > systems supported by Legacy. There is a "Test System Provider" linked on the start page of fedoralegacy.org. What exactly does that mean? Is a machine available that users willing to do QA can use? If yes, how do they get an account on a test machine? > I know that I've been meaning to get UML > with RH 7.2, 7.3 and 8.0 so I can QA all packages from one machine. > Having UML images of each distro would be helpful. Any comments from QA testers on this? UML images could be of interest for people checking packages on their own machine, but I think we don't need them if a test system (possibly with UML) is available. Jonas -------------- 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 jkeating at j2solutions.net Fri Feb 6 01:28:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 17:28:51 -0800 Subject: Regarding QA In-Reply-To: <1076030701.3582.320.camel@leonardo> References: <1076021717.3582.243.camel@leonardo> <1310.208.48.139.163.1076022524.squirrel@www.greenhydrant.com> <1076030701.3582.320.camel@leonardo> Message-ID: <200402051728.51364.jkeating@j2solutions.net> On Thursday 05 February 2004 17:25, Jonas Pasche wrote: > > I know that I've been meaning to get UML > > with RH 7.2, 7.3 and 8.0 so I can QA all packages from one machine. > > Having UML images of each distro would be helpful. > > Any comments from QA testers on this? UML images could be of interest > for people checking packages on their own machine, but I think we > don't need them if a test system (possibly with UML) is available. Whats wrong with just a plain old chroot? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Fri Feb 6 01:52:59 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 19:52:59 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1076018068.3582.199.camel@leonardo> References: <4022853F.9080003@clifford.net> <1076007496.3582.188.camel@leonardo> <20040205132034.joxa8sc8koc4wc0c@mail.ph.utexas.edu> <1076018068.3582.199.camel@leonardo> Message-ID: <20040205195259.n6927ks0wog0woss@mail.ph.utexas.edu> Quoting Jonas Pasche : > Hi Eric, > > > I really do get some good ideas out of these discussions, believe it > > or not. So thanks. But it would be even better if people wrote these > > docs they'd like to see and submitted them. > > Sometimes it's only a matter of discussion. If I have a small > suggestion, I only post a paragraph or two directly to the list. If > there's more to do, I generate pages on jonaspasche.de/fedoralegacy as > suggestions. Yes, Jonas, the above comments I made were in no way aimed at you. Your help has been invaluable so far. I was trying to prod more (other) people to join in as you have.. > what we already have is "quite good enough for now", and we have more > important things to do than discussings things until we reach a point > where any list members not interested in documentation hate us. :) Yeah, I'll tone down my comments and solicitations for help... > Jonas -- Eric Rostetter From rostetter at mail.utexas.edu Fri Feb 6 02:23:05 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 20:23:05 -0600 Subject: Regarding QA In-Reply-To: <200402051508.07233.jkeating@j2solutions.net> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> Message-ID: <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> Quoting Jesse Keating : > So I have to ask again, is there really all that much need for 8.0 > support? There is a need. How much need is hard to say. For example, I have a single 8.0 server (plus a dual 8/9 devel machine, so I can support that single 8.0 server). So it is very important to me, until I can get that server moved to 9 or FC or RHEL or something else... > Is there going to be any help for it? Is there going to be > anybody willing to VERIFY these packages once I put them into -testing? Once I know *how* to verify them, I will verify anything that I use on 8.0. Of course, I don't use them all, so I may not verify them all. Jonas and I are working on QA docs (independently) so hopefully soon we'll have docs for that. But even then, I have work to do (create a gpg signature, etc) that I must do before I can help with QA. So far I've been focusing on docs. Only now are the docs getting to the point were I can help, since I can now follow the docs to enable me to help. This stuff (yum, gpg, etc) is all new to me, and holding me back from the QA process... > I hate to continue to push packages that have only gotten 7.2 and/or > 7.3 QA, but no 8.0 QA, but at the same time, I hate holding back > packages because nobody is willing to QA them on a crap platform. Well, then you need to help those of us that need help getting up to speed. I think Jonas and I are working on web pages because we just don't have much clue as to how to do QA and what have you... I'm an admin. I can do cvs, mail, nfs, smb, web, programs, etc. But I just don't know things like yum, gpg, and so on... You need to either use me where I can help (like setup cvs for the web, rsync for the web, etc) or you need to help me to learn to do the rest (QA, etc). Sorry to bitch, but from the start I've been hitting roadblocks when I try to help, instead of people willing to help me get up to speed. So, best I can do is help create the docs that will get me up to speed. Once the docs are done for things like QA and apt and so on, I'll definately help with those things... -- Eric Rostetter From rostetter at mail.utexas.edu Fri Feb 6 04:26:46 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 5 Feb 2004 22:26:46 -0600 Subject: How to do QA In-Reply-To: <1076030058.3582.308.camel@leonardo> References: <1076030058.3582.308.camel@leonardo> Message-ID: <20040205222646.i1afsgsock0k0o8g@mail.ph.utexas.edu> Quoting Jonas Pasche : > Hi there, > > I have put together a page that might help people doing QA: > > http://jonaspasche.de/fedoralegacy/qa-howto.html See also http://rashi.ph.utexas.edu/docs/QA.php > As I already mentioned, I don't have any experience with QA, so this is > a call to the experienced QA testers: Can you please give feedback on > the QA checklist entries? I guess they need to get heavily reworked. Ditto for my whole page. Note it is *not* complete in that there may be broken links, things that should be links that aren't yet, etc. > Jonas Nice job Jonas! -- Eric Rostetter From sheltren at cs.ucsb.edu Fri Feb 6 04:35:17 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 05 Feb 2004 20:35:17 -0800 Subject: Self-Introduction: Jeff Sheltren Message-ID: <1076042116.3947.14.camel@avalanche> Well, since I never got around to this, here goes: 1) Jeff Sheltren 2) Santa Barbara, CA, USA 3) System Administrator 4) UC Santa Barbara, Computer Science Dept. 5) I'd like to see all types of packages, since I have users that use pretty much everything =/ Currently, I'm most interested in 7.3 as I don't have any more 7.2/8.0 boxes. I've never done QA, but I can give it a whirl. 6) I haven't worked anything much in the past as far as these types of things go. I can program in C/C++, Java, Perl, PHP, shell scripts - most things other than Python - I leave that to Seth ;p Why should I be trusted? Because I'm a great guy! And I'd like to see this project succeed. -Jeff From cspencer at cait.org Fri Feb 6 04:51:02 2004 From: cspencer at cait.org (Chris Spencer) Date: Thu, 05 Feb 2004 22:51:02 -0600 Subject: Self Introduction: Chris Spencer Message-ID: <1076043062.2788.198.camel@cnote> 1. Chris Spencer 2. Macomb, IL 3. System Administrator 4. Western Illinois University 5. I have some RH9 and Fedora running as such I am most interested in them. I've never done QA, I would like to. Someone will need to put some time into showing me what's needed though. 6. Red Hat says I am certifiable. Trust me. See: http://www.redhat.com/training/certification/verify/?rhce_cert_display:certno=803003193909721&rhce_cert_display:verify_cb=Verify -Chris From ms-nospam-0306 at arcor.de Fri Feb 6 06:01:53 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 6 Feb 2004 07:01:53 +0100 Subject: How to do QA In-Reply-To: <1076030058.3582.308.camel@leonardo> References: <1076030058.3582.308.camel@leonardo> Message-ID: <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> On Fri, 06 Feb 2004 02:14:19 +0100, Jonas Pasche wrote: > I have put together a page that might help people doing QA: > > http://jonaspasche.de/fedoralegacy/qa-howto.html In such a detailed form this goes into a wrong direction IMHO. Some comments following... but first: Disclaimer in front: This is no attempt at stopping anyone from trying to create a "how to do QA" document, although I think there's no general recipe on how to do QA. If there are people who find such documents useful and if it helps them actually to get started with package reviews and approvals, I shut up. At this time, however, I'd like to avoid that the "QA hurdle" is set too high or that it is considered as set too high. Apart from that, copying some things from the fedora.us checklist simply doesn't make any sense. I like to point out that people who are new to reviewing packages should follow a top-down approach to testing packages (and build teams with people who look a level lower) instead of a bottom-up approach which starts with low-level technical package reviews: If Fedora Legacy wants to provide updated packages which fix security issues or critical bugs, the primary objective is to provide packages which fix those issues and which don't break anything else. This requires testing the built binary packages. If no binary packages are provided, it may be necessary to rebuild the source rpms. Like Eric Rostetter's page, an introduction to testing packages should start with stuff like how to rpmbuild a src.rpm as non-root user, how to extract a src.rpm, how to create an rpm diff against the previous src.rpm, and maybe later continue with additional checks at the level of the source rpm or binary rpm (e.g. ldd, rpm -qlvp and rpm -qR checks), meeting the requirements of a build system (=> completing the build dependencies). However, Fedora Legacy aims at modifying the source rpms as little as necessary, so reviewers don't generally need to spend any time reading the spec file beyond the diff against the previous release. Fedora Legacy has different requirements than Fedora.us. Such a checklist gives a false impression of what kind of package reviews are needed. For instance, the Fedora.us QA checklist has been misunderstood by people repeatedly as it covers many low-level issues but doesn't spend a single word on how much "in production" testing is required or when a package is classified as "stable" instead of "testing" or "unstable", respectively. A checklist makes the package verification procedure appear overly complex, complicated [and maybe even pedantic]. Or people go through the list step by step and don't examine anything else. Fedora.us has different requirements because it deals with entirely new package build scripts, which are often written from scratch or sometimes derived from other distributions. Sometimes a packager doesn't even take the time to understand what is done in the package build script and whether it does what it is supposed to do. Such circumstances require a different level of reviewing package submissions. Quite some of the Fedora.us guidelines and policies have been created, so the initial repository is filled with a solid base of usable packages, which other packages can built upon and which also serve as examples and inspiration, and to avoid that the repository is turned into a dumping ground for a wild mixture of packages, which would probably require increased maintenance upon updates and/or distribution upgrades (e.g. even improperly set dependencies can break a repository easily). Other requirements and procedures (e.g. different levels of trust and low-level package reviews) are because in an open community project you meet and work with people you don't know or haven't worked with before (do you build from src.rpm without comparing the package contents with its previous release?). Many of the steps in the linked/copied fedora.us checklist don't apply at all to Fedora Legacy. I feel that starting with this list as a basis is approaching the "QA problem" from the wrong direction. Start at the top and refine the procedures and policies. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eric.rostetter at physics.utexas.edu Fri Feb 6 06:20:15 2004 From: eric.rostetter at physics.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 00:20:15 -0600 Subject: overview page Message-ID: <20040206002015.ok0swokscccgc0w4@mail.ph.utexas.edu> The FL overview at http://www.fedoralegacy.org/about/overview.php seems to be very out of date. How should we go about updating it? * Can the webmaster (me) just update it as needed? * Should the list come to a consensus over changes? * Should we leave it for historical purposes? * Should we make changes as annotations (leaving old text, adding new text, with some way to denote which is old and new, etc)? -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From jkeating at j2solutions.net Fri Feb 6 06:33:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 22:33:24 -0800 Subject: Regarding QA In-Reply-To: <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> Message-ID: <200402052233.31190.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 February 2004 18:23, Eric Rostetter wrote: > Sorry to bitch, but from the start I've been hitting roadblocks when > I try to help, instead of people willing to help me get up to speed. > So, best I can do is help create the docs that will get me up to speed. > Once the docs are done for things like QA and apt and so on, I'll > definately help with those things... This is ok, you've done great work. I have to ask you, what exactly do you need to know? To Verify, you download the package, install it, and make sure it works. You then edit a text file that says what you did, save the file, then run "gpg --clearsign file". This will create a file.asc file. Copy the entire contents into the bugzilla form. You have now verified a package (; Help me help you. Where are you stuck? What needs more explaining? To me it's a simple process, but I'm probably too deep in to see where it's not simple for new comers. The threads have been long and numerous on docs and I haven't had the time to fully read through them (and I doubt I will). I will however review any documentation that you want me to. A direct email would work, as well as pinging me on IRC or through an instant messenger (I run msn/aim/icq, contact me privately through email if you'd like my info). I deeply appreciate what you've done for the project thus far, and I'd like to help you do more. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIzU64v2HLvE71NURAtFtAJ0Vdus2+76w2Cn50cwl7bLoZtLTFgCffaTG h7HBt0zE5o0u6nZFJ2/KroY= =Pul9 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Feb 6 06:42:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 22:42:41 -0800 Subject: overview page In-Reply-To: <20040206002015.ok0swokscccgc0w4@mail.ph.utexas.edu> References: <20040206002015.ok0swokscccgc0w4@mail.ph.utexas.edu> Message-ID: <200402052242.42872.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 February 2004 22:20, Eric Rostetter wrote: > The FL overview at > > http://www.fedoralegacy.org/about/overview.php > > seems to be very out of date. How should we go about updating it? > > * Can the webmaster (me) just update it as needed? > * Should the list come to a consensus over changes? We should have consensus over proposed changes. > * Should we leave it for historical purposes? Thats already in CVS for those that are interested. > * Should we make changes as annotations (leaving old text, adding new > text, with some way to denote which is old and new, etc)? We could have a small section at the bottom that says "Changes made last:" - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIzdh4v2HLvE71NURAhdxAKCGZcZQGkbacYVItaqHGDndJDlL4wCgsmbu GWUxNRUpLDUvgEqsaDXH5Bs= =D14k -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Feb 6 06:45:16 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 00:45:16 -0600 Subject: How to do QA In-Reply-To: <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> Message-ID: <20040206004516.mc84440kwscgkk40@mail.ph.utexas.edu> Quoting Michael Schwendt : > On Fri, 06 Feb 2004 02:14:19 +0100, Jonas Pasche wrote: > > > I have put together a page that might help people doing QA: > > > > http://jonaspasche.de/fedoralegacy/qa-howto.html > > In such a detailed form this goes into a wrong direction IMHO. Some Unfortunately, Jonas and I are starting the only place we can. We don't know the top from the bottom, so we can't start either place. So we start with the fedora.us page, as was suggested many times on the mailing list as the place to start. > Disclaimer in front: This is no attempt at stopping anyone from trying > to create a "how to do QA" document, although I think there's no general > recipe on how to do QA. I think we need the doc. I agree there is no standard way to do QA. But we need to provide something to get people started. Right now we don't have enough people doing QA. The reason, according to those who speak up, is they just don't know how. So, either we fail to publish packages, or we need to write such a how-to. I don't want to fail in our mission; to publish packages. So, that means we need to provide such a document, how ever nieve it may be. Hopefully we can add enough text to suggest to the reader that it is not a cut and dry follow these steps process. But at the same time, we need to push new members of the community in the right direction. In addition, there has been a desire by the lead members to have a formal (documented) set of policies and procedures. These web pages will fill that need, which until now is filled only be the mailing list archives, which is not a convenient source for locating policy. > If there are people who find such documents > useful and if it helps them actually to get started with package reviews > and approvals, I shut up. There are (myself, maybe Jonas, and a few others who have spoke up on the list). But that doesn't mean you should shut up. > At this time, however, I'd like to avoid that > the "QA hurdle" is set too high or that it is considered as set too > high. Right now the hurdle is set too high. The hurdle is people don't know what to do. The result is they do nothing. Anything to help people get involved can only be a Good Thing. > Apart from that, copying some things from the fedora.us checklist > simply doesn't make any sense. We've had no real other place to start. > I like to point out that people who are new to reviewing packages should > follow a top-down approach to testing packages (and build teams with > people who look a level lower) instead of a bottom-up approach which > starts with low-level technical package reviews. That's probably true, and sounds like it is reasonable or plausible to me, but at the same time I really have no idea what exactly it means... > If Fedora Legacy wants to > provide updated packages which fix security issues or critical bugs, the > primary objective is to provide packages which fix those issues and which > don't break anything else. Correct. > This requires testing the built binary > packages. Yes. But someone has to build them also, before they can be tested. And they must be pre-tested for things like trojans, etc. > If no binary packages are provided, it may be necessary to > rebuild the source rpms. Like Eric Rostetter's page, an introduction to > testing packages should start with stuff like how to rpmbuild a src.rpm as > non-root user, how to extract a src.rpm, how to create an rpm diff against > the previous src.rpm, and maybe later continue with additional checks at > the level of the source rpm or binary rpm (e.g. ldd, rpm -qlvp and rpm -qR > checks), meeting the requirements of a build system (=> completing the > build dependencies). That's good food for thought for the page(s). > However, Fedora Legacy aims at modifying the source > rpms as little as necessary, so reviewers don't generally need to spend > any time reading the spec file beyond the diff against the previous > release. I think there are two levels of reviewers. The top (expert) level needs to check everything. They make sure there are no trojans, that the changes don't introduce additional bugs, that the spec file is correctly updated, that the actual vulnerability is fixed, etc. The bottom level (normal mortals) test that the package builds (optional), installs correctly, seems to work when they use it, works with other packages that interact with it, etc. Right now my draft QA docs don't treat these two groups as separate, but I'd prefer that they do at some point. > A checklist makes the package verification procedure appear overly > complex, complicated [and maybe even pedantic]. Yes, but we need testers, and we don't have them. So we need to provide people with the info needed to become testers. And part of that means checklists... They are not the end-all-be-all, but they are a start. > Or people go through the > list step by step and don't examine anything else. Then we need the list to tell them (by implication) what else they need to do besides what is explicitly on the list. > Fedora.us has different > requirements because it deals with entirely new package build scripts, > which are often written from scratch or sometimes derived from other > distributions. Sometimes a packager doesn't even take the time to > understand what is done in the package build script and whether it does > what it is supposed to do. Such circumstances require a different level of > reviewing package submissions. Which is why Jonas and I put our work up for comment and correction, rather than publishing it on the fedoralegacy.org site. We *want* input and help. We want to be told what to remove, what to add, what to change. > previous release?). Many of the steps in the linked/copied fedora.us > checklist don't apply at all to Fedora Legacy. Great, but which ones? Please review my page at http://rashi.ph.utexas.edu/docs/QA.php and let me know what *doesn't* belong (as well as anything you think needs to be added, if anything). > I feel that starting with > this list as a basis is approaching the "QA problem" from the wrong > direction. Start at the top and refine the procedures and policies. Again, we (Jonas and I) have no idea of what top or bottom is here. We simply know that people, including ourselves, need help, and we're trying to provide it to the best of our ability with what we have available to us. And what we have available to us, at this time, is the fedora.us information... -- Eric Rostetter From pmatilai at welho.com Fri Feb 6 07:02:21 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 06 Feb 2004 09:02:21 +0200 Subject: apt using rpmlib404 (was Re: Suggestion for a new Download page) In-Reply-To: <20040205225823.GD3731@psilocybe.teonanacatl.org> References: <4022853F.9080003@clifford.net> <200402051012.36279.jkeating@j2solutions.net> <1076005485.4877.29.camel@chip.laiskiainen.org> <20040205225823.GD3731@psilocybe.teonanacatl.org> Message-ID: <1076050940.7430.8.camel@chip.laiskiainen.org> On Fri, 2004-02-06 at 00:58, Todd wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Panu Matilainen wrote: > > Hmm, actually you *could* build apt against rpmlib404 on RHL 8.0 and > > avoid the rpm-hanging-itself issue with apt as well without > > upgrading rpm itself. > > Know anyone that's done this? If that's an option, it might well be > worth considering here. Haven't actually tried it but I don't see any reason why it shouldn't work. There's no librpm404(-devel) package in RHL 8.0 (just the rpm-python module) so you'll need an extra package from ftp.rpm.org but I suppose that could go to legacy-utils. Then, with just set include and library paths properly in build.. - Panu - From rostetter at mail.utexas.edu Fri Feb 6 07:02:00 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 01:02:00 -0600 Subject: Regarding QA In-Reply-To: <200402052233.31190.jkeating@j2solutions.net> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> Message-ID: <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> Quoting Jesse Keating : > I have to ask you, what exactly do you need to know? To Verify, you > download the package, install it, and make sure it works. * how do you know what packages to test (only with slocate was it announced on the list, before that you had to know where to look, remember to look, etc) * If you don't know how to use the package, how do you know if it works? (so I can't help test apt if I don't have any docs on how to use it, etc) * Once I see it works, how do I report that it works? * How do I verify I'm testing the correct package (gnupg signature checks, etc) * How do I get a gnupg signature? Do I need to register it somewhere? how? Where? * How do I sign a message? What does cleartext sign mean? etc. > You then edit a > text file that says what you did, save the file, then run "gpg --clearsign > file". This will create a file.asc file. Copy the entire contents into > the bugzilla form. You have now verified a package (; But I don't have a gpg key. How do I get one? Is there anything I need to know about getting a key (size, type, content, etc)? How should I protect it once I have it? Copy the contents of what (the file I created, the .asc file, both?) > Help me help you. Where are you stuck? What needs more explaining? To me > it's a simple process, but I'm probably too deep in to see where it's not > simple for new comers. You assume I'm at your level. That I already have a gpg key (I don't). That I know how to get such a key (I don't). That I know how to register such a key somewhere (I don't). That I know how to use such a key (I don't). That I have gpg installed on my machine (I do!). And so on. To you, this is all simple. To me, this is rocket science... > The threads have been long and numerous on docs and I haven't had the time > to fully read through them (and I doubt I will). I will however review > any documentation that you want me to. Please review the QA.php file I posted. > A direct email would work, as well > as pinging me on IRC or through an instant messenger (I run msn/aim/icq, > contact me privately through email if you'd like my info). Installing some form o instant messenger is on my todo list. Never used one though. Will do when I get some time. Don't use IRC, would rather not. E-mail I prefer to send to the list most times, as I can get feedback from more than one person (Jesse, you know I e-mail both you and the list often). > I deeply appreciate what you've done for the project thus far, and I'd like > to help you do more. I've offered to do more "behind the scenes" stuff, but I feel that you are too busy to take me up on it (kind of like offers from Warren and Chuck). Also, you have no real reason to trust me yet since I've never posted my introduction, etc. (I plan to, now that I've documented how to, just as soon as I get a gpg key). Don't take my complaining too seriously. I'm over dramatic when trying to solicit help. But the docs I'm writing I write for one reason: I don't know the answer, and I know others don't know the answer, and that is holding us back. So, to get me and others involved, I try to research the topic, try to solicite input from others, and try to put together a doc that will allow me (and hopefully others) to do what we want to do, what you want us to do, without having to bomb the mailing list or yourself with the same questions over and over (how do I get a gpg key, etc). You (and the list) shouldn't have to answer these types of questions; the docs should do that. That's why I'm trying to document this kind of stuff. Well, it's late, sorry for running on like that... -- Eric Rostetter From pmatilai at welho.com Fri Feb 6 07:23:49 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 06 Feb 2004 09:23:49 +0200 Subject: Suggestion for a new Download page In-Reply-To: <1076019901.3582.213.camel@leonardo> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205202806.GM2704@codegrinder.com> <1076019901.3582.213.camel@leonardo> Message-ID: <1076052229.7430.28.camel@chip.laiskiainen.org> On Fri, 2004-02-06 at 00:25, Jonas Pasche wrote: > Hi Jason, > > > The apt package is set up to configure itself upon the first invocation > > based on the mirror list on the fedoralegacy server. > > > > I'll write the docs if need be > > Please be aware that Eric already has put together a documentation > proposal for using apt. Before spending time on writing another one, can > you please check back on: > > http://www.fedoralegacy.org/docs/apt-rh8.php > > Your comments are appreciated! Hmm.. a few comments: Step 2.1: after installation FL apt will prompt you to select a mirror site, want it or not. So it's not optional by any means. You don't really want to point people to the fedoralegacy-xx-mirrors.list files because you can't download them, put someplace and have apt use it. Instead the mirror-select script downloads those files, parses it and prompts you with a menu to select the nearest mirror. Step 3.2: "apt-get -f install" is about *fixing* a "broken" rpmdb, "apt-get check" checks for it's consistency. There's no need to run that under normal conditions, apt-get checks for the consistency anyway on each and every run and suggests running apt-get -f install if it finds unsatisfied dependencies. I'd suggest removing that step entirely. Step 7: "servers specified in the /etc/apt/sources.list" is probably a bit confusing wrt "update" operation since there will be nothing in there by default on FL apt, since the mirror-selector writes its entries into /etc/apt/sources.list.d/mirror-select.list. So you might want to mention the sources.list.d thingy as well. The description of "updgrade" is a bit backwards: "upgrade" operation will never, ever install any new packages or remove others, changed dependencies or not. It'll just not upgrade something with changed dependencies and on RHL that can be bad - see below. Another thing: "dist-upgrade" is not a dangerous operation, really.. unless you put something like rawhide or a newer distro into your sources list. The name suggests upgrading the whole distro but that's basically a debianism - they have this policy that during a lifetime of a given release updates aren't allowed to be obsoleted so you don't need the extra dependency calculations of dist-upgrade, plain upgrade will do to job. On RHL that's not the case - in fact you'll *have* to use dist-upgrade to get all errata installed: for example "timeconfig" was obsoleted by "redhat-config-time" within RHL 8.0 errata. Other than these few mistakes/misunderstandings - nice, clean and simple instructions for basic apt usage :) - Panu - > > Jonas From skvidal at phy.duke.edu Fri Feb 6 07:24:09 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 06 Feb 2004 02:24:09 -0500 Subject: [Fwd: Re: Symlink Vulnerability in GNU libtool <1.5.2] Message-ID: <1076052249.3325.38.camel@binkley> libtool - vulnerability, see attached. in 7.3 it looks like more or less the same patch as attached (provided the attached patch works), except that it should start around line 4320 in /usr/share/libtool/ltmain.sh instead of 5673 looks like debian has a patch out for this one, too. And I expect one for rhl 9 too. - starting around line 4457 - same file. -sv -------------- next part -------------- An embedded message was scrubbed... From: Scott James Remnant Subject: Re: Symlink Vulnerability in GNU libtool <1.5.2 Date: Tue, 03 Feb 2004 20:33:58 +0000 Size: 4541 URL: From Freedom_Lover at pobox.com Fri Feb 6 08:53:45 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 6 Feb 2004 03:53:45 -0500 Subject: Regarding QA In-Reply-To: <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> Message-ID: <20040206085345.GK3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rostetter wrote: > * how do you know what packages to test (only with slocate was it > announced on the list, before that you had to know where to look, > remember to look, etc) [Jesse and others more in the know will hopefully chime in here, but since I'm replying to answer some of the gpg questions you have, I might as well take a stab at some of the others. If it saves someone else from having to type it up, that'll be great.] The Legacy Devel Tracker link on the home page points you where you want to start: http://www.fedora.us/LEGACY There you'll find the wonders up bugzilla and a list of all the current issues that need attention. > * If you don't know how to use the package, how do you know if it > works? (so I can't help test apt if I don't have any docs on how to > use it, etc) It's certainly difficult if you haven't a clue about an app. Usually though, you can take a peak at the man page and figure out the basic operations and test those. Ideally, someone that uses a package or is familiar with it will be more likely to get on doing QA for that package than you will. At least, that's the idea. So far, the apt package is proving that's not always how it works. :) > * Once I see it works, how do I report that it works? Follow along on some of the other bug reports and see how those are done. That helps. It's a new process for me, I'm trying to keep my eye's open and learn as much as possible from watching and reading. If you end up with a specific question, like, "I was looking at package fubar-1.1-1.legacy.src.rpm and it doesn't build right for me without package baz-devel, what should I do?" Just ask and someone will help out. > * How do I verify I'm testing the correct package (gnupg signature > checks, etc) The gpg check is the one I prefer to use. The Fedora.us wiki's suggest gpg signed md5 hash files to go along with the uploaded packages and most of the packages submitted so far for FL have done this, though I have to wonder what the point is. If you check the gpg signature of the md5 file and then use the md5 file to check the packages, you might as well just use gpg to check the packages directly. (Hope that didn't leave you more confused than you were before.) For example, say you're going to QA apt (cause everyone wants to), you'd find it in bugzilla and look at the entries there. You see that in Jason's latest comment there he's linked these two files: https://mail.codegrinder.com/www/apt4/md5sum.asc https://mail.codegrinder.com/www/apt4/apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm Download them both. Then run rpm --checksig -v (or just -Kv if you're lazy like me) on the rpm file. Assuming you already have Jason's key (and you probably don't yet, but we'll get to that later), you should get output like this: $ rpm --checksig -v apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm: MD5 sum OK: bbb702d9ed7f07f26be25f1f4099146c gpg: Signature made Thu 29 Jan 2004 12:49:32 AM EST using DSA key ID 9B643F0D gpg: Good signature from "Jason Rohwedder " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0AA1 6522 AD40 FB05 EFB3 2344 C364 0463 9B64 3F0D You could also use the md5sum file. To do that you'd check the gpg signature on it first: $ gpg --verify md5sum.asc gpg: Signature made Thu 29 Jan 2004 12:56:44 AM EST using DSA key ID 9B643F0D gpg: Good signature from "Jason Rohwedder " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0AA1 6522 AD40 FB05 EFB3 2344 C364 0463 9B64 3F0D If the gpg sig checks out, use the md5sum program to verify the md5 hash of the rpm you downloaded against the hash stored in the md5sum file: $ md5sum -c md5sum.asc apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm: OK > * How do I get a gnupg signature? Do I need to register it > somewhere? how? Where? The signatures are what you'll find in the text of the bugzilla entries and in .asc files. These signatures are also embedded in rpm packages as well. Don't worry too much more about this part at the moment. > * How do I sign a message? What does cleartext sign mean? etc. To sign a message, you would save it as a file, say you call it slocate-QA. Then run: $ gpg --clearsign slocate-QA [you'll be prompted for your passphrase and then the file will be signed] You will now have another file, slocate.QA.asc. You would then copy the contents of that file and paste them into bugzilla. When you clearsign a message, it means that the message is still readable to others even without using the gpg software to decode it. That's what you see when a message has BEGIN PGP SIGNED MESSAGE, BEGIN PGP SIGNATURE, and END PGP SIGNATURE. [One thing to be careful of here, bugzilla's text entry box will wrap text (I don't know at what width exactly) and if it does this, your gpg signature will be broken. That's one of the things about signatures, they really work. Any change to a message, no matter how slight, will invalidate the signature. So just wrap the text you plan to clearsign before you post it to bugzilla. Keeping it under 80 characters is sufficient as far as I can tell.] > But I don't have a gpg key. How do I get one? Simple enough. Use gpg to create one: $ gpg --gen-key and follow the prompts. The defaults should all be fine. Just put in your name and your email address and pick a good passphrase. At the end of the process, there will be some lines that look similar to this: pub 1024D/86182970 2004-02-06 Just A. Test Key fingerprint = E467 045D 0180 8726 F917 74A7 CA78 2901 8618 2970 sub 1024g/76AC068B 2004-02-06 Take note of the string of letters and numbers after the pub 1024D. This is your keyid. In this case, that's 86182970. > Is there anything I need to know about getting a key (size, type, > content, etc)? You could spend a long time studying the OpenPGP spec and the pros and cons of the various algorithms, but you don't need to. The defaults will work just fine. > How should I protect it once I have it? The two main method's of protecting your key are your file system security and the passphrase. You want to keep anyone from stealing a copy of your secret key. If someone does manage such a thing, they still have to guess your passhphrase in order to use the key to do anything nasty. So keep your system secure and choose a strong passphrase. Also, it's best to generate a revocation certificate. This is something that can be used in case you ever lose your key, forget your passphrase, or find that someone has compromised your system and stolen your key. That's done by running: $ gpg --gen-revoke $USERID replacing $USERID with the keyid from when you generated your key. Follow the prompts, enter your passphrase, and save the output someplace safe, like on a CD. (Note that you can also specify $USERID using your email address, see the section titled "How to specify a user ID" in the gpg man page for more details about this if you;re curious.) Finally, you should upload your key to a keyserver. The Fedora.us docs suggest pgp.mit.edu, so we'll stick with that one: $ gpg --keyserver pgp.mit.edu --send-key $USERID To download the keys of other users, you can use: $ gpg --keyserver pgp.mit.edu --recv-keys $THEIR_KEYID When people post a self introduction to the list, it should include some information about their gpg key. The output of this command is what you want to send: $ gpg --fingerprint $USERID It looks like this: $ gpg --fingerprint 86182970 pub 1024D/86182970 2004-02-06 Just A. Test Key fingerprint = E467 045D 0180 8726 F917 74A7 CA78 2901 8618 2970 sub 1024g/76AC068B 2004-02-06 Other sources of information that might prove useful to you are the gnupg.org website, the fine manual that comes with gpg, the Fedora.us Self Introduction wiki and the Fedora GPG mini-HOWTO, which is just post Warren made to the fedora-devel list a while back trying to get some documentation started. You'll notice since there isn't a handy HOWTO to send you to that this documentation has yet to be written, AFAIK. Sorry for the verbosity. It seems hard to even begin to cover gpg in such a short amount of space. I did a slightly more detailed, though still pretty minimal presentation for a local LUG a while back. That was mainly focused on using gpg for securing email, but a lot of it should be somewhat relevant to anyone just starting with gpg. A copy of that presentation is available at: http://pobox.com/~tmz/cplug/encryption-howto/siframes.html I hope this helps a little. I know that gpg can seem like a lot to take in at once. It's been an interest of mine for a long time, so that was at least one thing I didn't have to learn in order to get started trying to help out here. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Those who have been intoxicated with power... can never willingly abandon it. -- Edmund Burke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAI1YZuv+09NZUB1oRAnBxAKC7f7rPB8v1gTvQjz822MhSOcZ40QCgkip4 EN6rNO84yH1gTlHknsrTM1s= =w3CU -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Fri Feb 6 14:34:46 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 6 Feb 2004 15:34:46 +0100 Subject: Regarding QA In-Reply-To: <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> Message-ID: <20040206153446.7a4d8fd7.ms-nospam-0306@arcor.de> On Fri, 6 Feb 2004 01:02:00 -0600, Eric Rostetter wrote: > * how do you know what packages to test (only with slocate was it announced > on the list, before that you had to know where to look, remember to look, > etc) [in addition to the other reply to this] At bugzilla.fedora.us, Fedora Legacy has an own "product" where package requests and/or bugs can be filed. In addition to that, in tickets with Fedora Legacy relevance, the "LEGACY" keywords is set and makes queries easy (bugzilla keywords and other bugzilla details are explained when e.g. you follow the links at the top of a ticket). I think slocate had been mentioned on the list before the ticket was opened, though. > * If you don't know how to use the package, how do you know if it works? > (so I can't help test apt if I don't have any docs on how to use it, etc) Valid point and also one reason (besides lack of human resources and lack of interest) why some packages are stuck in the fedora.us queue. Anyone who would like to give apt a try, could help though and simply start using the program daily. With updates, some fixes and packages can be reviewed at the source code level. For instance, sometimes a trivial one-line patch closes a buffer overflow problem, and if they built binary packages matches the previous binary package very closely, there's no reason to be concerned. > * Once I see it works, how do I report that it works? Comments on packages are to be added to the corresponding bugzilla ticket. > * How do I verify I'm testing the correct package (gnupg signature checks, > etc) A package should be signed with the packager's key (and official Fedora Legacy packages signed with the Fedora Legacy key). "rpm -Kv filename.rpm" gives information on package integrity and signatures. Additionally, together with the package the MD5 or SHA1 checksum is likely posted. "md5sum filename" or "sha1sum filename" must return the same checksum. Since GPG keys are imported into the RPM database ("rpm --import keyfile"), make sure you only import keys of people you want to import. > * How do I get a gnupg signature? The introduction in /usr/share/doc/gnupg-*/README might help if Google doesn't find tutorials or beginners' guides (it should!). There's also software that makes working with keys and keyrings easier, e.g. the graphical GPA (package "gpa" at fedora.us). > Do I need to register it somewhere? how? > Where? To spread a public key, it can be uploaded in ASCII exported form to public keyservers, such as http://pgp.mit.edu:11371/ and http://www.keyserver.net/ > * How do I sign a message? At the commandline for example gpg --clearsig file and the rest is interactive and provided that you have a default secret key. That would create a signed file "file.asc" (.asc => ASCII). > What does cleartext sign mean? etc. It's when the signed part is enclosed with a header (-----BEGIN PGP SIGNED MESSAGE-----), the signature is appended at the bottom, both in ASCII encoded form suitable for direct inclusion in a mail, and the signed part stays readable because it is not encoded (except that special sequences are escaped). Example: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello World! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAI6Lr0iMVcrivHFQRAu3EAJ9gadwyNnU5zmRHk4A8ZN3SoMh7RwCggFpJ rx0K2+fqWTWKUImFI93Yh7o= =WKXp -----END PGP SIGNATURE----- One can cut'n'paste such a block of text into a file and verify it with "gpg --verify file", for instance. > Please review the QA.php file I posted. It's good where it starts at the top of the procedure, that is rebuilding a src.rpm, extracting a src.rpm and so on. It's not good where it copies fedora.us guidelines which don't apply to Fedora Legacy. E.g. you don't want to replace with rpm macros any hardcoded paths in a spec file, if that packages has been building and working fine for ages and it is only added an additional patch. -- From matt.phillips at c.ict.om.org Fri Feb 6 14:36:14 2004 From: matt.phillips at c.ict.om.org (Matt Phillips) Date: Fri, 6 Feb 2004 09:36:14 -0500 Subject: Self-Introduction: Matt Phillips Message-ID: <20040206143614.GE3721@mattplaptop.c.ict.om.org> OK, so I realized that I never actually introduced myself to this list, just to fedora-devel... Full legal name: Matthew C Phillips Country, City: USA, New Cumberland Profession: Linux Developer, Network Security Analyst Company: Operation Mobilization Goals in Fedora Project: - Fedora Legacy - I'm on a team that develops a customized distro to meet the needs of our diverse offices worldwide. This had been based on RH 9 and will soon be based on FC. Unfortunately our EOL needs to be much longer than RedHat or Fedora's. We will be supporting older versions for quite some time, so we'd might as well work with Fedora Legacy and not duplicate effort. Historical qualifications: - a SquirrelMail developer 2000-2002 - a Centrallix developer http://centrallix.sourceforge.net/ - somewhat proficient in C, C++, Perl, PHP, Shell, etc. Learning Python now.... - Not too much of what I do is known outside my organization, unfortunately. But then again, trust is something that can only be built up over time. - RHCE GPG: pub 1024D/0DAA7AF4 2002-03-06 Matt Phillips Key fingerprint = C64E A6C2 48F6 70FE CFEC 5490 9F2B B62C 0DAA 7AF4 sub 1024g/6DC2030C 2002-03-06 -- Matt Phillips International Coordinating Team, Operation Mobilisation Public PGP Key: http://moses.om.org/~mattp/gpg.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galt at gothpoodle.com Fri Feb 6 14:43:49 2004 From: galt at gothpoodle.com (Matthew Berg) Date: 06 Feb 2004 09:43:49 -0500 Subject: Self-Introduction: Matthew Berg Message-ID: <1076078630.6544.96.camel@damballah.gothpoodle.com> 1. Full legal name Matthew William Berg 2. Country, City United States, Buffalo, New York 3. Profession System Administrator 4. School No college/university diploma. Training courses: SCO Non-Stop Clustering SCO Webtop Administration SCO Network Administration Hands-On With HP-UX 11.00 Hands-On With LVM And Mirrordisk/UX HP-UX System And Network Administration II HP-UX Troubleshooting Administrating Microsoft Windows NT 4.0 Supporting Microsoft NT 4.0 Core Technologies Certifications: SCO Openserver ACE SCO Unixware ACE SCO Non-Stop Clustering Master ACE SCO Openserver Master ACE HP-UX Star Certified Professional LPI Level One 5. My goals in the Fedora Project Which packages? Main concern is security fixes for base system (e.g. util-linux, glibc) and server software (e.g. wu-ftpd, openssh) for Red Hat 7.2 QA? Quite definitely. I'll be reading over the threads on this over the next couple days and seeing where I can help. (I've got not only permission, but encouragment from my employer to spend my time on this.) If anyone is actively coordinating QA activity and wants to drop me a line you can either e-mail me, or catch me on IRC (I'm galt on EFnet, freenode, and gnome.org). Anything special? Nope. I'm pretty boring. I just want to avoid upgrading for no better reason than there's something newer available. :) 6. Historical qualifications Other projects? I'm part of the Ruby-GNOME2 project team, primarly working on documentation, as well as a few small patches for Ruby/GTK2. Nothing much else of consequence, though apparently Ville Laurikari is using the spec file I did for his TRE package. I also did a spec for CRM114 for Bill Yerazunis. He's holding off releasing a packaged version, however, since he wants to finish a code reorginization first. Computer languages and skills? Languages I work in regularly - perl, bourne shell, ruby, C. A large part of my job responsibility is testing and deploying updates to our platform. Even prior to the EOL we performed our own QA, which caught a few potentially bad issues (e.g. the xinetd update having a default cps limit, when the prior version had it disabled). I also maintain the majority of our own RPMS, which includes both custom software and modified versions of existing software; e.g. rebuilding the 7.2 kernel with the ips 6.10 driver, kudzu and anaconda with the related pcitable updates, and rebuilding the kickstart images. Prior to my four year tenure at this company I worked support at Ingram Micro for Openserver, Unixware, Solaris, and HP/UX. Other platforms I've had experience with include AIX, OpenBSD, BSDI, Slackware, Debian, and SuSE. Why should you trust me? Because I'm a hoopy frood and know where my towel is. From jpdalbec at ysu.edu Fri Feb 6 14:52:44 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 06 Feb 2004 09:52:44 -0500 Subject: Regarding QA Message-ID: <4023AA3C.30508@ysu.edu> It would be easier to QA apt for Red Hat 8.0 if Jason's web site weren't down. Anyone have a mirror? John From rostetter at mail.utexas.edu Fri Feb 6 15:56:54 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 09:56:54 -0600 Subject: Suggestion for a new Download page In-Reply-To: <1076052229.7430.28.camel@chip.laiskiainen.org> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205202806.GM2704@codegrinder.com> <1076019901.3582.213.camel@leonardo> <1076052229.7430.28.camel@chip.laiskiainen.org> Message-ID: <20040206095654.a4lg080gk48084c8@mail.ph.utexas.edu> Quoting Panu Matilainen : > Step 2.1: after installation FL apt will prompt you to select a mirror > site, want it or not. So it's not optional by any means. You don't Changed. > Step 3.2: "apt-get -f install" is about *fixing* a "broken" rpmdb, > "apt-get check" checks for it's consistency. There's no need to run that > under normal conditions, apt-get checks for the consistency anyway on > each and every run and suggests running apt-get -f install if it finds > unsatisfied dependencies. I'd suggest removing that step entirely. Removed. > Step 7: Now Step 6. > "servers specified in the /etc/apt/sources.list" is probably a bit > confusing wrt "update" operation since there will be nothing in there by Removed. > default on FL apt, since the mirror-selector writes its entries into > /etc/apt/sources.list.d/mirror-select.list. So you might want to mention > the sources.list.d thingy as well. Have no idea what that means. So just removed the whole bit about files. > The description of "updgrade" is a bit backwards: "upgrade" operation > will never, ever install any new packages or remove others, changed > dependencies or not. It'll just not upgrade something with changed > dependencies and on RHL that can be bad - see below. Hmmm... That's not what I've read/seen. I've not changed this yet. Can someone write up a new description for this command that is correct for FL apt? > Another thing: "dist-upgrade" is not a dangerous operation, really.. Okay, I'll trust you on that. > to job. On RHL that's not the case - in fact you'll *have* to use > dist-upgrade to get all errata installed: for example "timeconfig" was > obsoleted by "redhat-config-time" within RHL 8.0 errata. So should we be telling them to use dist-upgrade instead of upgrade in the instructions? Since we probably want them to get all the updates including updates which obsolete others, no? > - Panu - -- Eric Rostetter From rohwedde at codegrinder.com Fri Feb 6 16:08:14 2004 From: rohwedde at codegrinder.com (Jason) Date: Fri, 6 Feb 2004 10:08:14 -0600 Subject: Regarding QA In-Reply-To: <4023AA3C.30508@ysu.edu> References: <4023AA3C.30508@ysu.edu> Message-ID: <20040206160814.GR2704@codegrinder.com> On Fri, Feb 06, 2004 at 09:52:44AM -0500, John Dalbec wrote: > It would be easier to QA apt for Red Hat 8.0 if Jason's web site weren't > down. Anyone have a mirror? > John > Hrmm.. I can still connect to it from here at work.. -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mail at jonaspasche.de Fri Feb 6 16:14:30 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 06 Feb 2004 17:14:30 +0100 Subject: Suggestion for a new Download page In-Reply-To: <20040206095654.a4lg080gk48084c8@mail.ph.utexas.edu> References: <4022853F.9080003@clifford.net> <20040205130502.1sxu8cgk00s8gs4c@mail.ph.utexas.edu> <20040205200013.GY3731@psilocybe.teonanacatl.org> <20040205141948.xcomcs4c8wco8ckc@mail.ph.utexas.edu> <20040205202806.GM2704@codegrinder.com> <1076019901.3582.213.camel@leonardo> <1076052229.7430.28.camel@chip.laiskiainen.org> <20040206095654.a4lg080gk48084c8@mail.ph.utexas.edu> Message-ID: <1076084070.3556.112.camel@leonardo> Hi Eric, > > The description of "updgrade" is a bit backwards: "upgrade" operation > > will never, ever install any new packages or remove others, changed > > dependencies or not. It'll just not upgrade something with changed > > dependencies and on RHL that can be bad - see below. > > Hmmm... That's not what I've read/seen. I've not changed this yet. > Can someone write up a new description for this command that is > correct for FL apt? The man page of apt-get is very clear on this: --- cut --- upgrade upgrade is used to install the newest versions of all packages currently installed on the system from the sources enumerated in /etc/apt/sources.list. Packages currently installed with new >>> versions available are retrieved and upgraded; under no circum- >>> stances are currently installed packages removed, or packages >>> not already installed retrieved and installed. New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version. An update must be performed first so that apt-get knows that new versions of packages are available. --- cut --- So Panu is right on this. Jonas -------------- 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 Freedom_Lover at pobox.com Fri Feb 6 16:30:46 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 6 Feb 2004 11:30:46 -0500 Subject: Regarding QA In-Reply-To: <20040206153446.7a4d8fd7.ms-nospam-0306@arcor.de> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> <20040206153446.7a4d8fd7.ms-nospam-0306@arcor.de> Message-ID: <20040206163046.GL3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > Since GPG keys are imported into the RPM database ("rpm --import > keyfile"), make sure you only import keys of people you want to > import. One minor point here, just so no new users get terribly confused when things don't work right. In the case of RH 7.x, you want to import the keys to the gpg keyring, using gpg --import. RPM < 4.1 didn't store gpg keys in it's own database. Also, as long as RH 8.0 is using yum1 (and god I wish we'd just reach a consensus and get cracking on QA for one or the other set of packages, yum2 + rpm 4.1.1 + apt or yum1 + apt built against librpm404), then you'll have to maintain some keys in two places. Yum will be using the gpg keyring since it's using the older rpm library, so it's checks will need keys imported using gpg --import as root. Checks run using rpm -Kv will need to have the keys imported via rpm into its database. Damn confusing, I know. Call that one of the pros of upgrading to yum2 and rpm 4.1.1. I'm not sure which set of pros and cons outweighs the other. Anyone keeping track? - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== That which seems the height of absurdity in one generation often becomes the height of wisdom in the next. -- John Stuart Mill (1806-1873) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAI8E2uv+09NZUB1oRAnuIAKDGtXQCPQVya146FLmrtGaWeLwQJwCg2FW9 2A+plBW7AglmlskZd5qRD+8= =+Meh -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Feb 6 17:00:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 11:00:17 -0600 Subject: Self-Introduction: Eric Jon Rostetter Message-ID: <20040206110017.qsi84kcso800s4kw@mail.ph.utexas.edu> 1. Full legal name Eric Jon Rostetter 2. Country, City Austin, Texas, USA 3. Profession or Student status Computer Programmer, Full Time 4. Company or School Department of Physics, The University of Texas at Austin 5. Your goals in the Fedora Legacy Project * To see it succeed! * To be able to support my legacy RHL machines (7.2, 7.3, 8.0, 9) * Will do QA for packages I use on OS versions I have available, as time permits, once I learn how ;) 6. Historical qualifications # What other projects have you worked on in the past? Well, back in the old days (80's) when PDP-11's and VAX-11's ruled the earth, I used to be involved in a lot of RSTS/RSX-11/RT-11/VMS projects and ports like the NBS Pascal compiler, Minitab (PDP/VAX ports), VMS TED/SED editor, etc. (Under the tutelage of the late, great Brian Nelson at The University of Toledo). But then as the 90's came, UToledo found it cheaper to buy packages then create them, so I became an ordinary admin. When UToledo went under back in 1998/1999, I moved to the "other UT"; The University of Texas at Austin. Here I'm the sysadmin for the Dept. of Physics (Linux, AIX, OpenVMS mainly), provide their needed services (web, e-mail, nfs, etc) and am the sysadmin and now new programmer for the UT Homework Service (online homework, quiz, exams, grading, etc. open to the world for free). I've participated heavily in a few open source projects such as The Horde Project (www.horde.org) since moving to Austin. I'm an authorized certificate authority for UT Austin for Thawte certificates (mean I can create/approve/revoke/etc. Thawte certificates for all of UT Austin) which implies some trust level afforded my by the University itself (outside my department) and by Thawte. # What computer languages and other skills do you know? Can admin AIX, VMS, Linux, etc. Program in C, FORTRAN, Pascal, Perl, shell scripting, etc. Do xml/xslt, (x)html, php, javascript, etc. Run web sites, e-mail servers, NFS, NIS, SQL databases, etc. Can build RPMs and do other Red Hat Linux type stuff. # What computer languages and other skills do you lack? (Made this up) I apparently lack any clue about today's hot trends like gpg, wiki, irc, IM, and the lot. I'm a dinosaur... # Why should we trust you? You probably shouldn't yet. ;) But, I do have trust within groups like horde.org, and do have trust within UToledo, UT Austin, and Thawte.com. Other than that, no real reason. I'll earn my trust (or lack of trust) here by hard work here. 7. GPG KEYID and fingerprint pub 1024D/49C7A0F2 2004-02-06 Eric Jon Rostetter Key fingerprint = E4E7 E674 2BCA 14CC 54CF 13C9 E236 516E 49C7 A0F2 sub 1024g/BBFD8C0C 2004-02-06 -- Eric Rostetter From rostetter at mail.utexas.edu Fri Feb 6 21:41:31 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 6 Feb 2004 15:41:31 -0600 Subject: Regarding QA In-Reply-To: <20040206085345.GK3731@psilocybe.teonanacatl.org> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> <20040206085345.GK3731@psilocybe.teonanacatl.org> Message-ID: <20040206154131.hkki80c4ggscgogs@mail.ph.utexas.edu> Quoting Todd : > For example, say you're going to QA apt (cause everyone wants to), I'd love to (now that I have gpg keys and all). > you'd find it in bugzilla and look at the entries there. You see that > in Jason's latest comment there he's linked these two files: > > https://mail.codegrinder.com/www/apt4/md5sum.asc > > https://mail.codegrinder.com/www/apt4/apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm > > Download them both. Then run rpm --checksig -v (or just -Kv if you're > lazy like me) on the rpm file. Assuming you already have Jason's key > (and you probably don't yet, but we'll get to that later), you should > get output like this: Uhm, but that is a rh73 file, no? What if I want to test it on rh72 or rh8? Is no one working on these? Do I need to create them myself? I find the thread in bugzilla hard to follow myself... I'm not against making apt rh8 rpms, I just not sure if that is what I should be doing or not, etc. It appears slocate has made it to the fedora-testing phase, so I'll see if I can't help QA that at least... -- Eric Rostetter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: PGP Digital Signature URL: From rohwedde at codegrinder.com Fri Feb 6 22:37:35 2004 From: rohwedde at codegrinder.com (Jason) Date: Fri, 6 Feb 2004 16:37:35 -0600 Subject: Regarding QA In-Reply-To: <20040206154131.hkki80c4ggscgogs@mail.ph.utexas.edu> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> <20040206085345.GK3731@psilocybe.teonanacatl.org> <20040206154131.hkki80c4ggscgogs@mail.ph.utexas.edu> Message-ID: <20040206223735.GV2704@codegrinder.com> On Fri, Feb 06, 2004 at 03:41:31PM -0600, Eric Rostetter wrote: > Quoting Todd : > > >For example, say you're going to QA apt (cause everyone wants to), > > I'd love to (now that I have gpg keys and all). sweet. > >you'd find it in bugzilla and look at the entries there. You see that > >in Jason's latest comment there he's linked these two files: > > > > https://mail.codegrinder.com/www/apt4/md5sum.asc > > > >https://mail.codegrinder.com/www/apt4/apt-0.5.15cnc5-0.fdr.7.rh73.legacy.src.rpm > > > >Download them both. Then run rpm --checksig -v (or just -Kv if you're > >lazy like me) on the rpm file. Assuming you already have Jason's key > >(and you probably don't yet, but we'll get to that later), you should > >get output like this: > > Uhm, but that is a rh73 file, no? What if I want to test it on rh72 or > rh8? Is no one working on these? Do I need to create them myself? > I find the thread in bugzilla hard to follow myself... > > I'm not against making apt rh8 rpms, I just not sure if that is what > I should be doing or not, etc. > That src.rpm should build work with rh72,73,80 (and probably 9 whenever we take that over too) Though, if you're building on 8.0, please note what rpm you're building against, since there seems to be some disparity about that lately. I personally support Warren's proposal that if you want to use the legacy tools, you update rpm. -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Feb 7 05:19:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 6 Feb 2004 21:19:33 -0800 Subject: Docs process Message-ID: <200402062119.39883.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Instead of having everbody try to make docs on their own web servers, or send suggested changes back to the website, or get our docs confused with fedora.us's docs, I've installed a wiki system for FedoraLegacy to use. The url is: http://www.fedoralegacy.org/wiki/ The only item there (besides the built in wiki docs) is a quick how-to I wrote up on how to use the wiki. Please let start using the wiki to colaborate on our docs before pushing them to the website. Those of you with current pages that you'd like to see on our site, please drop them into the wiki and ping the list, we'll take a look and make changes as necessary. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJHVq4v2HLvE71NURAtzEAJ4koKWVOxq77sZ8hWEgU6FHBGh+EACeLKme P/l67kep2oBL3wKiUJIF0xM= =C4o3 -----END PGP SIGNATURE----- From sheltren at cs.ucsb.edu Sat Feb 7 15:41:01 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 07 Feb 2004 07:41:01 -0800 Subject: Docs process In-Reply-To: <200402062119.39883.jkeating@j2solutions.net> References: <200402062119.39883.jkeating@j2solutions.net> Message-ID: <1076168453.3188.7.camel@avalanche> Thanks Jesse - I guess I wasn't the only one who was getting a bit confused with all these things floating around on different servers... -Jeff On Fri, 2004-02-06 at 21:19, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Instead of having everbody try to make docs on their own web servers, or > send suggested changes back to the website, or get our docs confused with > fedora.us's docs, I've installed a wiki system for FedoraLegacy to use. > > The url is: > > http://www.fedoralegacy.org/wiki/ > > The only item there (besides the built in wiki docs) is a quick how-to I > wrote up on how to use the wiki. Please let start using the wiki to > colaborate on our docs before pushing them to the website. > > Those of you with current pages that you'd like to see on our site, please > drop them into the wiki and ping the list, we'll take a look and make > changes as necessary. > > - -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAJHVq4v2HLvE71NURAtzEAJ4koKWVOxq77sZ8hWEgU6FHBGh+EACeLKme > P/l67kep2oBL3wKiUJIF0xM= > =C4o3 > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Sun Feb 8 04:49:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 7 Feb 2004 20:49:22 -0800 Subject: New Doc Review Request Message-ID: <200402072049.23142.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have created a new document in our wiki system: "RPM Versioning". This document covers the naming scheme to use when creating legacy packages. Please review and comment/change as necessary. Thanks! - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJb/S4v2HLvE71NURAnZrAKCdaI0aP4rnWyEJA9hXohZ1jlskVQCZAbIw VcJYH28ZSJSEB+RxqHb9vaU= =IBBe -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sun Feb 8 22:17:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 8 Feb 2004 14:17:00 -0800 Subject: Please QA libtool Message-ID: <200402081417.01292.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've created packages for libtool that need QA. https://bugzilla.fedora.us/show_bug.cgi?id=1268 - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJrVc4v2HLvE71NURAq9IAJ4hFEx7USfGs5YqNYuNdcwwzwaloQCgrgPF LEYQyiIHmyxPczWArkTnb7M= =zYBE -----END PGP SIGNATURE----- From ow.mun.heng at wdc.com Mon Feb 9 02:48:14 2004 From: ow.mun.heng at wdc.com (Ow Mun Heng) Date: Mon, 9 Feb 2004 10:48:14 +0800 Subject: How to do QA Message-ID: > -----Original Message----- > From: Eric Rostetter [mailto:rostetter at mail.utexas.edu] > > Quoting Michael Schwendt : > > > At this time, however, I'd like to avoid that > > the "QA hurdle" is set too high or that it is considered > as set too > > high. > > Right now the hurdle is set too high. The hurdle is people don't know > what to do. The result is they do nothing. Anything to help people > get involved can only be a Good Thing. I agree.. I want to help out.. But not knowing how or what is already an obstable in getting my foot in the door. From cra at WPI.EDU Mon Feb 9 05:16:44 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 00:16:44 -0500 Subject: How to do QA In-Reply-To: <20040206004516.mc84440kwscgkk40@mail.ph.utexas.edu> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040206004516.mc84440kwscgkk40@mail.ph.utexas.edu> Message-ID: <20040209051644.GA20831@angus.ind.WPI.EDU> On Fri, Feb 06, 2004 at 12:45:16AM -0600, Eric Rostetter wrote: > Great, but which ones? Please review my page at > > http://rashi.ph.utexas.edu/docs/QA.php > > and let me know what *doesn't* belong (as well as anything you think needs > to be added, if anything). This is incorrect: "Be sure to increment the epoch number before building the new SRPMS." Epoch should never be incremented unless absolutely necessary. What should be incremented is the release number. From cra at WPI.EDU Mon Feb 9 05:38:53 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 00:38:53 -0500 Subject: How to do QA In-Reply-To: <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> Message-ID: <20040209053853.GB20831@angus.ind.WPI.EDU> On Fri, Feb 06, 2004 at 07:01:53AM +0100, Michael Schwendt wrote: > checks), meeting the requirements of a build system (=> completing the > build dependencies). However, Fedora Legacy aims at modifying the source > rpms as little as necessary, so reviewers don't generally need to spend > any time reading the spec file beyond the diff against the previous > release. It has been stated before that Red Hat's build system is different than fedora.us and fedoralegacy, and not as strict w.r.t. BuildRequires. As a result, many Red Hat packages that we me provide updates to do not have a proper set of BuildRequires: and hence may fail to build on our buildsystem. Therefore, the BuildRequires: checks are something that should really stay on the QA checklist. Additionally the ldd checks are an extremely good idea to make sure a missing BuildRequire isn't causing the resulting binary to miss some features silently. I believe it would be good to add some canned set of commands to help QA testers verify these types of things. For example, these can be used on the old and new source and binary RPM's to see what changed: rpm -qpl redhat-package.rpm > redhat-package rpm -qpl redhat-package-update.rpm > redhat-package-update diff -u redhat-package redhat-package-update Perhaps a similar, but slightly more complicated script could be devised to do ldd checks. > checklist don't apply at all to Fedora Legacy. I feel that starting with > this list as a basis is approaching the "QA problem" from the wrong > direction. Start at the top and refine the procedures and policies. I disagree that starting with this list is a bad idea. Sure, many of the things can be removed, but many of them are also trivial. These policies have been refined over time and it would be a shame to ignore them and start from scratch. From drees at greenhydrant.com Mon Feb 9 05:52:57 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 08 Feb 2004 21:52:57 -0800 Subject: How to do QA In-Reply-To: <20040209053853.GB20831@angus.ind.WPI.EDU> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> Message-ID: <40272039.5040404@greenhydrant.com> Charles R. Anderson wrote, On 2/8/2004 9:38 PM: > Perhaps a similar, but slightly more complicated script could be > devised to do ldd checks. I've been using alien to convert the packages to tarballs, unpacking the last release and the update release into separate directories and then check the ldd output. This could be scripted, but would require QA people to install alien. -Dave From cra at WPI.EDU Mon Feb 9 05:57:59 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 00:57:59 -0500 Subject: How to do QA In-Reply-To: <1076030058.3582.308.camel@leonardo> References: <1076030058.3582.308.camel@leonardo> Message-ID: <20040209055759.GC20831@angus.ind.WPI.EDU> On Fri, Feb 06, 2004 at 02:14:19AM +0100, Jonas Pasche wrote: > http://jonaspasche.de/fedoralegacy/qa-howto.html 1. can be removed. 2. should be kept. 3. is tricky. It shouldn't need to be checked unless we are fixing a Red Hat spec file problem. If the update is purely for security patches/upstream source upgrade, then %pre/%post should rarely be affected by these types of changes. 4. I think this can be removed entirely, since in our domain all packages are updates to Red Hat packages. 5. is important since our buildsystem requires that all BuildRequires: be stated explicitly. 6. - 11. are unimportant for legacy updates. They are pedantic spec file policies that, while a very good idea for new packages, have little relevance to our project goals. Again, this depends on whether the update is strictly fixing upstream sources, or the spec file itself. Patches to upstream sources should modify the spec file as little as needed. 12. - 13. are good things to check, but changes to 13. should be discussed with the community first. Making a package run as a different user (or in a chroot for example) is a major change to how a package functions. It may be necessary to do this to provide a security update to a package, however. 14. doesn't really matter. 15. is very important IMO. If these types of checks are not done, then an update could be missing large parts of its functionality when combined with undetected missing BuildRequires. Since our buildsystem doesn't install everything at build time (unlike Red Hat's) this is a real concern for us. From cra at WPI.EDU Mon Feb 9 06:00:17 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 01:00:17 -0500 Subject: How to do QA In-Reply-To: <40272039.5040404@greenhydrant.com> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> <40272039.5040404@greenhydrant.com> Message-ID: <20040209060017.GD20831@angus.ind.WPI.EDU> On Sun, Feb 08, 2004 at 09:52:57PM -0800, David Rees wrote: > I've been using alien to convert the packages to tarballs, unpacking the > last release and the update release into separate directories and then > check the ldd output. This could be scripted, but would require QA > people to install alien. alien isn't necessary. Use rpm2cpio, which comes with rpm: rpm2cpio file.rpm | cpio -idv - From Freedom_Lover at pobox.com Mon Feb 9 06:17:09 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 9 Feb 2004 01:17:09 -0500 Subject: How to do QA In-Reply-To: <20040209060017.GD20831@angus.ind.WPI.EDU> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> <40272039.5040404@greenhydrant.com> <20040209060017.GD20831@angus.ind.WPI.EDU> Message-ID: <20040209061709.GL3731@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles R. Anderson wrote: > On Sun, Feb 08, 2004 at 09:52:57PM -0800, David Rees wrote: >> I've been using alien to convert the packages to tarballs, unpacking the >> last release and the update release into separate directories and then >> check the ldd output. This could be scripted, but would require QA >> people to install alien. > > alien isn't necessary. Use rpm2cpio, which comes with rpm: > > rpm2cpio file.rpm | cpio -idv - Or, since there are always many ways to do something, part of the fedora-rpmdevtools package (that could use updating for 7x) is the fedora-unrpm script. It's quite handy. Since it's pretty short, I'll include it here for anyone that wants it. #!/bin/sh # # fedora-unrpm # Extract RPMs into PWD, "tar zxvf"-style # # Author: Ville Skytt?? # License: GPL # $Id: fedora-unrpm,v 1.2 2003/08/15 20:25:45 scop Exp $ usage() { echo "Usage: `basename $0` RPMFILE..." } extract() { name=$(rpm -qp --qf "%{NAME}-%{VERSION}-%{RELEASE}" "$1") if [ $? -ne 0 -o -z "$name" ]; then echo "Warning: can't extract $name" return 1 fi # Is it an absolute filename? absname="$1" if ! echo "$1" | grep -q "^/" -; then absname="$PWD/$1" fi (mkdir -p "$name" && \ cd "$name" && \ rpm2cpio "$absname" \ | cpio --quiet -ivdum 2>&1 \ | sed "s|^\(\./\)\?|$name/|" && \ cd ..) } if [ -z "$*" ]; then usage exit 1 fi for file in $*; do extract "$file" done - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Cogito cogito ergo cogito sum -- I think that I think, therefore I think that I am. -- Ambrose Bierce, "The Devil's Dictionary" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAJyXkuv+09NZUB1oRAmNrAKDhm8pqzOneolqBp5PN9q+QtLpVGgCghhCO vpLZj1v+suQ4yoEql7v1KSI= =gdAg -----END PGP SIGNATURE----- From drees at greenhydrant.com Mon Feb 9 06:36:51 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 08 Feb 2004 22:36:51 -0800 Subject: How to do QA In-Reply-To: <20040209060017.GD20831@angus.ind.WPI.EDU> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> <40272039.5040404@greenhydrant.com> <20040209060017.GD20831@angus.ind.WPI.EDU> Message-ID: <40272A83.5020808@greenhydrant.com> Charles R. Anderson wrote, On 2/8/2004 10:00 PM: > On Sun, Feb 08, 2004 at 09:52:57PM -0800, David Rees wrote: >>I've been using alien to convert the packages to tarballs, unpacking the >>last release and the update release into separate directories and then >>check the ldd output. This could be scripted, but would require QA >>people to install alien. > > alien isn't necessary. Use rpm2cpio, which comes with rpm: > > rpm2cpio file.rpm | cpio -idv - Thanks for the tip! -Dave From ms-nospam-0306 at arcor.de Mon Feb 9 07:25:21 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 9 Feb 2004 08:25:21 +0100 Subject: How to do QA In-Reply-To: <20040209053853.GB20831@angus.ind.WPI.EDU> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> Message-ID: <20040209082521.5c4f3a7d.ms-nospam-0306@arcor.de> On Mon, 9 Feb 2004 00:38:53 -0500, Charles R. Anderson wrote: > I believe it would be good to add some canned set of commands to help > QA testers verify these types of things. For example, these can be > used on the old and new source and binary RPM's to see what changed: > > rpm -qpl redhat-package.rpm > redhat-package > rpm -qpl redhat-package-update.rpm > redhat-package-update > diff -u redhat-package redhat-package-update Be sure to use -qplv, so you get to see file permissions, ownerships and sizes. > > checklist don't apply at all to Fedora Legacy. I feel that starting with > > this list as a basis is approaching the "QA problem" from the wrong > > direction. Start at the top and refine the procedures and policies. > > I disagree that starting with this list is a bad idea. Sure, many of > the things can be removed, but many of them are also trivial. These > policies have been refined over time and it would be a shame to ignore > them and start from scratch. Let's see: 1. does not apply (short: DNA) 2. DNA / a diff against previous src.rpm content should be done 3. DNA 4. DNA 5. yes, necessary for the build system 6. DNA 7. DNA / not needed to "improve" old packages 8. DNA 9. DNA 10. DNA / completely unimportant for old package updates 11. for upgrades this would make rpmlint happy, nothing else 12. DNA for ordinary patch-work 13. DNA -"- 14. DNA / I wouldn't touch it in updates to old packages because SMP make flags can break the build -- From cra at WPI.EDU Mon Feb 9 07:34:15 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 02:34:15 -0500 Subject: New Doc Review Request In-Reply-To: <200402072049.23142.jkeating@j2solutions.net> References: <200402072049.23142.jkeating@j2solutions.net> Message-ID: <20040209073415.GF20831@angus.ind.WPI.EDU> On Sat, Feb 07, 2004 at 08:49:22PM -0800, Jesse Keating wrote: > I have created a new document in our wiki system: "RPM Versioning". This > document covers the naming scheme to use when creating legacy packages. > Please review and comment/change as necessary. Thanks! Sometimes during the QA/testing process, it is necessary to roll updated packages multiple times to fix minor issues. For the conflict resolution across distros case, it might be a good idea to specify a minor release number so that as an update goes through revisions one doesn't have to keep rechecking the entire distro universe. Using your example: Red Hat Linux 7.2 xsane-0.82-3.1.i386.rpm -> xsane-0.82-4.legacy.i386.rpm Red Hat Linux 7.3 xsane-0.84-2.i386.rpm -> xsane-0.84-9.legacy.i386.rpm Red Hat Linux 8.0 xsane-0.84-8.i386.rpm -> xsane-0.84-10.legacy.i386.rpm Red Hat Linux 9 xsane-0.89-3.i386.rpm -> xsane-0.89-4.legacy.i386.rpm would become: Red Hat Linux 7.2 xsane-0.82-3.1.i386.rpm -> xsane-0.82-4.0.legacy.i386.rpm Red Hat Linux 7.3 xsane-0.84-2.i386.rpm -> xsane-0.84-9.0.legacy.i386.rpm Red Hat Linux 8.0 xsane-0.84-8.i386.rpm -> xsane-0.84-10.0.legacy.i386.rpm Red Hat Linux 9 xsane-0.89-3.i386.rpm -> xsane-0.89-4.0.legacy.i386.rpm and the .0 could be incremented for each iteration of an update undergoing QA/testing. This would also help reduce "release inflation" that might interfere with a future FC package's release number that is as yet unknown (unless Red Hat will be checking FedoraLegacy before coming up with new release numbers for future FC packages?). Come to think of it, why can't we just use the incremented minor number always with the same major release number as the existing RH/FC package? Even if the existing release number has multiple components separated with periods, can we not just add a .1 after all that and keep incrementing that number for each legacy release? From cra at WPI.EDU Mon Feb 9 07:51:02 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 9 Feb 2004 02:51:02 -0500 Subject: How to do QA In-Reply-To: <20040209082521.5c4f3a7d.ms-nospam-0306@arcor.de> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> <20040209082521.5c4f3a7d.ms-nospam-0306@arcor.de> Message-ID: <20040209075102.GG20831@angus.ind.WPI.EDU> On Mon, Feb 09, 2004 at 08:25:21AM +0100, Michael Schwendt wrote: > Be sure to use -qplv, so you get to see file permissions, ownerships and > sizes. Except dates and times will always change, so the case without -v is nice to see too, so you only see missing/new files/paths in the diff output. This might be a nice alternative, for comparing everything but the timestamps and file sizes of the binary rpms: rpm -qplv file.rpm | awk '{print $1,$2,$3,$4,$8,$9}' > 1. does not apply (short: DNA) > 2. DNA / a diff against previous src.rpm content should be done > 3. DNA > 4. DNA > 5. yes, necessary for the build system > 6. DNA > 7. DNA / not needed to "improve" old packages > 8. DNA > 9. DNA > 10. DNA / completely unimportant for old package updates > 11. for upgrades this would make rpmlint happy, nothing else > 12. DNA for ordinary patch-work > 13. DNA -"- > 14. DNA / I wouldn't touch it in updates to old packages > because SMP make flags can break the build Agreed, with the addition of 15. ldd comparisons. A tool could be written to perform the file and ldd diffs. The output could be similar to rpm -V output (size, MD5 sum, permissions, type, owner, group, timestamp) plus ldd/Requires diffs. From ms-nospam-0306 at arcor.de Mon Feb 9 15:10:34 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 9 Feb 2004 16:10:34 +0100 Subject: How to do QA In-Reply-To: <20040209075102.GG20831@angus.ind.WPI.EDU> References: <1076030058.3582.308.camel@leonardo> <20040206070153.6fb2ae9d.ms-nospam-0306@arcor.de> <20040209053853.GB20831@angus.ind.WPI.EDU> <20040209082521.5c4f3a7d.ms-nospam-0306@arcor.de> <20040209075102.GG20831@angus.ind.WPI.EDU> Message-ID: <20040209161034.546256cf.ms-nospam-0306@arcor.de> On Mon, 9 Feb 2004 02:51:02 -0500, Charles R. Anderson wrote: > > Be sure to use -qplv, so you get to see file permissions, ownerships and > > sizes. > > Except dates and times will always change, so the case without -v is > nice to see too, so you only see missing/new files/paths in the diff > output. > > This might be a nice alternative, for comparing everything but the > timestamps and file sizes of the binary rpms: > > rpm -qplv file.rpm | awk '{print $1,$2,$3,$4,$8,$9}' Of course. I have a similar one in my .bashrc for ages, which keeps -p optional, uses printf for improved readability and. Only minor differences. And a non-verbose version: $ rpmls m4 -rwxr-xr-x /usr/bin/m4 drwxr-xr-x /usr/share/doc/m4-1.4.1 -rw-r--r-- /usr/share/doc/m4-1.4.1/NEWS -rw-r--r-- /usr/share/doc/m4-1.4.1/README -rw-r--r-- /usr/share/info/m4.info-1.gz -rw-r--r-- /usr/share/info/m4.info-2.gz -rw-r--r-- /usr/share/info/m4.info-3.gz -rw-r--r-- /usr/share/info/m4.info.gz -rw-r--r-- /usr/share/locale/fr/m4.msg -- From ms-nospam-0306 at arcor.de Mon Feb 9 15:29:02 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 9 Feb 2004 16:29:02 +0100 Subject: New Doc Review Request In-Reply-To: <20040209073415.GF20831@angus.ind.WPI.EDU> References: <200402072049.23142.jkeating@j2solutions.net> <20040209073415.GF20831@angus.ind.WPI.EDU> Message-ID: <20040209162902.287cf147.ms-nospam-0306@arcor.de> On Mon, 9 Feb 2004 02:34:15 -0500, Charles R. Anderson wrote: > Come to think of it, why can't we just use the incremented minor > number always with the same major release number as the existing RH/FC > package? Even if the existing release number has multiple components > separated with periods, can we not just add a .1 after all that and > keep incrementing that number for each legacy release? You could add a right-most number to %release and increase that one only. But when an update is based on the most recent package revision, e.g. foo-1.0-3 is latest for rh73, foo-1.0-8 is the further developed package for rh80 which includes a few additional bug-fixes, one can base the update for rh73 on the most recent package and add a distribution specific %release postfix, e.g. foo-1.0-9.0.7.2 for rh72 foo-1.0-9.0.7.3 for rh73 foo-1.0-9.0.8 for rh80 (whether you add .0.x.y or just .x, is just for clearness). If one prefers incrementing %release strictly and keeping it short, foo-1.0-9 for rh72 foo-1.0-10 for rh73 foo-1.0-11 for rh80 doesn't really matter, other than that it pushes up the release number more quickly and you need to keep track of any changes inside the packages with a differing major %release number. -- From jkeating at j2solutions.net Mon Feb 9 16:19:39 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 9 Feb 2004 08:19:39 -0800 Subject: New Doc Review Request In-Reply-To: <20040209073415.GF20831@angus.ind.WPI.EDU> References: <200402072049.23142.jkeating@j2solutions.net> <20040209073415.GF20831@angus.ind.WPI.EDU> Message-ID: <200402090819.40480.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 08 February 2004 23:34, Charles R. Anderson wrote: > and the .0 could be incremented for each iteration of an update > undergoing QA/testing. This would also help reduce "release > inflation" that might interfere with a future FC package's release > number that is as yet unknown (unless Red Hat will be checking > FedoraLegacy before coming up with new release numbers for future FC > packages?). There is work being done inside Red Hat to start using a package naming scheme that won't conflict with folks like us. Basically it sounds like they'll start using a distro release tag. > Come to think of it, why can't we just use the incremented minor > number always with the same major release number as the existing RH/FC > package? Even if the existing release number has multiple components > separated with periods, can we not just add a .1 after all that and > keep incrementing that number for each legacy release? I'm not sure I follow what you're saying here. Regardless, I've added a new section to the doc, called Build Updates. Please review. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJ7Mb4v2HLvE71NURAkXpAJ9HzBNs3bCAX4kkxatVA970hxwp5QCfbpio wGIyNFcAsaj3ioAUTglXBek= =ZLAM -----END PGP SIGNATURE----- From jimpop at yahoo.com Tue Feb 10 06:05:44 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 10 Feb 2004 01:05:44 -0500 Subject: Donations Message-ID: <1076393144.6964.2.camel@bluetoo> Is there a way to donate $$ to the Fedora Legacy Project? PayPal please. I am a former RHN user and would gladly be willing to donate the equivalent amount to FLP for their efforts in assisting the Linux community. Thank you, -Jim P. From mccabemt at clarkson.edu Tue Feb 10 18:57:11 2004 From: mccabemt at clarkson.edu (Mike Mccabe) Date: Tue, 10 Feb 2004 13:57:11 -0500 Subject: Participating Message-ID: <1076439430.5155.6.camel@workstation> Hello I'm interested in participating in the Fedora Legacy Project as a Test RPM Packager. I've been using Redhat since 1998 and have some experience building my own RPMS. I'd like to help because I have a couple of boxes that are running Fedora Core 1 and I know I won't want to upgrade them to Fedora Core 2. I've read over the package versioning guidelines and would like to get started. In the future I'd be interested in becoming a vulnerability analyst and patch creator but I don't have the time right now. Thanks Mike McCabe -- Michael McCabe Z Server Team Leader Clarkson Open Source Institute From rostetter at mail.utexas.edu Tue Feb 10 21:46:47 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 10 Feb 2004 15:46:47 -0600 Subject: Participating In-Reply-To: <1076439430.5155.6.camel@workstation> References: <1076439430.5155.6.camel@workstation> Message-ID: <20040210154647.s42cgkw0gc008oko@mail.ph.utexas.edu> Quoting Mike Mccabe : > I'm interested in participating in the Fedora Legacy Project as a Test > RPM Packager. If you have access to a RHL 7.2, 7.3, or 8.0 box, we need someone to build/test the apt rpms for those versions. The 7.3 one is built and seems to work. At least two of use reported it won't build for us on 7.2, I don't know if anyone has tried 8.0 yet (though I plan to). It would be great if you could help with any of these, as apt really needs someone to build and QA test it. Keep in mind, you can use a real RHL system, or a virutal one if need be (user land linux, vmware, etc) > Thanks > Mike McCabe > -- > Michael McCabe > Z Server Team Leader > Clarkson Open Source Institute > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Eric Rostetter From villegas at math.gatech.edu Tue Feb 10 22:31:28 2004 From: villegas at math.gatech.edu (Carlos Villegas) Date: Tue, 10 Feb 2004 17:31:28 -0500 Subject: Regarding QA In-Reply-To: <20040206085345.GK3731@psilocybe.teonanacatl.org> References: <1076021717.3582.243.camel@leonardo> <200402051508.07233.jkeating@j2solutions.net> <20040205202305.woxa7c4ssscwgskg@mail.ph.utexas.edu> <200402052233.31190.jkeating@j2solutions.net> <20040206010200.asw4k40o00ockwgg@mail.ph.utexas.edu> <20040206085345.GK3731@psilocybe.teonanacatl.org> Message-ID: <20040210223128.GC26913@hemi.math.gatech.edu> On Fri, Feb 06, 2004 at 03:53:45AM -0500, Todd wrote: > > The gpg check is the one I prefer to use. The Fedora.us wiki's > suggest gpg signed md5 hash files to go along with the uploaded > packages and most of the packages submitted so far for FL have done > this, though I have to wonder what the point is. If you check the gpg > signature of the md5 file and then use the md5 file to check the > packages, you might as well just use gpg to check the packages > directly. (Hope that didn't leave you more confused than you were > before.) There is a good reason to use gpg signed md5's, and it is that as it is clear, some people don't know gpg, but are capable of verifying an md5 sum. So if you know gpg you can get the md5 and check the gpg, if you don't you can at least compare the md5 (clearly not very secure, but at least something). Carlos PS: Sorry I entered so late to this thread, I'm behind on mail reading... From mccabemt at clarkson.edu Tue Feb 10 22:54:20 2004 From: mccabemt at clarkson.edu (Michael T McCabe) Date: Tue, 10 Feb 2004 17:54:20 -0500 Subject: Participating In-Reply-To: <20040210154647.s42cgkw0gc008oko@mail.ph.utexas.edu> References: <1076439430.5155.6.camel@workstation> <20040210154647.s42cgkw0gc008oko@mail.ph.utexas.edu> Message-ID: <1076453659.2646.0.camel@localhost> I'll start workig on apt for Redhat 7.2. On Tue, 2004-02-10 at 16:46, Eric Rostetter wrote: > Quoting Mike Mccabe : > > > I'm interested in participating in the Fedora Legacy Project as a Test > > RPM Packager. > > If you have access to a RHL 7.2, 7.3, or 8.0 box, we need someone to > build/test the apt rpms for those versions. The 7.3 one is built and > seems to work. At least two of use reported it won't build for us on > 7.2, I don't know if anyone has tried 8.0 yet (though I plan to). > > It would be great if you could help with any of these, as apt really needs > someone to build and QA test it. > > Keep in mind, you can use a real RHL system, or a virutal one if need > be (user land linux, vmware, etc) > > > Thanks > > Mike McCabe > > -- > > Michael McCabe > > Z Server Team Leader > > Clarkson Open Source Institute > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From rostetter at mail.utexas.edu Tue Feb 10 22:57:06 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 10 Feb 2004 16:57:06 -0600 Subject: Participating In-Reply-To: <1076453659.2646.0.camel@localhost> References: <1076439430.5155.6.camel@workstation> <20040210154647.s42cgkw0gc008oko@mail.ph.utexas.edu> <1076453659.2646.0.camel@localhost> Message-ID: <20040210165706.umnpc88co88ww484@mail.ph.utexas.edu> Quoting Michael T McCabe : > I'll start workig on apt for Redhat 7.2. Great! Thanks! -- Eric Rostetter From green at r8.dion.ne.jp Wed Feb 11 12:42:19 2004 From: green at r8.dion.ne.jp (Green) Date: Wed, 11 Feb 2004 21:42:19 +0900 Subject: Donations In-Reply-To: <20040210170004.13511.60819.Mailman@listman.back-rdu.redhat.com> References: <20040210170004.13511.60819.Mailman@listman.back-rdu.redhat.com> Message-ID: <20040211214219.4406c734.green@r8.dion.ne.jp> > Is there a way to donate $$ to the Fedora Legacy Project? PayPal > please. I am a former RHN user and would gladly be willing to donate > the equivalent amount to FLP for their efforts in assisting the Linux > community. For your information, There was an announcement at fedora.us before like this: http://videl.ics.hawaii.edu/pipermail/hosef-announce/2003q3/000015.html Green. From jkeating at j2solutions.net Wed Feb 11 16:10:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 08:10:18 -0800 Subject: Donations In-Reply-To: <20040211214219.4406c734.green@r8.dion.ne.jp> References: <20040210170004.13511.60819.Mailman@listman.back-rdu.redhat.com> <20040211214219.4406c734.green@r8.dion.ne.jp> Message-ID: <200402110810.23732.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 February 2004 04:42, Green wrote: > For your information, > There was an announcement at fedora.us before like this: > > http://videl.ics.hawaii.edu/pipermail/hosef-announce/2003q3/000015.html Fedora Legacy is not a direct member of the Hawaii Open Source Education Foundation. I have replied in private to the requesting individual. While I had hoped to not need any donations, we have a real need for a dedicated master mirror system. We have rackspace, bandwidth, and system monitoring donated to us for this system, and possibly some hardware, but we're still in need of a chassis and some other stuff. I am not asking for any money donations, I am trying to fulfill the needs with my own resources and/or physical donations. I still have not exercised all my options on this issue. I'll notify the list if it is impossible for me to fulfill this requirement on my own. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKlPu4v2HLvE71NURAmpbAJ9fFxYKtRc4J0yJAtBEuy7MXkTXdQCeOT16 aS5xYoJt+VDzi1AGTimgdqI= =8VZX -----END PGP SIGNATURE----- From mclewley at ghsinc.com Wed Feb 11 21:27:07 2004 From: mclewley at ghsinc.com (Mike Clewley) Date: Wed, 11 Feb 2004 16:27:07 -0500 Subject: FTP site for mirror? Message-ID: <1076534827.5782.16.camel@mclewley.ghsinc.com> I'm just looking for an ftp site for mirroring. My mirror perl program only supports ftp for file stat reasons (I guess). I get a 550 login incorrect when attempting anonymous login to ftp://downloads.fedoralegacy.org. Is that site being worked on? Will there be anonymous ftp access in the future? TIA, -mike -- Michael Clewley < mclewley at ghsinc dot com > Network Engineer, GHS Data Management Inc. 800.609.7893 x.167 http://www.ghsinc.com/ Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) or their authorized representatives only, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From jkeating at j2solutions.net Wed Feb 11 22:18:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 14:18:11 -0800 Subject: FTP site for mirror? In-Reply-To: <1076534827.5782.16.camel@mclewley.ghsinc.com> References: <1076534827.5782.16.camel@mclewley.ghsinc.com> Message-ID: <200402111418.28758.jkeating@j2solutions.net> On Wednesday 11 February 2004 13:27, Mike Clewley wrote: > I'm just looking for an ftp site for mirroring. My mirror perl > program only supports ftp for file stat reasons (I guess). I get a > 550 login incorrect when attempting anonymous login to > ftp://downloads.fedoralegacy.org. > > Is that site being worked on? Will there be anonymous ftp access in > the future? Currently there is no ftp in my site, only http/rsync. I'm building a system that will serve as the perm. master mirror, and it will support anon ftp. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dawson at fnal.gov Wed Feb 11 23:05:35 2004 From: dawson at fnal.gov (Troy Dawson) Date: Wed, 11 Feb 2004 17:05:35 -0600 Subject: FTP site for mirror? In-Reply-To: <200402111418.28758.jkeating@j2solutions.net> References: <1076534827.5782.16.camel@mclewley.ghsinc.com> <200402111418.28758.jkeating@j2solutions.net> Message-ID: <402AB53F.3060109@fnal.gov> I am currently rsyncing the site on a nightly basis. If you wish, until he get's the main stuff going you can do anonymous ftp from ftp://linux21.fnal.gov/linux/legacy/ Troy Jesse Keating wrote: > On Wednesday 11 February 2004 13:27, Mike Clewley wrote: > >>I'm just looking for an ftp site for mirroring. My mirror perl >>program only supports ftp for file stat reasons (I guess). I get a >>550 login incorrect when attempting anonymous login to >>ftp://downloads.fedoralegacy.org. >> >>Is that site being worked on? Will there be anonymous ftp access in >>the future? > > > Currently there is no ftp in my site, only http/rsync. I'm building a > system that will serve as the perm. master mirror, and it will support > anon ftp. > From rostetter at mail.utexas.edu Wed Feb 11 23:08:55 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 11 Feb 2004 17:08:55 -0600 Subject: FTP site for mirror? In-Reply-To: <402AB53F.3060109@fnal.gov> References: <1076534827.5782.16.camel@mclewley.ghsinc.com> <200402111418.28758.jkeating@j2solutions.net> <402AB53F.3060109@fnal.gov> Message-ID: <20040211170855.11kyfuso4804cwsc@mail.ph.utexas.edu> Quoting Troy Dawson : > I am currently rsyncing the site on a nightly basis. If you wish, until > he get's the main stuff going you can do anonymous ftp from > > ftp://linux21.fnal.gov/linux/legacy/ > > Troy Thanks Troy! Jesse Keating: What's the status of getting a list of mirrors for the web site??? *poke* *prod* -- Eric Rostetter From jkeating at j2solutions.net Wed Feb 11 23:10:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 15:10:41 -0800 Subject: FTP site for mirror? In-Reply-To: <20040211170855.11kyfuso4804cwsc@mail.ph.utexas.edu> References: <1076534827.5782.16.camel@mclewley.ghsinc.com> <402AB53F.3060109@fnal.gov> <20040211170855.11kyfuso4804cwsc@mail.ph.utexas.edu> Message-ID: <200402111510.46343.jkeating@j2solutions.net> On Wednesday 11 February 2004 15:08, Eric Rostetter wrote: > Jesse Keating: What's the status of getting a list of mirrors for the > web site??? *poke* *prod* Scheduled for tonight. My first free time in a while ): -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 07:11:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 23:11:46 -0800 Subject: Fedora Legacy Test Update Notification: util-linux Message-ID: <200402112311.47230.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1256 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1256 2004-02-11 - --------------------------------------------------------------------- Name : util-linux Version : 2.11f Release : 19.7.2.legacy Summary : A collection of basic system utilities. Description : The util-linux package contains a large variety of low-level system utilities that are necessary for a Linux system to function. Among others, Util-linux contains the fdisk configuration tool and the login program. - --------------------------------------------------------------------- Update Information: CAN-2004-0080: In some situations, the login program could use a pointer that had been freed and reallocated. This could cause unintentional data leakage. This only effects util-linux in Red Hat Linux 7.2 - --------------------------------------------------------------------- Changelog: * Tue Feb 03 2004 Jesse Keating - - bumped to 2.11f-18.7.2.legacy for fixing util-linux-2.11f-pwent2.patch part of CAN-2004-0080 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 26d4c12f4942e59a24c858b06271cc66528c1258 7.2/updates/SRPMS/util-linux-2.11f-19.7.2.legacy.src.rpm de5fb4026cab54e697abd908e5e01d3352c515b6 7.2/updates/i386/util-linux-2.11f-19.7.2.legacy.i386.rpm - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKycy4v2HLvE71NURAlPXAJ9yMR3cDbye9s28EJKktW2IlXWe8wCdEd67 h5KlXVjRfD7PtbCrpEmRDUQ= =eGsk -----END PGP SIGNATURE----- From james-cambs-uk at bigfoot.com Thu Feb 12 10:57:09 2004 From: james-cambs-uk at bigfoot.com (james-cambs-uk (Bigfoot)) Date: Thu, 12 Feb 2004 10:57:09 +0000 Subject: http listing options In-Reply-To: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> <200401202204.32436.jkeating@j2solutions.net> <400E5249.3000403@togami.com> <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> Message-ID: <402B5C05.9010806@bigfoot.com> Date: Thu, 29 Jan 2004 19:47:12 -0600 Eric Rostetter wrote: > Just an FYI, there have neen numerous updates to the web site lately, > so if you haven't checked it out for a while you might want to do so now. > > Extra thanks to Jonas Pasche for his work on the Participation, FAQ, and > Documentation pages (keep it coming Jonas!). > > Comments, suggestions, and content always welcome (sent to me or the mailing > list). For newbies that want all the latest legacy packages at the top of a file list from http access - could you possibly supply an entry page that has the list ordering options as links themselves? Offlist I had made some suggestions about the web presentation of the update packages; my usual procedure for RedHat updates is to use ftp and ls -alqFt to see the updates in cronological order. Much more useful There have been complaints about the incorporation of the "non legacy" updates into one file area, but my discovery today makes the loss of direct anon ftp access not so painful, and those "needle in a haystack" complaints redundant. Now that I have discovered the cronological listing option from http: access I am one happy bunny. Thanks folks! ( Clicking on the column header ). ( Curiousity here - what cgi coding did you do to achieve this? I was expecting to see/need -D / D- to achieve reverse listing order when clicking twice on the heading link in an attempt to "toggle" ordering ) To get things in date order ( say, for RedHat 7.2 legacy ), I have bookmarked in my browser(s): http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/?M=D http://download.fedoralegacy.org/redhat/7.2/updates/i386/?M=D A simple thing to add a bunch of these into top entry pages on the site, in groups of supported DeadRat legacy version numbers... -- James From Bernd.Bartmann at sohanet.de Thu Feb 12 12:25:46 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Thu, 12 Feb 2004 13:25:46 +0100 Subject: slocate Advisory is missing on FL web site Message-ID: <402B70CA.2080000@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the slocate advisory has been released, but it is still missing on the Fedora Legacy advisory web sites: http://www.fedoralegacy.org/updates/RH7.2/ http://www.fedoralegacy.org/updates/RH7.3/ http://www.fedoralegacy.org/updates/RH8.0/ Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAK3DKkQuIaHu84cIRApnJAKCp93FL+BmRZehej4N2l6kEEoVYwQCeKoao id6DoZ60TcwTJpNiQsjWLFs= =QKXF -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 15:56:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 12 Feb 2004 07:56:22 -0800 Subject: slocate Advisory is missing on FL web site In-Reply-To: <402B70CA.2080000@sohanet.de> References: <402B70CA.2080000@sohanet.de> Message-ID: <200402120756.24160.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 February 2004 04:25, Bernd Bartmann wrote: > the slocate advisory has been released, but it is still missing on the > Fedora Legacy advisory web sites: > > http://www.fedoralegacy.org/updates/RH7.2/ > http://www.fedoralegacy.org/updates/RH7.3/ > http://www.fedoralegacy.org/updates/RH8.0/ > > Best regards. Currently this is a manual process, and the website version will lag a bit before being there. In the future it will be more automated. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAK6Im4v2HLvE71NURAp51AJ9xBhzDuKeyMa14ZOghcGfQZphhmwCeNARi FCWVvEtF2mPBytoNSrZgesE= =weHu -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 16:00:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 12 Feb 2004 08:00:41 -0800 Subject: http listing options In-Reply-To: <402B5C05.9010806@bigfoot.com> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <402B5C05.9010806@bigfoot.com> Message-ID: <200402120800.42490.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 February 2004 02:57, james-cambs-uk (Bigfoot) wrote: > Now that I have discovered the cronological listing option from http: > access I am one happy bunny. Thanks folks! ( Clicking on the column > header ). > > ( Curiousity here - what cgi coding did you do to achieve this? I was > expecting to see/need -D / D- to achieve reverse listing order when > clicking twice on the heading link in an attempt to "toggle" ordering ) > > To get things in date order ( say, for RedHat 7.2 legacy ), I have > bookmarked in my browser(s): > > http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/?M=D > http://download.fedoralegacy.org/redhat/7.2/updates/i386/?M=D > > A simple thing to add a bunch of these into top entry pages on the site, > in groups of supported DeadRat legacy version numbers... Heh, it's just apache at work here, no special magic. I'll think about adding your links once we move the files over to their permanent home. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAK6Mp4v2HLvE71NURAiPTAJ9uV7zbhYGKkf2fRiyV+xIizHpuWACeJXt8 IJbRPRmBxC4ucGA9FSQA2TI= =QWo9 -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Thu Feb 12 19:21:21 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 12 Feb 2004 14:21:21 -0500 Subject: PHP bug Message-ID: <402BD231.7080506@ysu.edu> Platform: Cross Platform Title: Apache mod_php Global Variables Information Disclosure Weakness Description: Mod_PHP is an Apache module which allows for PHP functionality in websites. The security flaw is present if the parameter 'register_globals = on' in the php.ini. An attacker may access some sensible information. PHP version 4.3.4 and prior are known to be vulnerable. Ref: http://bugs.php.net/bug.php?id=25753 From rostetter at mail.utexas.edu Thu Feb 12 21:15:10 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 12 Feb 2004 15:15:10 -0600 Subject: slocate Advisory is missing on FL web site In-Reply-To: <402B70CA.2080000@sohanet.de> References: <402B70CA.2080000@sohanet.de> Message-ID: <20040212151510.7qk8rkko04cowk8c@mail.ph.utexas.edu> Quoting Bernd Bartmann : > the slocate advisory has been released, but it is still missing on the > Fedora Legacy advisory web sites: > > http://www.fedoralegacy.org/updates/RH7.2/ > http://www.fedoralegacy.org/updates/RH7.3/ > http://www.fedoralegacy.org/updates/RH8.0/ > > Best regards. Yes, the system is not yet automatted, and I was behind in my email today. As soon as I came on the message, it put it on the web site (about an hour ago). At some point, I hope to subscribe an e-mail address to the announce list which will automate the process, but I'm not that far yet. -- Eric Rostetter From michal at harddata.com Fri Feb 13 18:05:01 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 13 Feb 2004 11:05:01 -0700 Subject: buffer overflows in XFree86 Message-ID: <20040213110501.A29315@mail.harddata.com> Mandrake posted this advisory: http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-2004:012 I did not add that to bugzilla, as this is not confirmed yet, but versions affected are those which are used in "Legacy distros" so it is not very likely that they are ok. Michal From skvidal at phy.duke.edu Fri Feb 13 18:11:56 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 13 Feb 2004 13:11:56 -0500 Subject: buffer overflows in XFree86 In-Reply-To: <20040213110501.A29315@mail.harddata.com> References: <20040213110501.A29315@mail.harddata.com> Message-ID: <1076695915.11529.2.camel@binkley> On Fri, 2004-02-13 at 11:05 -0700, Michal Jaegermann wrote: > Mandrake posted this advisory: > > http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-2004:012 > > I did not add that to bugzilla, as this is not confirmed yet, > but versions affected are those which are used in "Legacy distros" > so it is not very likely that they are ok. > > Michal It's already in bugzilla. -sv From Freedom_Lover at pobox.com Fri Feb 13 18:50:03 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 13 Feb 2004 13:50:03 -0500 Subject: buffer overflows in XFree86 In-Reply-To: <1076695915.11529.2.camel@binkley> References: <20040213110501.A29315@mail.harddata.com> <1076695915.11529.2.camel@binkley> Message-ID: <20040213185002.GW25704@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: > On Fri, 2004-02-13 at 11:05 -0700, Michal Jaegermann wrote: >> >> Mandrake posted this advisory: >> >> http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-2004:012 >> >> I did not add that to bugzilla, as this is not confirmed yet, >> but versions affected are those which are used in "Legacy distros" >> so it is not very likely that they are ok. [...] > It's already in bugzilla. Indeed, https://bugzilla.fedora.us/show_bug.cgi?id=1289 for anyone that's too busy to look for it and wants the direct link. :) Note 1: John Dalbec already built the packages the other night and was looking to get someone with more webspace that he has available to post them so QA can begin. I haven't seen any comments in bugzilla indicating that he found such a webspace donor, so if you can help, it might be worth posting a comment in that bugzilla entry. Note 2: Since John built these packages, an additional advisory was released and it appears that the Slackware and Mandrake packages incorporate this fix into their (identical) patches as well. So John might need to rebuild the packages before getting them posted and folks can QA them. HTH - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Politics is the conduct of public affairs for private advantage. -- Ambrose Bierce -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFALRxauv+09NZUB1oRArmDAJsHuw6hcSCInHaaHP84FAlufQQDkQCfbkVg BhhfV/8HrRtW7eYo9u8GwgE= =PbnC -----END PGP SIGNATURE----- From michal at harddata.com Fri Feb 13 19:27:56 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 13 Feb 2004 12:27:56 -0700 Subject: buffer overflows in XFree86 In-Reply-To: <1076695915.11529.2.camel@binkley>; from skvidal@phy.duke.edu on Fri, Feb 13, 2004 at 01:11:56PM -0500 References: <20040213110501.A29315@mail.harddata.com> <1076695915.11529.2.camel@binkley> Message-ID: <20040213122756.B31129@mail.harddata.com> On Fri, Feb 13, 2004 at 01:11:56PM -0500, seth vidal wrote: > On Fri, 2004-02-13 at 11:05 -0700, Michal Jaegermann wrote: > > > Mandrake posted this advisory: ... > > It's already in bugzilla. > > -sv Thanks. I always seem to have food-fights with search in bugzilla. Sigh! Michal From Freedom_Lover at pobox.com Fri Feb 13 20:07:19 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 13 Feb 2004 15:07:19 -0500 Subject: buffer overflows in XFree86 In-Reply-To: <20040213122756.B31129@mail.harddata.com> References: <20040213110501.A29315@mail.harddata.com> <1076695915.11529.2.camel@binkley> <20040213122756.B31129@mail.harddata.com> Message-ID: <20040213200718.GY25704@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Jaegermann wrote: > Thanks. I always seem to have food-fights with search in bugzilla. > Sigh! Bookmark this URL: http://www.fedora.us/LEGACY It will let you easily keep track of what needs done for Legacy packages. Hopefully, that list is always small enough that you can grep it visually. :) (This is conveniently linked off the fedoralegacy.org home page as "Legacy Devel Tracker") - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== I got stopped by a cop the other day. He said, "Why'd you run that stop sign?" I said, "Because I don't believe everything I read." -- Stephen Wright -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFALS52uv+09NZUB1oRApq8AJ9h+jASqfPbCDJmE6twAewar5bI0QCg4v2S yU2cZ7KtAsOB1p3/2e8sJ3g= =SpTU -----END PGP SIGNATURE----- From ingo at auroralinux.org Fri Feb 13 20:39:26 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Fri, 13 Feb 2004 21:39:26 +0100 Subject: buffer overflows in XFree86 References: <20040213110501.A29315@mail.harddata.com> Message-ID: <029601c3f271$7c823480$022ca8c0@OPTIMUS> There's most probably no need to build and push this one on rh73. Would save about 100 MBytes RPM+SRPM to download... The buffer overflow is in a path that is NOT built on RH73. This is from the rh73 spec file: ----------- %define RHL_73_build 1 # If RHL_73_build is false above, set RHL_80_build to true %define RHL_80_build !%{RHL_73_build} ... # FIXME We're using the new fontconfig based Xft1 1.2 lib now. %define with_new_fontconfig_Xft %{RHL_80_build} ----------- Ingo From michal at harddata.com Fri Feb 13 20:45:30 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 13 Feb 2004 13:45:30 -0700 Subject: buffer overflows in XFree86 In-Reply-To: <20040213200718.GY25704@psilocybe.teonanacatl.org>; from Freedom_Lover@pobox.com on Fri, Feb 13, 2004 at 03:07:19PM -0500 References: <20040213110501.A29315@mail.harddata.com> <1076695915.11529.2.camel@binkley> <20040213122756.B31129@mail.harddata.com> <20040213200718.GY25704@psilocybe.teonanacatl.org> Message-ID: <20040213134530.A467@mail.harddata.com> On Fri, Feb 13, 2004 at 03:07:19PM -0500, Todd wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michal Jaegermann wrote: > > Thanks. I always seem to have food-fights with search in bugzilla. > > Sigh! > > Bookmark this URL: http://www.fedora.us/LEGACY I have this bookmark for quite a while. I also have a login on bugzilla.fedora.us. It seem to have a mind of its own. Right know, for example, when I tried the above, it showed me 13 entries on the list. But my previous search gave 18 of those. If you _know_ that something you are looking for is actually in bugzilla then chances are pretty good that you will find it. It is another story if you are not sure. Michal From Freedom_Lover at pobox.com Fri Feb 13 21:02:48 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 13 Feb 2004 16:02:48 -0500 Subject: buffer overflows in XFree86 In-Reply-To: <20040213134530.A467@mail.harddata.com> References: <20040213110501.A29315@mail.harddata.com> <1076695915.11529.2.camel@binkley> <20040213122756.B31129@mail.harddata.com> <20040213200718.GY25704@psilocybe.teonanacatl.org> <20040213134530.A467@mail.harddata.com> Message-ID: <20040213210248.GZ25704@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Jaegermann wrote: > On Fri, Feb 13, 2004 at 03:07:19PM -0500, Todd wrote: [...] >> Bookmark this URL: http://www.fedora.us/LEGACY > > I have this bookmark for quite a while. I also have a login > on bugzilla.fedora.us. It seem to have a mind of its own. Hehe, I won't try to argue that bugzilla is the most user-friendly app out there. > Right know, for example, when I tried the above, it showed me 13 > entries on the list. But my previous search gave 18 of those. Might that be because some of the bugs have been closed? slocate is no longer there since it got pushed to updates, for example. > If you _know_ that something you are looking for is actually in > bugzilla then chances are pretty good that you will find it. It is > another story if you are not sure. True. If things are working properly, viewing bugzilla via the URL above should show you the open bugs that need attention. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The evils of tyranny are rarely seen but by him who resists it. -- John Hay, 1872 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFALTt4uv+09NZUB1oRAktoAJ0XMOStszWg0k79TXY3s8OJLyTJBACbBl2T 79L5TQFM8Mi8420Cr9amkgk= =GiUS -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Feb 13 21:35:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 13 Feb 2004 13:35:03 -0800 Subject: buffer overflows in XFree86 In-Reply-To: <20040213134530.A467@mail.harddata.com> References: <20040213110501.A29315@mail.harddata.com> <20040213200718.GY25704@psilocybe.teonanacatl.org> <20040213134530.A467@mail.harddata.com> Message-ID: <200402131335.07800.jkeating@j2solutions.net> On Friday 13 February 2004 12:45, Michal Jaegermann wrote: > I have this bookmark for quite a while. I also have a login > on bugzilla.fedora.us. It seem to have a mind of its own. Right > know, for example, when I tried the above, it showed me 13 entries > on the list. But my previous search gave 18 of those. That URL pulls from the "keywords" of the bug. Once we close a bug, I remove the keyword so that closed bugs will not show up in the list. Also, the active "list" you have in bugzilla will not update itself if you change keywords. You'll have to re-visit the URL to re-run the search. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Feb 13 22:22:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 13 Feb 2004 14:22:35 -0800 Subject: GPG fingerprint for verification Message-ID: <200402131422.41208.jkeating@j2solutions.net> In a bugzilla entry it was requested that I post the Fedora Legacy finger print. Here it be. pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) Key fingerprint = D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA sub 2048g/D12E351D 2004-01-19 The GPG key that is on our website is alone w/out any signatures. This is what we use to sign packages as there is a bug with RPM when you use a key that has signatures on it. The key on the key-server may gather signatures from time to time, but the key on our site will not reflect this. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Freedom_Lover at pobox.com Fri Feb 13 22:59:41 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 13 Feb 2004 17:59:41 -0500 Subject: GPG fingerprint for verification In-Reply-To: <200402131422.41208.jkeating@j2solutions.net> References: <200402131422.41208.jkeating@j2solutions.net> Message-ID: <20040213225940.GC25704@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > In a bugzilla entry it was requested that I post the Fedora Legacy > finger print. Here it be. > > pub 1024D/731002FA 2004-01-19 Fedora Legacy > (http://www.fedoralegacy.org) > Key fingerprint = D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA > sub 2048g/D12E351D 2004-01-19 Cool. Thanks Jesse! > The GPG key that is on our website is alone w/out any signatures. > This is what we use to sign packages as there is a bug with RPM when > you use a key that has signatures on it. No shit? I've never run into that one. I sign all the packages I build for my own systems and have never run into this. I'm mostly using 7.3 now, though I've done this on each redhat version since around 6.0. I've got less testing time with 8.0 or 9, but I have built and checked rpm's on both those versions using keys with multiple signatures on them. Anyone have a pointer to where I can learn more about this rpm bug? - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The American Republic will endure until the day Congress discovers that it can bribe the public with the public's money. -- Alexis De Tocqueville. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFALVbbuv+09NZUB1oRAoLEAJ9jcoX99vJQqtjDJhdO85C8GYEKKwCeNruv 2k5MOyAmktUBnwJnO53No24= =77gH -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Sat Feb 14 00:45:34 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 14 Feb 2004 01:45:34 +0100 Subject: GPG fingerprint for verification In-Reply-To: <20040213225940.GC25704@psilocybe.teonanacatl.org> References: <200402131422.41208.jkeating@j2solutions.net> <20040213225940.GC25704@psilocybe.teonanacatl.org> Message-ID: <20040214014534.3b3b42b8.ms-nospam-0306@arcor.de> On Fri, 13 Feb 2004 17:59:41 -0500, Todd wrote: > > The GPG key that is on our website is alone w/out any signatures. > > This is what we use to sign packages as there is a bug with RPM when > > you use a key that has signatures on it. > > No shit? I've never run into that one. > Anyone have a pointer to where I can learn more about this rpm bug? bug #90952 -- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Feb 12 06:36:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Feb 2004 22:36:26 -0800 Subject: [FLSA-2004:1232] Updated slocate resolves security vulnerabilites Message-ID: <200402112236.27912.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated slocate resolves security vulnerabilities Advisory ID: FLSA:1232 Issue date: 2004-02-11 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1232 CVE Names: CAN-2003-0848, CAN-2003-0056 - ----------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix security vulnerabilities which may allow local users to gain "slocate" group privileges. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. A vulnerability has been found in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. These packages also fix a buffer overflow that affected unpatched versions of Slocate prior to 2.7. This vulnerability could also allow a local user to gain "slocate" group privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0056 to this issue. Users of slocate should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Patrik Hornik and Kevin Lindsay fir disclosing these issues, as well as Michael Schwendt for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1232 - slocate security fix rh72, rh73, rh80 / CAN-2003-0848 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 50b9bf61a1c6066c2c0671cb9c38a18f07c9e5fa 7.2/updates/SRPMS/slocate-2.7-1.7.2.legacy.src.rpm 47b001b499d89b75a8bad2dafb884d9c393c1e9a 7.2/updates/i386/slocate-2.7-1.7.2.legacy.i386.rpm b3654ebce54ae26617f2f18457fa9731542971ab 7.3/updates/SRPMS/slocate-2.7-1.7.3.legacy.src.rpm eae25387e00a671974e0c43aa5b7f478dd04636f 7.3/updates/i386/slocate-2.7-1.7.3.legacy.i386.rpm b2238d14cec50187139883c34265c905b8495109 8.0/updates/SRPMS/slocate-2.7-1.8.0.legacy.src.rpm a22d3b45922b0123a0ca9035dd9f66093d63651d 8.0/updates/i386/slocate-2.7-1.8.0.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0056 http://rhn.redhat.com/errata/RHSA-2004-041.html https://bugzilla.fedora.us/show_bug.cgi?id=1232 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKx7q4v2HLvE71NURApJvAJ0Rb2bMl3clQn/o01EceNVBlw4o1gCgiExh exovlLtzTvi0t4XDfr8OT+8= =lmAX -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Feb 14 17:50:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 14 Feb 2004 09:50:14 -0800 Subject: GRRR Message-ID: <200402140950.15850.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is something seriously wrong w/ bugtraq's mailing list. It seems that if I send a notice to bugtraq, bugtraq likes to echo it right back to the LIST, instead of me, but echos it fully which means it'll go back to bugtraq, and so on and so forth. I'm going to stop sending messages to bugtraq for now until we get this sorted out. I've also re-set the list to explicitly hold any of my posts for approval. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFALl/W4v2HLvE71NURAg4rAJ9PMctij4naSRr9GBCJIVA5DqsymQCgqmMw urY4lNbbHCcg6GP4pmyftuU= =Z4k6 -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Mon Feb 16 20:26:07 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 16 Feb 2004 15:26:07 -0500 Subject: BuildRequires v. BuildPreReq In-Reply-To: <20040215170005.32251.63178.Mailman@listman.back-rdu.redhat.com> References: <20040215170005.32251.63178.Mailman@listman.back-rdu.redhat.com> Message-ID: <4031275F.5080403@ysu.edu> GRRR. I just found that XFree86.spec is missing a libtool BuildRequires. Rebuilding... All of the build requirements in XFree86.spec are given as BuildPreReq's. What's the difference? Thanks, John From drees at greenhydrant.com Mon Feb 16 21:02:32 2004 From: drees at greenhydrant.com (David Rees) Date: Mon, 16 Feb 2004 13:02:32 -0800 Subject: BuildRequires v. BuildPreReq In-Reply-To: <4031275F.5080403@ysu.edu> References: <20040215170005.32251.63178.Mailman@listman.back-rdu.redhat.com> <4031275F.5080403@ysu.edu> Message-ID: <40312FE8.4060105@greenhydrant.com> John Dalbec wrote, On 2/16/2004 12:26 PM: > GRRR. I just found that XFree86.spec is missing a libtool > BuildRequires. Rebuilding... > All of the build requirements in XFree86.spec are given as > BuildPreReq's. What's the difference? From what I can tell, BuildPreReq is deprecated, and should be replaced with BuildRequire. http://www.geocrawler.com/archives/3/87/1999/7/50/2480267/ -Dave From jpdalbec at ysu.edu Tue Feb 17 18:38:39 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 17 Feb 2004 13:38:39 -0500 Subject: fedora-legacy-list digest, Vol 1 #100 - 2 msgs In-Reply-To: <20040217170003.10610.95620.Mailman@listman.back-rdu.redhat.com> References: <20040217170003.10610.95620.Mailman@listman.back-rdu.redhat.com> Message-ID: <40325FAF.1070401@ysu.edu> > Date: Mon, 16 Feb 2004 13:02:32 -0800 > From: David Rees > To: fedora-legacy-list at redhat.com > Subject: Re: BuildRequires v. BuildPreReq > Reply-To: fedora-legacy-list at redhat.com > > John Dalbec wrote, On 2/16/2004 12:26 PM: > >>GRRR. I just found that XFree86.spec is missing a libtool >>BuildRequires. Rebuilding... >>All of the build requirements in XFree86.spec are given as >>BuildPreReq's. What's the difference? > > > From what I can tell, BuildPreReq is deprecated, and should be replaced > with BuildRequire. > > http://www.geocrawler.com/archives/3/87/1999/7/50/2480267/ > > -Dave *sigh* Rebuilding... John From ms-nospam-0306 at arcor.de Wed Feb 18 03:25:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 18 Feb 2004 04:25:20 +0100 Subject: BuildRequires v. BuildPreReq In-Reply-To: <40312FE8.4060105@greenhydrant.com> References: <20040215170005.32251.63178.Mailman@listman.back-rdu.redhat.com> <4031275F.5080403@ysu.edu> <40312FE8.4060105@greenhydrant.com> Message-ID: <20040218042520.453796f9.ms-nospam-0306@arcor.de> On Mon, 16 Feb 2004 13:02:32 -0800, David Rees wrote: > John Dalbec wrote, On 2/16/2004 12:26 PM: > > GRRR. I just found that XFree86.spec is missing a libtool > > BuildRequires. Rebuilding... > > All of the build requirements in XFree86.spec are given as > > BuildPreReq's. What's the difference? > > From what I can tell, BuildPreReq is deprecated, and should be replaced > with BuildRequire. > > http://www.geocrawler.com/archives/3/87/1999/7/50/2480267/ But with old distributions with old software and old packages, that is no reason to be concerned. Only if an update package is to be built on multiple target platforms and on one of them BuildPreReq were obsolete, that would require getting rid of BuildPreReq in spec files. -- From jkeating at j2solutions.net Wed Feb 18 15:43:15 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 07:43:15 -0800 Subject: A plea to the people downloading from download.fedoralegacy.org Message-ID: <200402180743.20823.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Currently this server is my personal server, and it shares a system with some paying customers of j2Solutions, my personal business. As of late, the amount of people downloading from me has skyrocketed, and caused the server to fall to it's knees bandwidth wise. My usage went up to 1.1TB of bandwidth over the last 30 days. So, I'm begging you, PLEASE use the mirrors for your downloading. We have put up a list of mirrors (nearly complete, missing a couple) here: http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php Please, feel very free to use them. I have hardware on the way to build a dedicated master mirror, but until then I have to do something to limit my bandwidth usage. I've already dropped rsync to only 5 active connections, and I'm trying to get mod_throttle working for http. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAM4gY4v2HLvE71NURAgamAJ9TdH6UWEcGBTXNRCX/t6xzDZ98vgCfSqAo k8NarwTztIFScBl4DUvQwLw= =PFvq -----END PGP SIGNATURE----- From joey at clean.q7.com Wed Feb 18 15:55:03 2004 From: joey at clean.q7.com (Joe Pruett) Date: Wed, 18 Feb 2004 07:55:03 -0800 (PST) Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180743.20823.jkeating@j2solutions.net> Message-ID: the ncsu.edu rsync link is wrong, it should be: rsync://mirror.physics.ncsu.edu/fedoralegacy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 18 15:55:52 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 18 Feb 2004 16:55:52 +0100 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180743.20823.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> Message-ID: <20040218165552.50a5ec94@localhost> Jesse Keating wrote : > Currently this server is my personal server, and it shares a system with > some paying customers of j2Solutions, my personal business. As of late, > the amount of people downloading from me has skyrocketed, and caused the > server to fall to it's knees bandwidth wise. My usage went up to 1.1TB of > bandwidth over the last 30 days. So, I'm begging you, PLEASE use the > mirrors for your downloading. Why not just point download.fedoralegacy.org to a full mirror server which has the same "official" services (http, ftp, rsync) with the same paths? That's what I've done a while ago for {ayo,ftp}.freshrpms.net, as you can always be assured that waaaaay more people will use the default configuration than bother to point to a mirror. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.2-1.81 Load : 0.02 0.11 0.13 From jkeating at j2solutions.net Wed Feb 18 16:00:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 08:00:14 -0800 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <20040218165552.50a5ec94@localhost> References: <200402180743.20823.jkeating@j2solutions.net> <20040218165552.50a5ec94@localhost> Message-ID: <200402180800.14755.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 February 2004 07:55, Matthias Saou wrote: > Why not just point download.fedoralegacy.org to a full mirror server > which has the same "official" services (http, ftp, rsync) with the same > paths? That's what I've done a while ago for {ayo,ftp}.freshrpms.net, as > you can always be assured that waaaaay more people will use the default > configuration than bother to point to a mirror. The plan is that "download.fedoralegacy.org" will be it's own box, capable of handling all the bandwidth. I'm building a single opteron server, w/ 512 megs of ram and a 80gig IDE software mirror. The total bandwidth used isn't so much the issue, more of rsync killed the CPU on the current box, and the bandwidth used is making other services on this system lag. The dedicated box is about a week out (I hope) so I don't want to cut over to somebody, then cut right back. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAM4wO4v2HLvE71NURAt9sAKCTE7Dn5AuyO1z1/t7Vxcz6mrr1RwCgkYta fHyjCdltkpTTJnibANM0Ico= =vAh6 -----END PGP SIGNATURE----- From ncb at cc.gatech.edu Wed Feb 18 17:02:39 2004 From: ncb at cc.gatech.edu (Neil Bright) Date: Wed, 18 Feb 2004 12:02:39 -0500 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180743.20823.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> Message-ID: <424CE0C8-6234-11D8-ABA5-000A957D6FD4@cc.gatech.edu> Feel free to add me to the mirrors list: Georgia Tech. Software Library College of Computing Georgia Institute of Technology Atlanta, GA USA http://www.gtlib.cc.gatech.edu/pub/fedoralegacy ftp://ftp.gtlib.cc.gatech.edu/pub/fedoralegacy rsync://rsync.gtlib.cc.gatech.edu/fedoralegacy On Feb 18, 2004, at 10:43 AM, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Currently this server is my personal server, and it shares a system > with > some paying customers of j2Solutions, my personal business. As of > late, > the amount of people downloading from me has skyrocketed, and caused > the > server to fall to it's knees bandwidth wise. My usage went up to > 1.1TB of > bandwidth over the last 30 days. So, I'm begging you, PLEASE use the > mirrors for your downloading. We have put up a list of mirrors (nearly > complete, missing a couple) here: > > http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php > > Please, feel very free to use them. I have hardware on the way to > build a > dedicated master mirror, but until then I have to do something to > limit my > bandwidth usage. I've already dropped rsync to only 5 active > connections, > and I'm trying to get mod_throttle working for http. > > - -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAM4gY4v2HLvE71NURAgamAJ9TdH6UWEcGBTXNRCX/t6xzDZ98vgCfSqAo > k8NarwTztIFScBl4DUvQwLw= > =PFvq > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > +=================================================================+ Neil Bright Computing and Networking Services, ncb at cc.gatech.edu CERCS / IHPCL, College of Computing (404) 385-0448 Georgia Institute of Technology From admin at cs.montana.edu Wed Feb 18 17:43:20 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 18 Feb 2004 10:43:20 -0700 (MST) Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180743.20823.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> Message-ID: <3530.153.90.196.197.1077126200.squirrel@webtest.cs.montana.edu> Jesse Keating said: So, I'm begging you, PLEASE use the > mirrors for your downloading. We have put up a list of mirrors (nearly > complete, missing a couple) here: > > http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php > I have switched mirroring to the canadian site: You need to update the rsync listing for the site, as the current listing is wrong. currently listed as: RSYNC: rsync://mirror.cpsc.ucalgary.ca/mirror/fedoralegacy.org/ It should be: RSYNC: rsync://mirror.cpsc.ucalgary.ca/fedoralegacy -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From jpdalbec at ysu.edu Wed Feb 18 17:53:53 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 18 Feb 2004 12:53:53 -0500 Subject: fedora-legacy-list digest, Vol 1 #101 - 6 msgs In-Reply-To: <20040218170013.20433.16247.Mailman@listman.back-rdu.redhat.com> References: <20040218170013.20433.16247.Mailman@listman.back-rdu.redhat.com> Message-ID: <4033A6B1.9060309@ysu.edu> > From: Jesse Keating > Organization: j2Solutions > To: fedora-legacy-list at redhat.com > Subject: A plea to the people downloading from download.fedoralegacy.org > Date: Wed, 18 Feb 2004 07:43:15 -0800 > Reply-To: fedora-legacy-list at redhat.com > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Currently this server is my personal server, and it shares a system with > some paying customers of j2Solutions, my personal business. As of late, > the amount of people downloading from me has skyrocketed, and caused the > server to fall to it's knees bandwidth wise. My usage went up to 1.1TB of > bandwidth over the last 30 days. So, I'm begging you, PLEASE use the > mirrors for your downloading. We have put up a list of mirrors (nearly > complete, missing a couple) here: > > http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php Have you updated the mirror selector files for apt? I tried apt-get mirror-select but it only offered "Fedoralegacy.org, USA". Does the mirror selector download the list of mirrors every time or does it cache it somewhere? Thanks, John From jkeating at j2solutions.net Wed Feb 18 17:48:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 09:48:41 -0800 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <3530.153.90.196.197.1077126200.squirrel@webtest.cs.montana.edu> References: <200402180743.20823.jkeating@j2solutions.net> <3530.153.90.196.197.1077126200.squirrel@webtest.cs.montana.edu> Message-ID: <200402180948.46256.jkeating@j2solutions.net> On Wednesday 18 February 2004 09:43, Lucas Albers wrote: > I have switched mirroring to the canadian site: > You need to update the rsync listing for the site, as the current > listing is wrong. > currently listed as: > RSYNC: rsync://mirror.cpsc.ucalgary.ca/mirror/fedoralegacy.org/ > It should be: > RSYNC: rsync://mirror.cpsc.ucalgary.ca/fedoralegacy Ok, there is a small problem in the file that I originally created, and it doesn't handle protocol URLs that differ, so for now I've removed rsync from your listing. We'll be making the mirror list accept specific urls for specific protocols and re-insert the extra stuff. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Wed Feb 18 18:56:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 10:56:58 -0800 Subject: fedora-legacy-list digest, Vol 1 #101 - 6 msgs In-Reply-To: <4033A6B1.9060309@ysu.edu> References: <20040218170013.20433.16247.Mailman@listman.back-rdu.redhat.com> <4033A6B1.9060309@ysu.edu> Message-ID: <200402181057.02652.jkeating@j2solutions.net> On Wednesday 18 February 2004 09:53, John Dalbec wrote: > Have you updated the mirror selector files for apt? I tried apt-get > mirror-select but it only offered "Fedoralegacy.org, USA". Does the > mirror selector download the list of mirrors every time or does it > cache it somewhere? Thanks, > John I have not yet updated it. I'm still a little unclear as to the format. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 andreas at bawue.net Wed Feb 18 21:42:49 2004 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 18 Feb 2004 22:42:49 +0100 (CET) Subject: Fixed Kernel? Message-ID: Hi, I'm wondering as I didn't saw a kernel release on the legacy adivsory page: Do you already have an RPM packagred? We did a rebuild of the RH9 package with some small additions to adapt it to RH7.x for our internal machines and a small RPC-patch which removes some debugging output that is cluttering /dev/console which seems to run fine on our boxes., Are you interested in that or do you favour your own kernel? bye, andreas From rostetter at mail.utexas.edu Wed Feb 18 21:44:50 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 18 Feb 2004 15:44:50 -0600 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180948.46256.jkeating@j2solutions.net> References: <200402180743.20823.jkeating@j2solutions.net> <3530.153.90.196.197.1077126200.squirrel@webtest.cs.montana.edu> <200402180948.46256.jkeating@j2solutions.net> Message-ID: <20040218154450.sc4sooosks08sgk4@mail.ph.utexas.edu> Quoting Jesse Keating : > Ok, there is a small problem in the file that I originally created, and > it doesn't handle protocol URLs that differ. It may be true that there was such a problem in your original file, but I think the script which generates the mirror page allows for this (from day 0) so there really isn't a problem. > so for now I've removed > rsync from your listing. We'll be making the mirror list accept > specific urls for specific protocols and re-insert the extra stuff. I don't believe any change is needed, except to the file you maintain. We foresaw this problem and coded around it, IIRC. -- Eric Rostetter From jkeating at j2solutions.net Wed Feb 18 21:51:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 13:51:16 -0800 Subject: Fixed Kernel? In-Reply-To: References: Message-ID: <200402181351.20730.jkeating@j2solutions.net> On Wednesday 18 February 2004 13:42, Andreas Thienemann wrote: > Hi, > > I'm wondering as I didn't saw a kernel release on the legacy adivsory > page: > > Do you already have an RPM packagred? > > We did a rebuild of the RH9 package with some small additions to > adapt it to RH7.x for our internal machines and a small RPC-patch > which removes some debugging output that is cluttering /dev/console > which seems to run fine on our boxes., > > Are you interested in that or do you favour your own kernel? Hi Andreas. Because we are a volunteer group, and we are not included in any "inner circle" security lists, we have to react to what we see from the other distributors. We do have a kernel that needs QA, you'll find it in our bugzilla. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Wed Feb 18 21:53:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 13:53:38 -0800 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <20040218154450.sc4sooosks08sgk4@mail.ph.utexas.edu> References: <200402180743.20823.jkeating@j2solutions.net> <200402180948.46256.jkeating@j2solutions.net> <20040218154450.sc4sooosks08sgk4@mail.ph.utexas.edu> Message-ID: <200402181353.38097.jkeating@j2solutions.net> On Wednesday 18 February 2004 13:44, Eric Rostetter wrote: > It may be true that there was such a problem in your original file, > but I think the script which generates the mirror page allows for > this (from day 0) so there really isn't a problem. > > > so for now I've removed > > rsync from your listing. We'll be making the mirror list accept > > specific urls for specific protocols and re-insert the extra stuff. > > I don't believe any change is needed, except to the file you > maintain. We foresaw this problem and coded around it, IIRC. mia culpa! You are in fact right! I will update the .list file accordingly. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 cra at WPI.EDU Thu Feb 19 00:02:14 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 18 Feb 2004 19:02:14 -0500 Subject: Fixed Kernel? In-Reply-To: <200402181351.20730.jkeating@j2solutions.net> References: <200402181351.20730.jkeating@j2solutions.net> Message-ID: <20040219000214.GS26418@angus.ind.WPI.EDU> Right now there are two bugs in bugzilla that require a new kernel to be rolled: https://bugzilla.fedora.us/show_bug.cgi?id=1284 https://bugzilla.fedora.us/show_bug.cgi?id=1302 Both issues are fixed in the latest RHL 9 errata, 2.4.20-30.9, and both bugs have identical patches. Should one of these be resolved as a duplicate of the other? From davej at redhat.com Thu Feb 19 00:06:15 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 19 Feb 2004 00:06:15 +0000 Subject: Fixed Kernel? In-Reply-To: <20040219000214.GS26418@angus.ind.WPI.EDU> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> Message-ID: <20040219000615.GF6242@redhat.com> On Wed, Feb 18, 2004 at 07:02:14PM -0500, Charles R. Anderson wrote: > Right now there are two bugs in bugzilla that require a new kernel to > be rolled: > > https://bugzilla.fedora.us/show_bug.cgi?id=1284 > https://bugzilla.fedora.us/show_bug.cgi?id=1302 > > Both issues are fixed in the latest RHL 9 errata, 2.4.20-30.9, and > both bugs have identical patches. Should one of these be resolved as > a duplicate of the other? Wait for 2174 before pushing an update. (It just got pushed out to mirrors). It fixes a big problem with aacraid which caused 2173 to not boot for a lot of folks. Dave From jkeating at j2solutions.net Thu Feb 19 00:07:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 16:07:50 -0800 Subject: Fixed Kernel? In-Reply-To: <20040219000214.GS26418@angus.ind.WPI.EDU> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> Message-ID: <200402181607.54785.jkeating@j2solutions.net> On Wednesday 18 February 2004 16:02, Charles R. Anderson wrote: > Right now there are two bugs in bugzilla that require a new kernel to > be rolled: > > https://bugzilla.fedora.us/show_bug.cgi?id=1284 > https://bugzilla.fedora.us/show_bug.cgi?id=1302 > > Both issues are fixed in the latest RHL 9 errata, 2.4.20-30.9, and > both bugs have identical patches. Should one of these be resolved as > a duplicate of the other? Done. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Feb 19 00:16:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 16:16:04 -0800 Subject: Fixed Kernel? In-Reply-To: <20040219000615.GF6242@redhat.com> References: <20040219000214.GS26418@angus.ind.WPI.EDU> <20040219000615.GF6242@redhat.com> Message-ID: <200402181616.05039.jkeating@j2solutions.net> On Wednesday 18 February 2004 16:06, Dave Jones wrote: > Wait for 2174 before pushing an update. (It just got pushed out to > mirrors). It fixes a big problem with aacraid which caused 2173 to > not boot for a lot of folks. Thanks Dave! Does this refer to 2174 of Fedora ? We should backport the aacraid stuff from 2174 into the RHL kernel line? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dom at earth.li Thu Feb 19 00:20:26 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 19 Feb 2004 00:20:26 +0000 Subject: Fixed Kernel? In-Reply-To: <20040219000214.GS26418@angus.ind.WPI.EDU> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> Message-ID: <20040219002026.GM930@tirian.magd.ox.ac.uk> On Wed, Feb 18, 2004 at 07:02:14PM -0500, Charles R. Anderson wrote: > Both issues are fixed in the latest RHL 9 errata, 2.4.20-30.9, and > both bugs have identical patches. Should one of these be resolved as > a duplicate of the other? It looks like this has now been done. I just thought I'd say hi and at the same time apologise for wading in a bit too quickly today with that new bugzilla entry; I can see that it wasn't particularly productive (it was also bad luck that Michael added to a previous bug just after I'd looked at it). Anyway, thanks for existing; it's helped management of my workplace's desktops. Hopefully I can contribute more in future :) Cheers, Dominic. From chuckw at quantumlinux.com Thu Feb 19 00:21:59 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 18 Feb 2004 16:21:59 -0800 (PST) Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <200402180743.20823.jkeating@j2solutions.net> Message-ID: On Wed, 18 Feb 2004, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Currently this server is my personal server, and it shares a system with > some paying customers of j2Solutions, my personal business. As of late, > the amount of people downloading from me has skyrocketed, and caused the > server to fall to it's knees bandwidth wise. My usage went up to 1.1TB > of bandwidth over the last 30 days. So, I'm begging you, PLEASE use the > mirrors for your downloading. We have put up a list of mirrors (nearly > complete, missing a couple) here: Forgive me if this has already been suggested, but have you looked into limiting bandwidth to certain services with shaper? -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From davej at redhat.com Thu Feb 19 00:23:59 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 19 Feb 2004 00:23:59 +0000 Subject: Fixed Kernel? In-Reply-To: <200402181616.05039.jkeating@j2solutions.net> References: <20040219000214.GS26418@angus.ind.WPI.EDU> <20040219000615.GF6242@redhat.com> <200402181616.05039.jkeating@j2solutions.net> Message-ID: <20040219002359.GG6242@redhat.com> On Wed, Feb 18, 2004 at 04:16:04PM -0800, Jesse Keating wrote: Content-Description: signed data > On Wednesday 18 February 2004 16:06, Dave Jones wrote: > > Wait for 2174 before pushing an update. (It just got pushed out to > > mirrors). It fixes a big problem with aacraid which caused 2173 to > > not boot for a lot of folks. > > Thanks Dave! Does this refer to 2174 of Fedora ? oh, duhh. I'm getting my kernels mixed up. > . We should backport > the aacraid stuff from 2174 into the RHL kernel line? the rhl9 errata that went out is fine[*], ignore me.. just flip the nptl switches, and you should be good to go. Dave [*] well, not fine - it has the bug that patch tried to fix, but unlike fedora, didnt include it, so didnt get borked. From jkeating at j2solutions.net Thu Feb 19 00:35:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Feb 2004 16:35:02 -0800 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: References: Message-ID: <200402181635.03002.jkeating@j2solutions.net> On Wednesday 18 February 2004 16:21, Chuck Wolber wrote: > Forgive me if this has already been suggested, but have you looked > into limiting bandwidth to certain services with shaper? I am throttling the particular virtual host that is download.fedoralegacy.org. If this were to be a perm host of the services, I'd shape them. Being that this is a temporary solution I don't want to get into that just yet. Also, most of the difficulty I've been having in the last week ends up being my switch locking me in at 5M instead of 10M, and causing all kinds of problems. This has since been fixed (just today) and things seem much better for me. I'm still throttling http traffic on download.fedoralegacy.org to just 1M/s limit, but thats plenty no? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pmatilai at welho.com Thu Feb 19 09:09:39 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 19 Feb 2004 11:09:39 +0200 (EET) Subject: fedora-legacy-list digest, Vol 1 #101 - 6 msgs In-Reply-To: <200402181057.02652.jkeating@j2solutions.net> References: <20040218170013.20433.16247.Mailman@listman.back-rdu.redhat.com> <4033A6B1.9060309@ysu.edu> <200402181057.02652.jkeating@j2solutions.net> Message-ID: On Wed, 18 Feb 2004, Jesse Keating wrote: > On Wednesday 18 February 2004 09:53, John Dalbec wrote: > > Have you updated the mirror selector files for apt? I tried apt-get > > mirror-select but it only offered "Fedoralegacy.org, USA". Does the > > mirror selector download the list of mirrors every time or does it > > cache it somewhere? Thanks, > > John > > I have not yet updated it. I'm still a little unclear as to the format. I know it's helluva stupid fileformat - feel free to blame me :) It's also quite simple: <1st mirror name/location> <1st mirror sources.list entry> -- <2nd mirror name/location> <2nd mirrror sources.list entry> -- ..... ---- The "----" means end of repository, either it's the last line in the file or you can list another repository there. Hopefully that makes it clearer, if not feel free to ask me. - Panu - From peter.abraham at dynamicnet.net Thu Feb 19 13:12:46 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Thu, 19 Feb 2004 08:12:46 -0500 Subject: Fixed Kernel? In-Reply-To: <20040219000214.GS26418@angus.ind.WPI.EDU> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> Message-ID: <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> Greetings: Will the Fedora team be releasing a kernel update to RedHat 7.x? Thank you. At 07:02 PM 2/18/2004, you wrote: >Right now there are two bugs in bugzilla that require a new kernel to >be rolled: > >https://bugzilla.fedora.us/show_bug.cgi?id=1284 >https://bugzilla.fedora.us/show_bug.cgi?id=1302 > >Both issues are fixed in the latest RHL 9 errata, 2.4.20-30.9, and >both bugs have identical patches. Should one of these be resolved as >a duplicate of the other? > > >-- >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 Thu Feb 19 16:01:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 19 Feb 2004 08:01:12 -0800 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> References: <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> Message-ID: <200402190801.12515.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 19 February 2004 05:12, Peter M. Abraham wrote: > Will the Fedora team be releasing a kernel update to RedHat 7.x? Yes we will. Look for an updates-testing kernel hopefully by Friday evening PST. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFANN3I4v2HLvE71NURAp5qAJ417k4CJDwCQ4TVYXEoDgp+ruS7dwCfQcWj s917XnpfpEAFIY4WfAESKDU= =pxut -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Thu Feb 19 16:24:26 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 19 Feb 2004 17:24:26 +0100 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> Message-ID: <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> On Thu, 19 Feb 2004 08:12:46 -0500, Peter M. Abraham wrote: > Greetings: > > Will the Fedora team be releasing a kernel update to RedHat 7.x? > > Thank you. > > At 07:02 PM 2/18/2004, you wrote: > >Right now there are two bugs in bugzilla that require a new kernel to > >be rolled: > > > >https://bugzilla.fedora.us/show_bug.cgi?id=1284 If you can't wait, visit above URL, read comment 3, get the new kernel erratum src.rpm for Red Hat Linux 9, apply the small patch which flips two lines in the spec file and build for rh7x. -- From jjneely at pams.ncsu.edu Thu Feb 19 16:25:39 2004 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 19 Feb 2004 11:25:39 -0500 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: References: <200402180743.20823.jkeating@j2solutions.net> Message-ID: <20040219162539.GF7314@anduril.pams.ncsu.edu> On Wed, Feb 18, 2004 at 07:55:03AM -0800, Joe Pruett wrote: > the ncsu.edu rsync link is wrong, it should be: > rsync://mirror.physics.ncsu.edu/fedoralegacy > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > Well..actually there are intended to be two mirrors at NCSU. Being that ftp.linux.ncsu.edu is the first listed Red Hat / Fedora mirror I've been trying to wait for the demand for FC2-test1 to die off. Otherwise, its rather difficult to sync. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jpdalbec at ysu.edu Thu Feb 19 21:58:12 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 19 Feb 2004 16:58:12 -0500 Subject: fedora-rpmdevtools question Message-ID: <40353174.9080001@ysu.edu> Does anyone else find fedora-wipebuildtree too aggressive? I'm used to storing RPMs and SRPMs in the build tree, but fedora-wipebuildtree wipes those out along with the specs, sources, and build directories. Where do other people store RPMs and SRPMs that they have built and want to keep? Thanks, John From sheltren at cs.ucsb.edu Thu Feb 19 22:16:52 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 19 Feb 2004 14:16:52 -0800 Subject: fedora-rpmdevtools question In-Reply-To: <40353174.9080001@ysu.edu> References: <40353174.9080001@ysu.edu> Message-ID: <1077229012.5110.5.camel@forsberg> I've never used the wipebuildtree, but as soon as I have an RPM that I want to keep, I copy it over to a repository/FTP server, since I seem to accidently delete/loose stuff like that if I only keep it on my machine. -Jeff On Thu, 2004-02-19 at 13:58, John Dalbec wrote: > Does anyone else find fedora-wipebuildtree too aggressive? I'm used to storing > RPMs and SRPMs in the build tree, but fedora-wipebuildtree wipes those out along > with the specs, sources, and build directories. Where do other people store > RPMs and SRPMs that they have built and want to keep? > Thanks, > John > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From gmott at ntlworld.com Fri Feb 20 16:21:49 2004 From: gmott at ntlworld.com (g) Date: Fri, 20 Feb 2004 16:21:49 +0000 Subject: jumpstarting yum on 7.2 In-Reply-To: <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> Message-ID: <1077294107.7174.42930.camel@ruby.rub.gnuleaf.net> hello legacists, after installing 7.2 from CD, the instructions at http://fedoralegacy.org/docs/yum-rh7x.php do not work: # rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-4.0.4-7x.i386.rpm Retrieving http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-4.0.4-7x.i386.rpm error: failed dependencies: popt = 1.6.4 is needed by rpm-4.0.4-7x rpm = 4.0.3 is needed by rpm-python-4.0.3-1.03 rpm = 4.0.3 is needed by rpm-build-4.0.3-1.03 rpm = 4.0.3 is needed by rpm-devel-4.0.3-1.03 rpm = 4.0.3 is needed by rpm-perl-4.0.3-1.03 librpm-4.0.3.so is needed by gnorpm-0.96-11 librpm-4.0.3.so is needed by kdeadmin-2.2-8 librpm-4.0.3.so is needed by rpm-python-4.0.3-1.03 librpm-4.0.3.so is needed by rpm-build-4.0.3-1.03 librpm-4.0.3.so is needed by rpm-perl-4.0.3-1.03 librpm-4.0.3.so is needed by rpm2html-1.7-1 librpm-4.0.3.so is needed by rpmfind-1.7-2 librpmbuild-4.0.3.so is needed by kdeadmin-2.2-8 librpmbuild-4.0.3.so is needed by rpm-build-4.0.3-1.03 librpmdb-4.0.3.so is needed by gnorpm-0.96-11 librpmdb-4.0.3.so is needed by kdeadmin-2.2-8 librpmdb-4.0.3.so is needed by rpm-python-4.0.3-1.03 librpmdb-4.0.3.so is needed by rpm-build-4.0.3-1.03 librpmdb-4.0.3.so is needed by rpm-perl-4.0.3-1.03 librpmdb-4.0.3.so is needed by rpm2html-1.7-1 librpmdb-4.0.3.so is needed by rpmfind-1.7-2 librpmio-4.0.3.so is needed by gnorpm-0.96-11 librpmio-4.0.3.so is needed by kdeadmin-2.2-8 librpmio-4.0.3.so is needed by rpm-python-4.0.3-1.03 librpmio-4.0.3.so is needed by rpm-build-4.0.3-1.03 librpmio-4.0.3.so is needed by rpm-perl-4.0.3-1.03 librpmio-4.0.3.so is needed by rpm2html-1.7-1 librpmio-4.0.3.so is needed by rpmfind-1.7-2 perhaps those instructions are presuming the user has already used RHN, but they do not say so. so here's what i did instead, and what happened: # rsync -vSPa rsync://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-* /tmp# # rsync -vSPa rsync://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/7.2/updates/i386/popt-* /tmp # rsync -vSPa rsync://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/7.2/legacy-utils/i386/yum-* /tmp # rpm -Uvh --nodeps /tmp/yum-* /tmp/rpm-* /tmp/popt-* i adjusted my /etc/yum.conf (see below), then # gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY # gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY # yum update ... .conflict between kernel-smp and bcm5820 conflict between kernel-debug and bcm5820 conflict between kernel and bcm5820 # rpm -e bcm5820 # yum update ... Getting postgresql-tcl-7.1.3-5.72.i386.rpm Getting php-pgsql-4.1.2-7.2.6.i386.rpm Error: MD5 Signature check failed for /var/cache/yum/updates/packages/php-pgsql-4.1.2-7.2.6.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/php-pgsql-4.1.2-7.2.6.i386.rpm Exiting. # rsync -vSPa rsync://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/7.2/updates/i386/php-pgsql-4.1.2-7.2.6.i386.rpm /var/cache/yum/updates/packages # yum update yum update finally ran successfully. #my /etc/yum.conf: [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest exactarch=1 exclude= # Added this because some mirrors go down and then retying takes forever. retries=1 [base] name=Red Hat Linux $releasever base baseurl=http://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/$releasever/os/$basearch gpgcheck=1 [updates] name=Red Hat Linux $releasever updates baseurl=http://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/$releasever/updates/$basearch gpgcheck=1 [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://ftp.heanet.ie/mirrors/download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch gpgcheck=1 From jjneely at pams.ncsu.edu Fri Feb 20 18:01:38 2004 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Fri, 20 Feb 2004 13:01:38 -0500 Subject: A plea to the people downloading from download.fedoralegacy.org In-Reply-To: <20040219162539.GF7314@anduril.pams.ncsu.edu> References: <200402180743.20823.jkeating@j2solutions.net> <20040219162539.GF7314@anduril.pams.ncsu.edu> Message-ID: <20040220180138.GM7314@anduril.pams.ncsu.edu> On Thu, Feb 19, 2004 at 11:25:39AM -0500, Jack Neely wrote: > On Wed, Feb 18, 2004 at 07:55:03AM -0800, Joe Pruett wrote: > > the ncsu.edu rsync link is wrong, it should be: > > rsync://mirror.physics.ncsu.edu/fedoralegacy > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > Well..actually there are intended to be two mirrors at NCSU. Being that > ftp.linux.ncsu.edu is the first listed Red Hat / Fedora mirror I've been > trying to wait for the demand for FC2-test1 to die off. Otherwise, its > rather difficult to sync. > > Jack Neely > > -- > Jack Neely > Realm Linux Administration and Development > PAMS Computer Operations at NC State University > GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > Okay...ftp.linux.ncsu.edu has finally been populated. Repositories are also Yum-ified. ftp://ftp.linux.ncsu.edu/pub/fedoralegacy Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From rostetter at mail.utexas.edu Fri Feb 20 20:42:36 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 20 Feb 2004 14:42:36 -0600 Subject: jumpstarting yum on 7.2 In-Reply-To: <1077294107.7174.42930.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <1077294107.7174.42930.camel@ruby.rub.gnuleaf.net> Message-ID: <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> Quoting g : > after installing 7.2 from CD, the instructions at > http://fedoralegacy.org/docs/yum-rh7x.php > do not work: I see. > # rpm -Uvh > http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-4.0.4-7x.i386.rpm We'd have to allow for rpm* and popt here. You could do that all on one line, but it would be a very long line. I'm not sure of a good remote solution... > # rpm -Uvh --nodeps /tmp/yum-* /tmp/rpm-* /tmp/popt-* You should not have to use --nodeps. If you do, then something is wrong. > # yum update > ... > .conflict between kernel-smp and bcm5820 > conflict between kernel-debug and bcm5820 > conflict between kernel and bcm5820 That is, I guess, a real conflict, and not a problem yum or our docs can really address. > # rpm -e bcm5820 > # yum update But, that is a good solution assuming you don't need bcm5820. > Getting php-pgsql-4.1.2-7.2.6.i386.rpm > Error: MD5 Signature check failed for > /var/cache/yum/updates/packages/php-pgsql-4.1.2-7.2.6.i386.rpm Again, not a problem with yum or the docs, but perhaps a problem with the file in the repository you used. You need to contact the repository owner about such problems. It may be a corrupted file, or a file caught during an update of the repo, or a corruption of the download of the file from the site. > exclude= Be default it would exclude kernels, and hence your conflict above would not have happened (for better or for worse). > # Added this because some mirrors go down and then retying takes forever. > retries=1 Interesting ;) -- Eric Rostetter From gmott at ntlworld.com Fri Feb 20 23:12:14 2004 From: gmott at ntlworld.com (g) Date: Fri, 20 Feb 2004 23:12:14 +0000 Subject: jumpstarting yum on 7.2 In-Reply-To: <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <1077294107.7174.42930.camel@ruby.rub.gnuleaf.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> Message-ID: <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> On Fri, 2004-02-20 at 20:42, Eric Rostetter wrote: > Quoting g : > > # rpm -Uvh --nodeps /tmp/yum-* /tmp/rpm-* /tmp/popt-* > > You should not have to use --nodeps. If you do, then something is wrong. what is "wrong" is that i did not want to bother to manually download gnorpm, kdeadmin, et al, which i did not need just to get yum going, and which would get downloaded automatically anyway when i ran yum update. > > # yum update > > ... > > .conflict between kernel-smp and bcm5820 > > conflict between kernel-debug and bcm5820 > > conflict between kernel and bcm5820 > > That is, I guess, a real conflict, and not a problem yum or our docs can > really address... > > > exclude= > > Be default it would exclude kernels, and hence your conflict above > would not have happened (for better or for worse). it does appear that the provided yum configuration, and the docs, presume we don't want to update the kernel. i realize this is also what the default up2date configuration was. even so, this is strange thinking. the updated kernel is essential if we're talking about security. > > Error: MD5 Signature check failed for /var/cache/yum/updates/packages/php-pgsql-4.1.2-7.2.6.i386.rpm > > You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/php-pgsql-4.1.2-7.2.6.i386.rpm > > Again, not a problem with yum or the docs, but perhaps a problem with > the file in the repository you used. You need to contact the repository > owner about such problems. It may be a corrupted file, or a file caught > during an update of the repo, or a corruption of the download of the > file from the site. as the error message says, all that's necessary is to remove the file. while it is possible that i collided (on 2 such occurrences) with a repo update, i think it more likely that yum occationally simply fails to completely download the files, probably due to lost packets or whatever. From eric.rostetter at physics.utexas.edu Fri Feb 20 20:47:10 2004 From: eric.rostetter at physics.utexas.edu (Eric Rostetter) Date: Fri, 20 Feb 2004 14:47:10 -0600 Subject: yum and apt differences. Message-ID: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> I've installed the FL versions of yum and apt, and noticed the following inconsistencies. * yum ignores kernel updates by default, but apt doesn't. * yum doesn't auto install any gpg keys, but apt does. Should we not try to make these consistent between yum and apt? Or is the yum/apt history that says they should act differently? -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From jkeating at j2solutions.net Fri Feb 20 23:26:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 20 Feb 2004 15:26:40 -0800 Subject: jumpstarting yum on 7.2 In-Reply-To: <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> Message-ID: <200402201526.44348.jkeating@j2solutions.net> On Friday 20 February 2004 15:12, g wrote: > it does appear that the provided yum configuration, and the docs, > presume we don't want to update the kernel. i realize this is also > what the default up2date configuration was. even so, this is strange > thinking. the updated kernel is essential if we're talking about > security. Nobody is saying that you don't want to upgrade the kernel, however many people (like me) don't want our automatic update systems grabbing a new kernel w/out me knowing about it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 rjohnson at medata.com Sat Feb 21 00:46:42 2004 From: rjohnson at medata.com (Rick Johnson) Date: Fri, 20 Feb 2004 16:46:42 -0800 Subject: jumpstarting yum on 7.2 In-Reply-To: <200402201526.44348.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> <200402201526.44348.jkeating@j2solutions.net> Message-ID: <4036AA72.3060802@medata.com> Jesse Keating wrote: > On Friday 20 February 2004 15:12, g wrote: > >>it does appear that the provided yum configuration, and the docs, >>presume we don't want to update the kernel. i realize this is also >>what the default up2date configuration was. even so, this is strange >>thinking. the updated kernel is essential if we're talking about >>security. > > > Nobody is saying that you don't want to upgrade the kernel, however many > people (like me) don't want our automatic update systems grabbing a new > kernel w/out me knowing about it. > IMHO, there's nothing wrong w/ grabbing the new one as long as it's not set as default. Is there a way to tell yum or rpm to install the kernel, but not set as default? It isn't the behavior of RPM, so I have a feeling yum is the culprit. Personally, I let it grab and set as default since kernel's don't scare me as long as I have the old to fall back to :-) I just choose my reboot time carefully in case something does go wrong. That's why when we do it manually, we ivh, not Uvh :-) Now in the case of lights out management setups or remote locations, setting as default Could Be Bad :-/ -Rick -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From drees at greenhydrant.com Sat Feb 21 00:47:32 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 20 Feb 2004 16:47:32 -0800 (PST) Subject: yum and apt differences. In-Reply-To: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> Message-ID: <2269.208.48.139.163.1077324452.squirrel@www.greenhydrant.com> On Fri, February 20, 2004 1at 2:47 pm, Eric Rostetter wrote: > > I've installed the FL versions of yum and apt, and noticed the following > inconsistencies. > > * yum ignores kernel updates by default, but apt doesn't. > * yum doesn't auto install any gpg keys, but apt does. > > Should we not try to make these consistent between yum and apt? Or > is the yum/apt history that says they should act differently? I don't think that apt should automatically install any gpg keys, others have shown the same reservation. apt on Debian does not install kernels by default, you have to use apt-cache to list available kernels and then manually install. Not sure about the history of yum. I don't have a problem with yum installing the latest kernel as it does not make the new kernel the default in the bootloader and does not remove the old kernel, either. As far as making apt install kernels by default, I can't say I recommend it do it either way (so leave it be?). -Dave From cra at WPI.EDU Sat Feb 21 00:56:37 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 20 Feb 2004 19:56:37 -0500 Subject: yum and apt differences. In-Reply-To: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> Message-ID: <20040221005637.GF29673@angus.ind.WPI.EDU> On Fri, Feb 20, 2004 at 02:47:10PM -0600, Eric Rostetter wrote: > * yum ignores kernel updates by default, but apt doesn't. > * yum doesn't auto install any gpg keys, but apt does. > > Should we not try to make these consistent between yum and apt? Or > is the yum/apt history that says they should act differently? I brought this up at the time I packaged yum, but there was no consensus other than yum should behave the same way up2date did (which is why it exludes kernels by default), and root's gpg keyring shouldn't be messed with automatically by the package. Does anyone use apt non-interactively, i.e. via cron? If not, then these differences don't matter too much I guess. I view apt as a nicer user interface, more featureful sysadmin tool to be used interactively, not as an autoupdate mechanism. From rjohnson at medata.com Sat Feb 21 01:05:28 2004 From: rjohnson at medata.com (Rick Johnson) Date: Fri, 20 Feb 2004 17:05:28 -0800 Subject: yum and apt differences. In-Reply-To: <2269.208.48.139.163.1077324452.squirrel@www.greenhydrant.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <2269.208.48.139.163.1077324452.squirrel@www.greenhydrant.com> Message-ID: <4036AED8.8010102@medata.com> David Rees wrote: > I don't think that apt should automatically install any gpg keys, others > have shown the same reservation. Agreed - if you're connecting to an untrusted mirror, it'd be too easy to forge a key and sign malicious packages. > I don't have a problem with yum installing the latest kernel as it does > not make the new kernel the default in the bootloader and does not remove > the old kernel, either. As far as making apt install kernels by default, > I can't say I recommend it do it either way (so leave it be?). In cases where I've run it interactively, it *has* set the new kernel as default. -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From drees at greenhydrant.com Sat Feb 21 01:14:19 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 20 Feb 2004 17:14:19 -0800 (PST) Subject: yum and apt differences. In-Reply-To: <4036AED8.8010102@medata.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <2269.208.48.139.163.1077324452.squirrel@www.greenhydrant.com> <4036AED8.8010102@medata.com> Message-ID: <2393.208.48.139.163.1077326059.squirrel@www.greenhydrant.com> On Fri, February 20, 2004 at 5:05 pm, Rick Johnson wrote: > >> I don't have a problem with yum installing the latest kernel as it does >> not make the new kernel the default in the bootloader and does not >> remove >> the old kernel, either. As far as making apt install kernels by >> default, >> I can't say I recommend it do it either way (so leave it be?). > > In cases where I've run it interactively, it *has* set the new kernel as > default. Hm, I just tried it on my Fedora Core 1 (yum-2.0.4-2) system, maybe it's different for the yum being packaged for Fedora Legacy. I'm using grub, and ran yum update which installed kernel-2.4.22-1.2174.nptl as the first entry in the grub.conf, but also incremented the default so that my old kernel would still boot. IMO, this is a sane way to handle the update, and if the yum being packaged for Fedora Legacy doesn't behave the same way, it should be changed to. -Dave From drees at greenhydrant.com Sat Feb 21 01:16:51 2004 From: drees at greenhydrant.com (David Rees) Date: Fri, 20 Feb 2004 17:16:51 -0800 (PST) Subject: yum and apt differences. In-Reply-To: <20040221005637.GF29673@angus.ind.WPI.EDU> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> Message-ID: <2407.208.48.139.163.1077326211.squirrel@www.greenhydrant.com> On Fri, February 20, 2004 at 4:56 pm, Charles R. Anderson wrote: > On Fri, Feb 20, 2004 at 02:47:10PM -0600, Eric Rostetter wrote: >> * yum ignores kernel updates by default, but apt doesn't. >> * yum doesn't auto install any gpg keys, but apt does. >> >> Should we not try to make these consistent between yum and apt? Or >> is the yum/apt history that says they should act differently? > > I brought this up at the time I packaged yum, but there was no > consensus other than yum should behave the same way up2date did (which > is why it exludes kernels by default), and root's gpg keyring > shouldn't be messed with automatically by the package. > > Does anyone use apt non-interactively, i.e. via cron? If not, then > these differences don't matter too much I guess. I view apt as a > nicer user interface, more featureful sysadmin tool to be used > interactively, not as an autoupdate mechanism. It seems that people either prefer to use yum or apt and tend to not mix the two. People familiar with apt will very likely use it non-interactively via cron, especially those who come from a Debian background. apt for Fedora Legacy should probably behave like the original apt, unless there is a good reason not to. -Dave From jkeating at j2solutions.net Sat Feb 21 01:16:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 20 Feb 2004 17:16:44 -0800 Subject: yum and apt differences. In-Reply-To: <2393.208.48.139.163.1077326059.squirrel@www.greenhydrant.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <4036AED8.8010102@medata.com> <2393.208.48.139.163.1077326059.squirrel@www.greenhydrant.com> Message-ID: <200402201716.49230.jkeating@j2solutions.net> On Friday 20 February 2004 17:14, David Rees wrote: > Hm, I just tried it on my Fedora Core 1 (yum-2.0.4-2) system, maybe > it's different for the yum being packaged for Fedora Legacy. > > I'm using grub, and ran yum update which installed > kernel-2.4.22-1.2174.nptl as the first entry in the grub.conf, but > also incremented the default so that my old kernel would still boot. > > IMO, this is a sane way to handle the update, and if the yum being > packaged for Fedora Legacy doesn't behave the same way, it should be > changed to. The difference might be that FC1 uses yum-2.x while Legacy releases are using yum-1.x. Seth, was there a procedure change between 1.x and 2.x on how yum treats kernels? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Sat Feb 21 03:59:36 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 20 Feb 2004 21:59:36 -0600 Subject: jumpstarting yum on 7.2 In-Reply-To: <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <1077294107.7174.42930.camel@ruby.rub.gnuleaf.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> Message-ID: <20040220215936.y0ow0ws4w0ko00kk@mail.ph.utexas.edu> Quoting g : > On Fri, 2004-02-20 at 20:42, Eric Rostetter wrote: >> Quoting g : >> > # rpm -Uvh --nodeps /tmp/yum-* /tmp/rpm-* /tmp/popt-* >> >> You should not have to use --nodeps. If you do, then something is wrong. > > what is "wrong" is that i did not want to bother to manually download > gnorpm, kdeadmin, et al, which i did not need just to get yum going, and > which would get downloaded automatically anyway when i ran yum update. Ah, okay. Forgot about those strange packages like gnorpm et al. The rpm upgrade process is indeed going to be a pain to document and/or automate... -- Eric Rostetter From rostetter at mail.utexas.edu Sat Feb 21 04:18:19 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 20 Feb 2004 22:18:19 -0600 Subject: yum and apt differences. In-Reply-To: <20040221005637.GF29673@angus.ind.WPI.EDU> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> Message-ID: <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> Quoting "Charles R. Anderson" : > I brought this up at the time I packaged yum, but there was no > consensus other than yum should behave the same way up2date did (which > is why it exludes kernels by default), and root's gpg keyring > shouldn't be messed with automatically by the package. Sounds like apt should follow the same rules then, no? > Does anyone use apt non-interactively, i.e. via cron? I don't think that is relavent really. Why would it matter? > If not, then > these differences don't matter too much I guess. Sure they do. I install apt, run it, and it messes with my root user's key ring. It doesn't even tell me what it is doing to it, just that it is changing it. At least I'd like to know what it is doing, if it's going to do anything at all. > I view apt as a > nicer user interface, more featureful sysadmin tool to be used > interactively, not as an autoupdate mechanism. I don't see how that matters. So, you say to do updates, hope you notice that one of the updates is a kernel update. You don't know what that means, or if it will squash your custom kernel, etc. (Does it upgrade the kernel, so it removes your old one? Does it make the new kernel the default boot kernel? Does it upgrade obsolete modules?) So you have no choice but to abort the whole thing (AFAICT) and then change the apt config files (hopefully you know where they are, how to change them, etc), and then restart the hole update. (Or just roll the dice and see what happens) I guess I would sum it up as: If Red Hat didn't have enough faith in an automatted update of the kernel, then why should we? If we're supposed to change as little as possible for compatability with previous behavior and to avoid surprises to the admin, then shouldn't stick with the way Red Hat did these kinds of things? -- Eric Rostetter From warlock at eskimo.com Sat Feb 21 05:38:55 2004 From: warlock at eskimo.com (Jim Richardson) Date: Fri, 20 Feb 2004 21:38:55 -0800 Subject: yum and apt differences. In-Reply-To: <2407.208.48.139.163.1077326211.squirrel@www.greenhydrant.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> <2407.208.48.139.163.1077326211.squirrel@www.greenhydrant.com> Message-ID: <20040221053855.GA32055@hockwold.net> On Fri, Feb 20, 2004 at 05:16:51PM -0800, David Rees wrote: >On Fri, February 20, 2004 at 4:56 pm, Charles R. Anderson wrote: >> On Fri, Feb 20, 2004 at 02:47:10PM -0600, Eric Rostetter wrote: >>> * yum ignores kernel updates by default, but apt doesn't. * yum >>> doesn't auto install any gpg keys, but apt does. >>> >>> Should we not try to make these consistent between yum and apt? Or >>> is the yum/apt history that says they should act differently? >> >> I brought this up at the time I packaged yum, but there was no >> consensus other than yum should behave the same way up2date did >> (which is why it exludes kernels by default), and root's gpg keyring >> shouldn't be messed with automatically by the package. >> >> Does anyone use apt non-interactively, i.e. via cron? If not, then >> these differences don't matter too much I guess. I view apt as a >> nicer user interface, more featureful sysadmin tool to be used >> interactively, not as an autoupdate mechanism. > >It seems that people either prefer to use yum or apt and tend to not >mix the two. People familiar with apt will very likely use it >non-interactively via cron, especially those who come from a Debian >background. apt for Fedora Legacy should probably behave like the >original apt, unless there is a good reason not to. > I use apt on Debian machines non-interactively, but only to download new stuff, and let me know that I need to run upgrade myself. I use yum on the Fedora-Legacy boxes rather than apt, because I want to make sure I realize they are different than the Debian boxes. I'll probably switch over to apt on them, when I am comfortable doing so. -- Jim Richardson http://www.eskimo.com/~warlock Windows is the answer, but only if the question was 'what is the intellectual equivalent of being a galley slave?' --Larry Smith, in comp.os.linux.misc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From johnlin at ieeeg.com Sat Feb 21 09:49:13 2004 From: johnlin at ieeeg.com (John Lin) Date: Sat, 21 Feb 2004 17:49:13 +0800 Subject: yum and apt differences. In-Reply-To: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> Message-ID: <40372999.2050208@ieeeg.com> It seems that yum have some little problem with 3 of my installations of Fedora. When any package install breaks, it assumes those remaining packages are installed, but they are actually not. It some how marked those packages installed if anything failed during rpm install. When I execute 'yum install failed-package.rpm', it said it is already installed. When I did 'apt-get install failed-package.rpm', it started the installation of that package. This is weird. This creates some problem for me. Anything that I am doing wrong? or there are some bug with yum..? best regards, john Eric Rostetter ??: >I've installed the FL versions of yum and apt, and noticed the following >inconsistencies. > >* yum ignores kernel updates by default, but apt doesn't. >* yum doesn't auto install any gpg keys, but apt does. > >Should we not try to make these consistent between yum and apt? Or >is the yum/apt history that says they should act differently? > >-- >Eric Rostetter >The Department of Physics >The University of Texas at Austin > >Why get even? Get odd! > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > -- This message has been scanned for viruses and dangerous content, and is believed to be clean. From cliff at villagevisions.com Sat Feb 21 13:13:09 2004 From: cliff at villagevisions.com (Cliff Kent) Date: Sat, 21 Feb 2004 08:13:09 -0500 Subject: yum and apt differences. In-Reply-To: <40372999.2050208@ieeeg.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <40372999.2050208@ieeeg.com> Message-ID: <40375965.5020005@villagevisions.com> John, I suggest that you post this question to the yum list: yum at lists.dulug.duke.edu There's been a discussion of things somewhat similar to this recently on that list. Cliff Kent From johnlin at ieeeg.com Sat Feb 21 14:46:26 2004 From: johnlin at ieeeg.com (John Lin) Date: Sat, 21 Feb 2004 22:46:26 +0800 Subject: yum and apt differences. In-Reply-To: <40375965.5020005@villagevisions.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <40372999.2050208@ieeeg.com> <40375965.5020005@villagevisions.com> Message-ID: <40376F42.9080502@ieeeg.com> Cliff, Thx! John Cliff Kent ??: >John, > >I suggest that you post this question to the yum list: > >yum at lists.dulug.duke.edu > >There's been a discussion of things somewhat similar to this recently on >that list. > >Cliff Kent > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > -- This message has been scanned for viruses and dangerous content, and is believed to be clean. From skvidal at phy.duke.edu Sat Feb 21 15:56:33 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 21 Feb 2004 10:56:33 -0500 Subject: yum and apt differences. In-Reply-To: <40372999.2050208@ieeeg.com> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <40372999.2050208@ieeeg.com> Message-ID: <1077378993.20379.14.camel@binkley> On Sat, 2004-02-21 at 17:49 +0800, John Lin wrote: > It seems that yum have some little problem with 3 of my installations of > Fedora. When any package install breaks, it assumes those remaining > packages are installed, but they are actually not. It some how marked > those packages installed if anything failed during rpm install. When I > execute 'yum install failed-package.rpm', it said it is already > installed. When I did 'apt-get install failed-package.rpm', it started > the installation of that package. This is weird. > > This creates some problem for me. Anything that I am doing wrong? or > there are some bug with yum..? > What version of yum are you seeing this on? Just to be sure you're see: yum install foo bar baz during the install foo fails and yum exits - yum is reporting that bar and baz succeeds? Can you demonstrate this behavior? what version of rhl? what version of rpm? -sv From jkeating at j2solutions.net Sat Feb 21 17:33:49 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 21 Feb 2004 09:33:49 -0800 Subject: Fedora Legacy Test Update Notification: Kernel Message-ID: <200402210933.54570.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1284 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1284 2004-02-21 - --------------------------------------------------------------------- Name : kernel Version 7.x : 2.4.20-30.7.legacy Version 8.0 : 2.4.20-30.8.legacy Summary : The Linux kernel (the core of the Linux operating system) Description : The kernel package contains the Linux kernel (vmlinuz), the core of your Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. - --------------------------------------------------------------------- Update Information: CAN-2004-0077: A flaw in return value checking in mremap() in the Linux kernel versions 2.4.24 and previous that may allow a local attacker to gain root privileges. No exploit is currently available; however this issue is exploitable. CAN-2004-0075: The Vicam USB driver in kernel versions prior to 2.4.25 does not use the copy_from_user function to access userspace, which crosses security boundaries. CAN-2004-0010: A flaw in ncp_lookup() in ncpfs that could allow local privilege escalation. ncpfs is only used to allow a system to mount volumes of NetWare servers or print to NetWare printers. CAN-2004-0003: Issues in the R128 Direct Render Infrastructure that could allow local privilege escalation. - --------------------------------------------------------------------- Changelog: * Thu Feb 19 2004 Jesse Keating - - Disabled nptl for 7.x/8 build. Added .legacy tag. * Thu Feb 05 2004 Dave Jones - - Check do_mremap return values (CAN-2004-0077) * Mon Feb 02 2004 Dave Jones - - Fix NCPFS deep stack usage. (CAN-2004-0010) * Fri Jan 16 2004 Dave Jones - - Check limits in R128 DRI drivers. (CAN-2004-0003) - - Fix user/kernel copying in Vicam USB driver. (CAN-2004-0075) - - Fix user/kernel copying in DRI GAMMA driver. - - Fix another NPTL local DoS. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 4b1d86c6b9c706d5ed9561a2c4fc0628528ddc86 7.2/updates-testing/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm f97d96d3238aa1bb314896699e280a31ed85529d 7.2/updates-testing/i386/kernel-2.4.20-30.7.legacy.athlon.rpm cf0e03315d942140fbb439521684705d25e59a8f 7.2/updates-testing/i386/kernel-2.4.20-30.7.legacy.i386.rpm d3e0a7b68e06af4045cd4f66d0a5864920dbd5b5 7.2/updates-testing/i386/kernel-2.4.20-30.7.legacy.i586.rpm debfa2741248dccffdade72b8efe3b94d0e2483c 7.2/updates-testing/i386/kernel-2.4.20-30.7.legacy.i686.rpm 989873968805dca5a7abd47dfb0c6dfca8a110b4 7.2/updates-testing/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm 17a5a3b267339f1b20870cdcf586f5784b632358 7.2/updates-testing/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm 15c40d84c061917f08e0c6b540bc49999ed18599 7.2/updates-testing/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm f1460dafa968105647f38983d795b2693692fbfd 7.2/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm 15f1ac18efcf20c6f7c2f1fdcd803562704e507f 7.2/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm 3c0fdeb92cd1d549b643bf91429dd1b79a067e77 7.2/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm c64a8cef6e9ec35454a397229b2a15a60bba5322 7.2/updates-testing/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm 4b1d86c6b9c706d5ed9561a2c4fc0628528ddc86 7.3/updates-testing/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm f97d96d3238aa1bb314896699e280a31ed85529d 7.3/updates-testing/i386/kernel-2.4.20-30.7.legacy.athlon.rpm cf0e03315d942140fbb439521684705d25e59a8f 7.3/updates-testing/i386/kernel-2.4.20-30.7.legacy.i386.rpm d3e0a7b68e06af4045cd4f66d0a5864920dbd5b5 7.3/updates-testing/i386/kernel-2.4.20-30.7.legacy.i586.rpm debfa2741248dccffdade72b8efe3b94d0e2483c 7.3/updates-testing/i386/kernel-2.4.20-30.7.legacy.i686.rpm 989873968805dca5a7abd47dfb0c6dfca8a110b4 7.3/updates-testing/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm 17a5a3b267339f1b20870cdcf586f5784b632358 7.3/updates-testing/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm 15c40d84c061917f08e0c6b540bc49999ed18599 7.3/updates-testing/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm f1460dafa968105647f38983d795b2693692fbfd 7.3/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm 15f1ac18efcf20c6f7c2f1fdcd803562704e507f 7.3/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm 3c0fdeb92cd1d549b643bf91429dd1b79a067e77 7.3/updates-testing/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm c64a8cef6e9ec35454a397229b2a15a60bba5322 7.3/updates-testing/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm 8eea381f80412a9421d25b1466d084cbbf5e1cee 8.0/updates-testing/SRPMS/kernel-2.4.20-30.8.legacy.src.rpm 77ee4d29f593a4746e70a6ac55f9791d3183803e 8.0/updates-testing/i386/kernel-2.4.20-30.8.legacy.athlon.rpm b1ba3b73d03294d4b31756eb6086bfffd4ef9958 8.0/updates-testing/i386/kernel-2.4.20-30.8.legacy.i386.rpm cd49df62f704ed4e11be197fdae0920de1e1c584 8.0/updates-testing/i386/kernel-2.4.20-30.8.legacy.i586.rpm 467c2613862985f16e07db103d7d88ab914ea73c 8.0/updates-testing/i386/kernel-2.4.20-30.8.legacy.i686.rpm 63e243113b85a57ccaaaf0bcdf1468d7f8290001 8.0/updates-testing/i386/kernel-BOOT-2.4.20-30.8.legacy.i386.rpm ea960ffbacd83cdb2b0ae78e612da5099121f77c 8.0/updates-testing/i386/kernel-bigmem-2.4.20-30.8.legacy.i686.rpm 842cea04dad3976173afb6609c19615eff88aa8a 8.0/updates-testing/i386/kernel-doc-2.4.20-30.8.legacy.i386.rpm e07e04ffef20d0f3fd66cd8cc46d7f2d7d1c2af0 8.0/updates-testing/i386/kernel-smp-2.4.20-30.8.legacy.athlon.rpm a2a81a0ebe3e7433e339881bd1ba6177f75599c8 8.0/updates-testing/i386/kernel-smp-2.4.20-30.8.legacy.i586.rpm 8625244b0dca1a71fe9b74769f6376af9495b333 8.0/updates-testing/i386/kernel-smp-2.4.20-30.8.legacy.i686.rpm 4f6b05bc2296a0b37bc9528fd0e36d4e8f69ff67 8.0/updates-testing/i386/kernel-source-2.4.20-30.8.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) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAN5aC4v2HLvE71NURAvq8AJ94CA4qs4mpiZH2KPu86yKS9wKOmQCgocyg 1WFOby56dXOMZMPOJQllvmk= =jsST -----END PGP SIGNATURE----- From cra at WPI.EDU Sat Feb 21 17:55:06 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 21 Feb 2004 12:55:06 -0500 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <200402210933.54570.jkeating@j2solutions.net> References: <200402210933.54570.jkeating@j2solutions.net> Message-ID: <20040221175506.GG29673@angus.ind.WPI.EDU> On Sat, Feb 21, 2004 at 09:33:49AM -0800, Jesse Keating wrote: > CAN-2004-0077: > A flaw in return value checking in mremap() in the Linux kernel versions > 2.4.24 and previous that may allow a local attacker to gain root > privileges. No exploit is currently available; however this issue is > exploitable. -------------- next part -------------- An embedded message was scrubbed... From: Ulrich Keil Subject: Re: [RHSA-2004:065-01] Updated kernel packages resolve security vulnerabilities Date: Wed, 18 Feb 2004 17:58:49 +0100 Size: 2778 URL: From jkeating at j2solutions.net Sat Feb 21 18:11:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 21 Feb 2004 10:11:05 -0800 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <20040221175506.GG29673@angus.ind.WPI.EDU> References: <200402210933.54570.jkeating@j2solutions.net> <20040221175506.GG29673@angus.ind.WPI.EDU> Message-ID: <200402211011.05609.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 21 February 2004 09:55, Charles R. Anderson wrote: > On Sat, Feb 21, 2004 at 09:33:49AM -0800, Jesse Keating wrote: > > CAN-2004-0077: > > A flaw in return value checking in mremap() in the Linux kernel > > versions 2.4.24 and previous that may allow a local attacker to gain > > root privileges. No exploit is currently available; however this issue > > is exploitable. I'll note this when we move it to updates. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAN5854v2HLvE71NURAqsUAKCNeCIN8NipQbLst3K6fekoUqLmSQCfXXXG w+yZlAH0hmnmsOB1EM4lE8A= =fw3n -----END PGP SIGNATURE----- From davej at redhat.com Sat Feb 21 18:44:26 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 21 Feb 2004 18:44:26 +0000 Subject: Fedora Legacy Test Update Notification: Kernel In-Reply-To: <20040221175506.GG29673@angus.ind.WPI.EDU> References: <200402210933.54570.jkeating@j2solutions.net> <20040221175506.GG29673@angus.ind.WPI.EDU> Message-ID: <20040221184426.GB839@redhat.com> On Sat, Feb 21, 2004 at 12:55:06PM -0500, Charles R. Anderson wrote: > > Paul Starzetz discovered a flaw in return value checking in mremap() > > in the Linux kernel versions 2.4.24 and previous that may allow a local > > attacker to gain root privileges. No exploit is currently available; > > ... > > There is an Proof-of-concept exploit available: > > http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html that's "crash the box" exploit as opposed to "get local root", which is what the 'no exploit' refers to in the original Red Hat advisory. Dave From ivan at geosci.usyd.edu.au Mon Feb 23 02:27:19 2004 From: ivan at geosci.usyd.edu.au (Ivan Teliatnikov) Date: Mon, 23 Feb 2004 13:27:19 +1100 (EST) Subject: Installing test kernel using APT. Message-ID: Hi there, I want to install test kernel using APT. I have made a local mirror of fredora-legacy APT repository using RSYNC tool and placed appropriate lines into /etc/apt/sources.list file rpm ftp://mirror.geosci.usyd.edu.au/download.fedoralegacy.org/apt redhat/8.0/i386 os updates rpm ftp://mirror.geosci.usyd.edu.au/download.fedoralegacy.org/apt redhat/8.0/i386 legacy-utils rpm ftp://mirror.geosci.usyd.edu.au/download.fedoralegacy.org/apt redhat/8.0/i386 updates-testing Running apt-get update; apt-get install kernel; shows a list of kernel available. in "os updates" directory. It does not lists kernels located in updates-testing. How do I make packages (e.g.kernel) located in updates-testing visible from an apt-get client? -- ================================================================================ Ivan Teliatnikov phone: +61 2 9351 2031 fax: +61 2 9351 0184 mobile_phone: +61 402 173 179 email: ivan at es.usyd.edu.au School of Geosciences F05 - Edgeworth David Building The University of Sydney NSW 2006 Australia =============================================================================== From skvidal at phy.duke.edu Mon Feb 23 04:58:37 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Feb 2004 23:58:37 -0500 Subject: yum and apt differences. In-Reply-To: <200402201716.49230.jkeating@j2solutions.net> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <4036AED8.8010102@medata.com> <2393.208.48.139.163.1077326059.squirrel@www.greenhydrant.com> <200402201716.49230.jkeating@j2solutions.net> Message-ID: <1077512317.22711.33.camel@binkley> > The difference might be that FC1 uses yum-2.x while Legacy releases are > using yum-1.x. Seth, was there a procedure change between 1.x and 2.x > on how yum treats kernels? no - no change. -sv From pmatilai at welho.com Mon Feb 23 07:23:15 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 23 Feb 2004 09:23:15 +0200 (EET) Subject: yum and apt differences. In-Reply-To: <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> Message-ID: On Fri, 20 Feb 2004, Eric Rostetter wrote: > Quoting "Charles R. Anderson" : > > > I brought this up at the time I packaged yum, but there was no > > consensus other than yum should behave the same way up2date did (which > > is why it exludes kernels by default), and root's gpg keyring > > shouldn't be messed with automatically by the package. > > Sounds like apt should follow the same rules then, no? The matter is a bit different on RHL 7.x since there it's indeed messing with roots gpg keyring (doesn't have to be that way, you could just as well make the gpg-checker script import to alternate keyring and check from there), on rpm >= 4.1 the keys get imported into rpmdb. That was a feature people wanted for fedora.us apt, if you don't like the auto-import of keys then either a) make it use alternative keyring b) expect to deal with lotsa people complaining about unknown signatures :) > > > Does anyone use apt non-interactively, i.e. via cron? > > I don't think that is relavent really. Why would it matter? > > > If not, then > > these differences don't matter too much I guess. > > Sure they do. I install apt, run it, and it messes with my root user's > key ring. It doesn't even tell me what it is doing to it, just that it > is changing it. At least I'd like to know what it is doing, if it's > going to do anything at all. See above, also no reason why you couldn't make that interactive... > > > I view apt as a > > nicer user interface, more featureful sysadmin tool to be used > > interactively, not as an autoupdate mechanism. > > I don't see how that matters. So, you say to do updates, hope you notice > that one of the updates is a kernel update. You don't know what that means, > or if it will squash your custom kernel, etc. (Does it upgrade the kernel, > so it removes your old one? Does it make the new kernel the default boot > kernel? Does it upgrade obsolete modules?) So you have no choice but to > abort the whole thing (AFAICT) and then change the apt config files > (hopefully you know where they are, how to change them, etc), and then > restart the hole update. (Or just roll the dice and see what happens) > > I guess I would sum it up as: If Red Hat didn't have enough faith in > an automatted update of the kernel, then why should we? If we're supposed > to change as little as possible for compatability with previous behavior and > to avoid surprises to the admin, then shouldn't stick with the way Red Hat > did these kinds of things? First people complain about apt not upgrading kernels and when it finally does people complain about that :) Fedoralegacy apt is yours to configure as you please, just ship with different defaults than fedora.us apt if these things bother you: RPM::Upgrade-Virtual=false (to prevent automatic kernel "upgrades", it doesn't upgrade the package but installs a new one like it should) Kernel::Set-Default=false (don't make the new kernel default) I had a discussion about this with Seth a while ago on IRC and agreed that for most new(ish) users it's probably the right thing to do (upgrade kernel, make it default), experienced admins and such can change the default settings as they please (eg on server you might not want that automated kernel update or making it default) - Panu - From keb at ctinetworks.com Tue Feb 24 01:13:33 2004 From: keb at ctinetworks.com (Kevin Bonner) Date: Mon, 23 Feb 2004 20:13:33 -0500 Subject: Installing test kernel using APT. In-Reply-To: References: Message-ID: <200402232013.38265.keb@ctinetworks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A quick look at /8.0/i386/base on your ftp server shows that pkglist.updates-testing.bz2 was last modified on 02/12/2004. I would run your apt repository script again for the updates-testing module. Once that is done, run your two apt-get commands again and everything _should_ work. Kevin Bonner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAOqVB/9i/ml3OBYMRAufAAJ4nb/vzoWg7AINirXRJAQ0O73eOtwCbBXti cNBFoxqQaX2p1rRjrO2MYiU= =804h -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Tue Feb 24 01:40:22 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 23 Feb 2004 19:40:22 -0600 Subject: yum and apt differences. In-Reply-To: References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> Message-ID: <20040223194022.vc40go4osw4ooog0@mail.ph.utexas.edu> Quoting Panu Matilainen : > The matter is a bit different on RHL 7.x since there it's indeed messing > with roots gpg keyring (doesn't have to be that way, you could just as > well make the gpg-checker script import to alternate keyring and check > from there), on rpm >= 4.1 the keys get imported into rpmdb. Good point, which I once knew and then forgot about. Thanks for pointing that out again. >> Sure they do. I install apt, run it, and it messes with my root user's >> key ring. It doesn't even tell me what it is doing to it, just that it >> is changing it. At least I'd like to know what it is doing, if it's >> going to do anything at all. > > See above, also no reason why you couldn't make that interactive... Actually, I'd settle for it just telling me what it is doing, but asking me if I wanted it to do it would be even better. > First people complain about apt not upgrading kernels and when it finally > does people complain about that :) True. But note that we're talking about the default setting, and not the capability. > Fedoralegacy apt is yours to configure > as you please, just ship with different defaults than fedora.us apt if > these things bother you: What bothers me, I suppose, is that it FL-apt is acting the opposite of FL-yum. I'd rather, for what ever reason, see them act the same as much as possible. > I had a discussion about this with Seth a while ago on IRC and agreed that > for most new(ish) users it's probably the right thing to do (upgrade > kernel, make it default) Incidently, I was using FL-yum today and what I saw was: * It installs (not upgrades) the kernel in all cases * If it finds grub, it makes the new kernel the default * If it finds lilo, it fails to make the new kernel the default (at least for me) > experienced admins and such can change the > default settings as they please (eg on server you might not want that > automated kernel update or making it default) My view is the FL was to provide no surprises from previous RHL behaviour. Previous RHL behaviour in up2date was to not update kernels by default. So to provide no surprises, we would not update kernels by default. I'm flexible though. I only brought it up because I noticed that apt and yum acted differently, not because I really care that much if the kernel gets updated or not. > - Panu - -- Eric Rostetter From mvano at vano.com Mon Feb 23 21:32:38 2004 From: mvano at vano.com (Mario Vano) Date: Mon, 23 Feb 2004 15:32:38 -0600 Subject: can't subscribe Message-ID: <403A7176.80304@vano.com> I've tried twice now to subscribe to the list, but each time I never get the confirmation message. Is this a problem with your message looking like spam or a virus to isp filters, or isn't your list server sending it to me? Mario Vano From jkeating at j2solutions.net Tue Feb 24 04:43:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Feb 2004 20:43:54 -0800 Subject: can't subscribe In-Reply-To: <403A7176.80304@vano.com> References: <403A7176.80304@vano.com> Message-ID: <200402232043.59041.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 23 February 2004 13:32, Mario Vano wrote: > I've tried twice now to subscribe to the list, but each time I never get > the confirmation message. > > Is this a problem with your message looking like spam or a virus to isp > filters, or isn't your list server sending it to me? I don't know whats going on, but I've manually subscribed you to the list. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAOtaO4v2HLvE71NURArZoAKCS8aCginSsNVSWTDv7Pe3kdCBMvACdFFwA I2zqFVf1u5c1y3xfbjm5xYw= =MRU8 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Feb 24 05:56:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Feb 2004 21:56:35 -0800 Subject: Fedora Legacy Test Update Notification: mailman Message-ID: <200402232156.41320.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1269 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1269 2004-02-23 - --------------------------------------------------------------------- Name : mailman Version 7.x : 2.0.14-0.7.x.1.legacy Version 8.0 : 2.0.14-0.8.0.1.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. When the package has finished installing, you will need to: * Run /var/mailman/bin/mmsitepass to set the mailman administrator password. * Edit /var/mailman/Mailman/mm_cfg.py to configure Mailman for your site. * Add "Include conf/httpd-mailman.conf" to /etc/httpd/conf/httpd.conf. Users upgrading from previous releases of this package may need to move their data or adjust the configuration files to point to the locations where their data is. - --------------------------------------------------------------------- Update Information: CAN-2003-0991: Vulnerability in the mail command handler in Mailman before 2.0.14 allows remote attackers to cause a denial of service (crash) via malformed e-mail commands. - --------------------------------------------------------------------- Changelog: * Mon Feb 23 2004 Jesse Keating - - 2.0.14-0.7.x.1.legacy - - Changed to 7.x as it will work across both. * Sun Feb 08 2004 Seth Vidal 2.0.14-0.7.3.1.legacy - - patch only - updates to 2.0.14 - not official tar release - - deals with CVE CAN-2003-0991 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ c07e2c370716c93e170c7a579827ed20fbaf5321 7.2/updates-testing/SRPMS/mailman-2.0.14-0.7.x.1.legacy.src.rpm 98bfc33970d689e18dd7ddae10fab4ee90a52db9 7.2/updates-testing/i386/mailman-2.0.14-0.7.x.1.legacy.i386.rpm c07e2c370716c93e170c7a579827ed20fbaf5321 7.3/updates-testing/SRPMS/mailman-2.0.14-0.7.x.1.legacy.src.rpm 98bfc33970d689e18dd7ddae10fab4ee90a52db9 7.3/updates-testing/i386/mailman-2.0.14-0.7.x.1.legacy.i386.rpm 8877213c0c0ba8eccd0f5afcbe64c2e00d650863 8.0/updates-testing/SRPMS/mailman-2.0.14-0.8.0.1.legacy.src.rpm 05e7c4f494a10f63afb183c58086935d9ea3421c 8.0/updates-testing/i386/mailman-2.0.14-0.8.0.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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAOueZ4v2HLvE71NURApukAJ4q86rU52Q2ANS49L2Y8I1d6zDwOQCfY1B9 f3DrUZlidkT9wa8mz3RjLGM= =ZTWa -----END PGP SIGNATURE----- From pmatilai at welho.com Tue Feb 24 07:44:57 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 24 Feb 2004 09:44:57 +0200 (EET) Subject: yum and apt differences. In-Reply-To: <20040223194022.vc40go4osw4ooog0@mail.ph.utexas.edu> References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> <20040223194022.vc40go4osw4ooog0@mail.ph.utexas.edu> Message-ID: On Mon, 23 Feb 2004, Eric Rostetter wrote: > Quoting Panu Matilainen : > > > The matter is a bit different on RHL 7.x since there it's indeed messing > > with roots gpg keyring (doesn't have to be that way, you could just as > > well make the gpg-checker script import to alternate keyring and check > > from there), on rpm >= 4.1 the keys get imported into rpmdb. > > Good point, which I once knew and then forgot about. Thanks for pointing > that out again. > > >> Sure they do. I install apt, run it, and it messes with my root user's > >> key ring. It doesn't even tell me what it is doing to it, just that it > >> is changing it. At least I'd like to know what it is doing, if it's > >> going to do anything at all. > > > > See above, also no reason why you couldn't make that interactive... > > Actually, I'd settle for it just telling me what it is doing, but asking > me if I wanted it to do it would be even better. IIRC the reason I made it automated in the script instead of being interactive was that if it's interactive, synaptic just plain hangs while waiting for output in terminal which doesn't exist. That could be avoided with synaptic >= 0.47 though (synaptic now allows detection which one is running) > > > First people complain about apt not upgrading kernels and when it finally > > does people complain about that :) > > True. But note that we're talking about the default setting, and not > the capability. > > > Fedoralegacy apt is yours to configure > > as you please, just ship with different defaults than fedora.us apt if > > these things bother you: > > What bothers me, I suppose, is that it FL-apt is acting the opposite > of FL-yum. I'd rather, for what ever reason, see them act the same > as much as possible. > > > I had a discussion about this with Seth a while ago on IRC and agreed that > > for most new(ish) users it's probably the right thing to do (upgrade > > kernel, make it default) > > Incidently, I was using FL-yum today and what I saw was: > > * It installs (not upgrades) the kernel in all cases > * If it finds grub, it makes the new kernel the default > * If it finds lilo, it fails to make the new kernel the default (at least for > me) Sorry but I don't see how that's the "opposite" of what apt does, actually it's identical to what the FL-apt does in default configuration. > > > experienced admins and such can change the > > default settings as they please (eg on server you might not want that > > automated kernel update or making it default) > > My view is the FL was to provide no surprises from previous RHL behaviour. > Previous RHL behaviour in up2date was to not update kernels by default. > So to provide no surprises, we would not update kernels by default. > > I'm flexible though. I only brought it up because I noticed that apt > and yum acted differently, not because I really care that much if the > kernel gets updated or not. No surprises is good thing certainly, and I don't care one way or the another, just ask Jason and not me if the defaults need to be changed for FL-apt. It's just that I fail to see how's the behavior different from FL-yum :) - Panu - From jkeating at j2solutions.net Tue Feb 24 07:53:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Feb 2004 23:53:51 -0800 Subject: Fedora Legacy Test Update Notification: mc Message-ID: <200402232353.51667.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1224 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1224 2004-02-23 - --------------------------------------------------------------------- Name : mc Version 7.2 : 4.5.51-37.legacy Version 7.3 : mc-4.5.55-6.legacy Version 8.0 : mc-4.5.55-13.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-2003-1023: Stack-based buffer overflow in vfs_s_resolve_symlink of vfs/direntry.c for Midnight Commander (mc) 4.6.0 and earlier, and possibly later versions, allows remote attackers to execute arbitrary code during symlink conversion. - --------------------------------------------------------------------- Changelog: * Sun Jan 25 2004 Michael Schwendt - - Fix up missing build requirements. - - Move PAM dependency to mcserv package. * Sun Jan 18 2004 Jesse Keating - - updated to 4.5.51-37.legacy - - added patch for CAN-2003-1023 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 9f8a003f130fa1f9a97c77bb481791445885f1b5 7.2/updates-testing/SRPMS/mc-4.5.51-37.legacy.src.rpm b9a4452ffc5d1aaf99fcc2eff940dd6252c24446 7.2/updates-testing/i386/mc-4.5.51-37.legacy.i386.rpm 8c3ff32790268aa8d38e3b0c2a63da6c8b603363 7.2/updates-testing/i386/mcserv-4.5.51-37.legacy.i386.rpm f62558a3f57a388887376be2d3ede32334e4099d 7.2/updates-testing/i386/gmc-4.5.51-37.legacy.i386.rpm 045b05e94d3971759110bf6e5faf3797e8c771f1 7.3/updates-testing/SRPMS/mc-4.5.55-6.legacy.src.rpm d56d82b210636fe30c09d0ce09b38cf8572e4ab5 7.3/updates-testing/i386/mc-4.5.55-6.legacy.i386.rpm be63f46bf7e3b003b9d07a731ee158ec33215ff6 8.0/updates-testing/SRPMS/mc-4.5.55-13.legacy.src.rpm 34cfea3816c76dba42e3fb1ac4f15c6b48704b2d 8.0/updates-testing/i386/mc-4.5.55-13.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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAOwMP4v2HLvE71NURAryhAKCADo2MF+EtYqKN/VfyNn068IWBLQCgvJ5z YxeDZLasOHYV+Us7hxm1gAM= =Laru -----END PGP SIGNATURE----- From mvano at vano.com Tue Feb 24 14:25:14 2004 From: mvano at vano.com (Mario Vano) Date: Tue, 24 Feb 2004 08:25:14 -0600 Subject: can't subscribe In-Reply-To: <200402232043.59041.jkeating@j2solutions.net> References: <403A7176.80304@vano.com> <200402232043.59041.jkeating@j2solutions.net> Message-ID: <403B5ECA.6090300@vano.com> Thanks, I think a lot of mail systems were acting strangely yesterday. I finally received a confirmation message and did reply to it this morning for completeness of your opt-in records, but at the same time I also received some list messages, so I think everything's fine anyway. thanks again Mario Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 23 February 2004 13:32, Mario Vano wrote: > >>I've tried twice now to subscribe to the list, but each time I never get >>the confirmation message. >> >>Is this a problem with your message looking like spam or a virus to isp >>filters, or isn't your list server sending it to me? > > > I don't know whats going on, but I've manually subscribed you to the list. > > - -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAOtaO4v2HLvE71NURArZoAKCS8aCginSsNVSWTDv7Pe3kdCBMvACdFFwA > I2zqFVf1u5c1y3xfbjm5xYw= > =MRU8 > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From ms-nospam-0306 at arcor.de Tue Feb 24 14:45:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 24 Feb 2004 15:45:20 +0100 Subject: can't subscribe In-Reply-To: <403B5ECA.6090300@vano.com> References: <403A7176.80304@vano.com> <200402232043.59041.jkeating@j2solutions.net> <403B5ECA.6090300@vano.com> Message-ID: <20040224154520.4ebb13b1.ms-nospam-0306@arcor.de> On Tue, 24 Feb 2004 08:25:14 -0600, Mario Vano wrote: > Thanks, I think a lot of mail systems were acting strangely yesterday. This list is hosted at redhat.com, too, and hence suffered from the same problems as the other public mailing-lists yesterday: no delivery of messages for almost a day. Has happened before and might happen again, depending on what the cause of it is. Patience is the key. -- From rostetter at mail.utexas.edu Tue Feb 24 16:05:41 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 24 Feb 2004 10:05:41 -0600 Subject: yum and apt differences. In-Reply-To: References: <20040220144710.e4ptkw0kwg400k88@mail.ph.utexas.edu> <20040221005637.GF29673@angus.ind.WPI.EDU> <20040220221819.u84gw0s40kg8owkk@mail.ph.utexas.edu> <20040223194022.vc40go4osw4ooog0@mail.ph.utexas.edu> Message-ID: <20040224100541.3msk4800g0kwowg0@mail.ph.utexas.edu> Quoting Panu Matilainen : >> Incidently, I was using FL-yum today and what I saw was: >> >> * It installs (not upgrades) the kernel in all cases >> * If it finds grub, it makes the new kernel the default >> * If it finds lilo, it fails to make the new kernel the default (at >> least for >> me) > > Sorry but I don't see how that's the "opposite" of what apt does, actually > it's identical to what the FL-apt does in default configuration. This was just an "incidently" mention of how yum works, since over the past several days there was a discussion and many questions about whether kernels where upgraded vs installed, and if they were set to default or not. So I was setting the record straight based on my observation after upgrading a few dozen machines. If indeed apt does the same, then that is great! I was not trying in any way to compare it to apt, or imply apt was different. I guess the original thread split into multiple threads, and now I'm mixing my answers back as one thread, which is perhaps confusing people. > No surprises is good thing certainly, and I don't care one way or the > another, just ask Jason and not me if the defaults need to be changed for > FL-apt. It's just that I fail to see how's the behavior different from > FL-yum :) One defaults to not installing the kernel updates, the other defaults to installing the kernel updates. That is the difference, plain and simple. Shucks, let's just drop the whole thing. Let's get apt published, different or not. I'll document the differences, and people can just deal with it. I was just trying to see if we couldn't make them the same as it makes the documentation easier, less FAQ hassle, etc. But when it comes down to it, we can handle FAQ chatter, and write more docs, and I'd rather have to answer the same question constantly about apt or yum than to not have them available for use while we endlessly debate trivial differences. So, I'm ending the thread (as far as my input goes). If anyone wants to take up the cause, then great. If not, let's get apt out the door, and I'll just document all the quirks of using apt and yum. > - Panu - -- Eric Rostetter From jkeating at j2solutions.net Wed Feb 25 05:08:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 Feb 2004 21:08:23 -0800 Subject: Fedora Legacy Test Update Notification: pwlib Message-ID: <200402242108.27931.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1296 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1296 2004-02-24 - --------------------------------------------------------------------- Name : pwlib Version 7.3 : 1.2.12-4.legacy Version 8.0 : 1.3.3-6.legacy Summary : Portable Windows Libary Description : PWLib is a moderately large class library that has its genesis many years ago as a method to produce applications to run on both Microsoft Windows and Unix X-Window systems. It also was to have a Macintosh port as well but this never eventuated. This version does not contain any UI code. It is supplied mainly to support the open H323 project, but that shouldn't stop you from using it in whatever project you have in mind if you so desire. - --------------------------------------------------------------------- Update Information: CAN-2004-0097: Multiple vulnerabilities in PWLib before 1.6.0 allow remote attackers to cause a denial of service and possibly execute arbitrary code, as demonstrated by the NISCC/OUSPG PROTOS test suite for the H.225 protocol. - --------------------------------------------------------------------- Changelog: * Tue Feb 24 2004 Jesse Keating - - 1.2.12-4.legacy - - Make version change less obnoxious. No conflict with upstream * Sun Feb 15 2004 Johnny Strom - - Fix some range checks in asn parser CAN-2004-0097 - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 083f52e7339aabe4b123506b37d6638fd6ff0114 7.3/updates-testing/SRPMS/pwlib-1.2.12-4.legacy.src.rpm bfccb74ebed5ae978ca99efe0e33504a27efcb66 7.3/updates-testing/i386/pwlib-1.2.12-4.legacy.i386.rpm 4540e6e0cb3cf8d388dda9616d5ca6d0818afc7f 7.3/updates-testing/i386/pwlib-devel-1.2.12-4.legacy.i386.rpm 798cc21e3741fd7a984ba8f8287f1ceaac84a3ae 8.0/updates-testing/SRPMS/pwlib-1.3.3-6.legacy.src.rpm 5b7f740057678c6d0ce83a7aefec56a7cc69a0eb 8.0/updates-testing/i386/pwlib-1.3.3-6.legacy.i386.rpm 6c35dd204c72d5ffb114d63dcc1fce733050b511 8.0/updates-testing/i386/pwlib-devel-1.3.3-6.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) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAPC3L4v2HLvE71NURAkTWAKDFe+bLCHG/WUJz7ByY3fvqBbfZcACgn5W0 B0wkw2cJCGvKfHg8oAkxwyc= =Tait -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Feb 25 06:23:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 Feb 2004 22:23:07 -0800 Subject: Fedora Legacy Test Update Notification: mutt Message-ID: <200402242223.07288.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1285 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1285 2004-02-24 - --------------------------------------------------------------------- Name : mutt Version 8.0 : 1.4.1-0.8.x.1.legacy Release : 0.8.x.1.legacy Summary : A text mode mail user agent. Description : Mutt is a text-mode mail user agent. Mutt supports color, threading, arbitrary key remapping, and a lot of customization. You should install mutt if you have used it in the past and you prefer it, or if you are new to mail programs and have not decided which one you are going to use. - --------------------------------------------------------------------- Update Information: CAN-2004-0078: Buffer overflow in the index menu code (menu_pad_string of menu.c) for Mutt 1.4.1 and earlier allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via certain mail messages. - --------------------------------------------------------------------- Changelog: * Wed Feb 11 2004 Todd Zullinger 5:1.4.1-0.8.x.1.legacy - - patch to fix CAN-2004-0078 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0078 - - s/Serial/Epoch/ - - s/BuildPrereq/BuildRequires/ - - add BuildRequires: cyrus-sasl-devel - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ b7e95c02951c5b412d3c08abd90fbd03db89e1dd 8.0/updates-testing/SRPMS/mutt-1.4.1-0.8.x.1.legacy.src.rpm 3d2b3c5631252abc13959f87a164bf3f96459997 8.0/updates-testing/i386/mutt-1.4.1-0.8.x.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) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAPD9L4v2HLvE71NURAl5hAKCs7x7C85ZOcwuM3dTY22zSGe4/kgCgtcpW kvk9vbH0pP7ODQBZtPvtdtc= =HM8V -----END PGP SIGNATURE----- From gmott at ntlworld.com Wed Feb 25 11:16:27 2004 From: gmott at ntlworld.com (g) Date: Wed, 25 Feb 2004 11:16:27 +0000 Subject: jumpstarting yum on 7.2 In-Reply-To: <200402201526.44348.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> <200402201526.44348.jkeating@j2solutions.net> Message-ID: <1077707787.23896.194.camel@ruby.rub.gnuleaf.net> On Fri, 2004-02-20 at 23:26, Jesse Keating wrote: > On Friday 20 February 2004 15:12, g wrote: > > it does appear that the provided yum configuration, and the docs, > > presume we don't want to update the kernel. i realize this is also > > what the default up2date configuration was. even so, this is strange > > thinking. the updated kernel is essential if we're talking about > > security. > > Nobody is saying that you don't want to upgrade the kernel, however many > people (like me) don't want our automatic update systems grabbing a new > kernel w/out me knowing about it. actually i don't see the point. a new kernel gets downloaded, and even entered into grub.conf as a choice, but the previous default boot kernel is not changed. so what's the worry? (; heck if i were to take issue with things that get automatically updated, it would be that package updates in general seem to think that the right thing to do is to install their startup links in /etc/rc.d/rcN.d, even though there were no links for that package in there before the update, which means that after every automatic update, i have to throw out the contents of all the /etc/rc.d/rcN.d and put in there (only) what i want in there. but come to think of it, i have read that debian does the Right Thing there, so perhaps there is hope over the horizon. ;) From bart.martens at chello.be Wed Feb 25 11:36:39 2004 From: bart.martens at chello.be (Bart Martens) Date: Wed, 25 Feb 2004 12:36:39 +0100 Subject: keyword LEGACY missing in doc Message-ID: <1077708999.5215.11.camel@localhost.localdomain> Page http://www.fedoralegacy.org/ points to http://www.fedora.us/LEGACY with link name "development in progress". Page http://www.fedoralegacy.org/about/overview.php points to http://www.fedora.us/wiki/PackageSubmissionQAPolicy with link name "fedora.us Package Submission & QA Policy". So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the LEGACY keyword is missing in the list of Bugzilla Keywords. -------------- 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 ms-nospam-0306 at arcor.de Wed Feb 25 12:17:17 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 25 Feb 2004 13:17:17 +0100 Subject: keyword LEGACY missing in doc In-Reply-To: <1077708999.5215.11.camel@localhost.localdomain> References: <1077708999.5215.11.camel@localhost.localdomain> Message-ID: <20040225131717.69400328.ms-nospam-0306@arcor.de> On Wed, 25 Feb 2004 12:36:39 +0100, Bart Martens wrote: > Page http://www.fedoralegacy.org/ points to http://www.fedora.us/LEGACY > with link name "development in progress". > > Page http://www.fedoralegacy.org/about/overview.php points to > http://www.fedora.us/wiki/PackageSubmissionQAPolicy with link name > "fedora.us Package Submission & QA Policy". > > So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the > LEGACY keyword is missing in the list of Bugzilla Keywords. It's a Wiki. You could enhance the pages anytime yourself. Although I don't understand why you would want to add the LEGACY keyword in the fedora.us documentation. Btw, the complete list of keywords can be found in bugzilla: https://bugzilla.fedora.us/describekeywords.cgi The LEGACY keyword is not really needed anyway. -- From peter.abraham at dynamicnet.net Wed Feb 25 13:30:00 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Wed, 25 Feb 2004 08:30:00 -0500 Subject: Fixed Kernel? In-Reply-To: <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> Message-ID: <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> Greetings: Is the Kernel update out of testing? When we see something like "Fedora Legacy Test Update Notification: pwlib" posted to the list, is there an average time line before it hits production? Thank you!! At 11:24 AM 2/19/2004, you wrote: >On Thu, 19 Feb 2004 08:12:46 -0500, Peter M. Abraham wrote: > > > Greetings: > > > > Will the Fedora team be releasing a kernel update to RedHat 7.x? > > > > Thank you. > > > > At 07:02 PM 2/18/2004, you wrote: > > >Right now there are two bugs in bugzilla that require a new kernel to > > >be rolled: > > > > > >https://bugzilla.fedora.us/show_bug.cgi?id=1284 > >If you can't wait, visit above URL, read comment 3, get the new kernel >erratum src.rpm for Red Hat Linux 9, apply the small patch which flips two >lines in the spec file and build for rh7x. From bart.martens at chello.be Wed Feb 25 13:53:36 2004 From: bart.martens at chello.be (Bart Martens) Date: Wed, 25 Feb 2004 14:53:36 +0100 Subject: keyword LEGACY missing in doc In-Reply-To: <20040225131717.69400328.ms-nospam-0306@arcor.de> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131717.69400328.ms-nospam-0306@arcor.de> Message-ID: <1077717215.5215.57.camel@localhost.localdomain> On Wed, 2004-02-25 at 13:17, Michael Schwendt wrote: > On Wed, 25 Feb 2004 12:36:39 +0100, Bart Martens wrote: > > > Page http://www.fedoralegacy.org/ points to http://www.fedora.us/LEGACY > > with link name "development in progress". > > > > Page http://www.fedoralegacy.org/about/overview.php points to > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy with link name > > "fedora.us Package Submission & QA Policy". > > > > So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the > > LEGACY keyword is missing in the list of Bugzilla Keywords. > > It's a Wiki. You could enhance the pages anytime yourself. Can anyone get a new login/pass at http://www.fedora.us/wiki/ ? It says "New users may use an empty password" but then it keeps complaining "Invalid password or userid". Anyone? > Although I > don't understand why you would want to add the LEGACY keyword in the > fedora.us documentation. > The LEGACY keyword is not really needed anyway. I don't want to start a discussion on the (non)sense of chosen keywords. I only want to see an inconsistency in the documentation fixed. > Btw, the complete list of keywords can be found in bugzilla: > https://bugzilla.fedora.us/describekeywords.cgi OK, that page has the LEGACY keyword listed. Then I guess the solution is to remove the keyword list from http://www.fedora.us/wiki/PackageSubmissionQAPolicy and have that page point to https://bugzilla.fedora.us/describekeywords.cgi Can someone fix the inconsistency, or give me access to these wiki pages? -------------- 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 ms-nospam-0306 at arcor.de Wed Feb 25 14:22:52 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 25 Feb 2004 15:22:52 +0100 Subject: keyword LEGACY missing in doc In-Reply-To: <1077717215.5215.57.camel@localhost.localdomain> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131717.69400328.ms-nospam-0306@arcor.de> <1077717215.5215.57.camel@localhost.localdomain> Message-ID: <20040225152252.0fc352d7.ms-nospam-0306@arcor.de> On Wed, 25 Feb 2004 14:53:36 +0100, Bart Martens wrote: > > > So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the > > > LEGACY keyword is missing in the list of Bugzilla Keywords. > > > > It's a Wiki. You could enhance the pages anytime yourself. > > Can anyone get a new login/pass at http://www.fedora.us/wiki/ ? It says > "New users may use an empty password" but then it keeps complaining > "Invalid password or userid". Anyone? The chosen UserId must be a valid WikiWord, that means, be in the proper format (have upper-case characters at word-boundaries). -- From ms-nospam-0306 at arcor.de Wed Feb 25 14:25:33 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 25 Feb 2004 15:25:33 +0100 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> Message-ID: <20040225152533.6f4b6ea6.ms-nospam-0306@arcor.de> On Wed, 25 Feb 2004 08:30:00 -0500, Peter M. Abraham wrote: > Greetings: > > Is the Kernel update out of testing? > > When we see something like "Fedora Legacy Test Update Notification: pwlib" > posted to the list, is there an average time line before it hits production? Clearsigned approvals posted as bugzilla comments or attachments can speed up the release. If everyone chooses to wait for some time-out, Fedora Legacy is not peforming good. -- From bart.martens at chello.be Wed Feb 25 17:07:30 2004 From: bart.martens at chello.be (Bart Martens) Date: Wed, 25 Feb 2004 18:07:30 +0100 Subject: keyword LEGACY missing in doc In-Reply-To: <20040225152252.0fc352d7.ms-nospam-0306@arcor.de> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131717.69400328.ms-nospam-0306@arcor.de> <1077717215.5215.57.camel@localhost.localdomain> <20040225152252.0fc352d7.ms-nospam-0306@arcor.de> Message-ID: <1077728850.5215.156.camel@localhost.localdomain> On Wed, 2004-02-25 at 15:22, Michael Schwendt wrote: > On Wed, 25 Feb 2004 14:53:36 +0100, Bart Martens wrote: > > > > So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the > > > > LEGACY keyword is missing in the list of Bugzilla Keywords. > > > It's a Wiki. You could enhance the pages anytime yourself. > > Can anyone get a new login/pass at http://www.fedora.us/wiki/ ? It says > > "New users may use an empty password" but then it keeps complaining > > "Invalid password or userid". Anyone? > > The chosen UserId must be a valid WikiWord, that means, be in the > proper format (have upper-case characters at word-boundaries). > OK I got it fixed now. Thanks for your help. -------------- 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 rostetter at mail.utexas.edu Wed Feb 25 19:14:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 25 Feb 2004 13:14:17 -0600 Subject: jumpstarting yum on 7.2 In-Reply-To: <1077707787.23896.194.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040220144236.qyyas084cssgoc8w@mail.ph.utexas.edu> <1077318734.7174.44230.camel@ruby.rub.gnuleaf.net> <200402201526.44348.jkeating@j2solutions.net> <1077707787.23896.194.camel@ruby.rub.gnuleaf.net> Message-ID: <20040225131417.7aoskg0w8wsk0css@mail.ph.utexas.edu> Quoting g : > actually i don't see the point. a new kernel gets downloaded, and even > entered into grub.conf as a choice, but the previous default boot kernel > is not changed. so what's the worry? IT *DOES* CHANGE THE DEFAULT BOOT KERNEL! At least in most cases. ;) So your argument doesn't match the reality of the situation. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Feb 25 19:19:43 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 25 Feb 2004 13:19:43 -0600 Subject: keyword LEGACY missing in doc In-Reply-To: <1077708999.5215.11.camel@localhost.localdomain> References: <1077708999.5215.11.camel@localhost.localdomain> Message-ID: <20040225131943.ie8koogw4c0k0w4w@mail.ph.utexas.edu> Quoting Bart Martens : > Page http://www.fedoralegacy.org/ points to http://www.fedora.us/LEGACY > with link name "development in progress". Correct. I'm not sure why it leaves our site, but I assume it has to due with fedora.us hosting our bugzilla. > Page http://www.fedoralegacy.org/about/overview.php points to > http://www.fedora.us/wiki/PackageSubmissionQAPolicy with link name > "fedora.us Package Submission & QA Policy". That page is sorely out of date, but since changes to it need to be done via community agreement, and no one has had the time to pursue that yet, it stays out of date. We don't have our own official QA Policy page yet, though we do have drafts, so that link is the most valid at this time. > So on page http://www.fedora.us/wiki/PackageSubmissionQAPolicy the > LEGACY keyword is missing in the list of Bugzilla Keywords. Because it is a page that is for fedora.us, and not legacy, and was never updated to include legacy even though legacy pointed at it. But probably it would be best for us to just get our own QA page up asap. -- Eric Rostetter From rostetter at mail.utexas.edu Wed Feb 25 19:26:35 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 25 Feb 2004 13:26:35 -0600 Subject: keyword LEGACY missing in doc In-Reply-To: <1077717215.5215.57.camel@localhost.localdomain> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131717.69400328.ms-nospam-0306@arcor.de> <1077717215.5215.57.camel@localhost.localdomain> Message-ID: <20040225132635.mwgo4s04ksws0kwc@mail.ph.utexas.edu> Quoting Bart Martens : > Can anyone get a new login/pass at http://www.fedora.us/wiki/ ? It says Yes. > "New users may use an empty password" but then it keeps complaining > "Invalid password or userid". Anyone? Your username must be in proper format. Otherwise it won't work. Try your first and last name without any spaces (FirstLast) for example. I recommend putting a password on it, otherwise anyone can post things as you (assume your identity) and I can find no way to create a password later on. > I only want to see an inconsistency in the documentation fixed. It isn't so much an inconsistency in the docs as a cross-post between two different projects. > OK, that page has the LEGACY keyword listed. Then I guess the solution > is to remove the keyword list from > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > and have that page point to > https://bugzilla.fedora.us/describekeywords.cgi That sounds like a winner. > Can someone fix the inconsistency, or give me access to these wiki > pages? You should get access if you use a properly formated name. I don't know what the rules are, but "FirstLast" seems to be a good choice. -- Eric Rostetter From jkeating at j2solutions.net Wed Feb 25 19:26:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 25 Feb 2004 11:26:45 -0800 Subject: keyword LEGACY missing in doc In-Reply-To: <20040225131943.ie8koogw4c0k0w4w@mail.ph.utexas.edu> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131943.ie8koogw4c0k0w4w@mail.ph.utexas.edu> Message-ID: <200402251126.45520.jkeating@j2solutions.net> On Wednesday 25 February 2004 11:19, Eric Rostetter wrote: > Because it is a page that is for fedora.us, and not legacy, and was > never updated to include legacy even though legacy pointed at it. > But probably it would be best for us to just get our own QA page up > asap. This is one of my goals for the week. We have our own wiki, and I'm going to be putting our own QA procedures up on our own wiki. I've seen the drafts, and will be pulling some info from them. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 bart.martens at chello.be Wed Feb 25 20:09:51 2004 From: bart.martens at chello.be (Bart Martens) Date: Wed, 25 Feb 2004 21:09:51 +0100 Subject: keyword LEGACY missing in doc In-Reply-To: <20040225132635.mwgo4s04ksws0kwc@mail.ph.utexas.edu> References: <1077708999.5215.11.camel@localhost.localdomain> <20040225131717.69400328.ms-nospam-0306@arcor.de> <1077717215.5215.57.camel@localhost.localdomain> <20040225132635.mwgo4s04ksws0kwc@mail.ph.utexas.edu> Message-ID: <1077739790.5215.171.camel@localhost.localdomain> On Wed, 2004-02-25 at 20:26, Eric Rostetter wrote: > Quoting Bart Martens : > > OK, that page has the LEGACY keyword listed. Then I guess the solution > > is to remove the keyword list from > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > and have that page point to > > https://bugzilla.fedora.us/describekeywords.cgi > > That sounds like a winner. OK, fixed that. -------------- 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 jpdalbec at ysu.edu Wed Feb 25 21:07:34 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 25 Feb 2004 16:07:34 -0500 Subject: mach on RH 8.0 Message-ID: <403D0E96.9080809@ysu.edu> I'm trying to set up a RHL 7.2 chroot on RH 8.0. I tried "mach -r rh72 setup base" but I get the following error: apt-get: relocation error: /lib/libnss_files.so.2: symbol _nss_files_parse_grent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Any ideas? Thanks, John From arvand at sbcglobal.net Thu Feb 26 08:18:11 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Thu, 26 Feb 2004 00:18:11 -0800 Subject: libxml2 security vulnerability? Message-ID: <200402260818.i1Q8IAfE239820@pimout1-ext.prodigy.net> Hello, I received the following from RH about 5 minutes ago. Would 7.x and 8.0 be vulnerable as well? If yes, can this be added to the bugzilla? https://www.redhat.com/archives/redhat-watch-list/2004-February/msg00007.htm l Regards, Arvand Sabetian From andy.henson.fedora at zexia.co.uk Thu Feb 26 09:40:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Thu, 26 Feb 2004 09:40 +0000 (GMT Standard Time) Subject: mach on RH 8.0 In-Reply-To: <403D0E96.9080809@ysu.edu> Message-ID: Is it a general mach install problem or just a rh72 one? What does "mach setup base" (without the -r) say? Does that work ok? If it fails to work without the -r, make sure it's installed correctly and you are su to "mach" before running it. Also make sure you got the rh8 apt and mach packages... mach will get the rh72 bits you need. Andy From jkeating at j2solutions.net Thu Feb 26 15:44:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 26 Feb 2004 07:44:59 -0800 Subject: libxml2 security vulnerability? In-Reply-To: <200402260818.i1Q8IAfE239820@pimout1-ext.prodigy.net> References: <200402260818.i1Q8IAfE239820@pimout1-ext.prodigy.net> Message-ID: <200402260744.59173.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 00:18, Arvand Sabetian wrote: > I received the following from RH about 5 minutes ago. Would 7.x and 8.0 > be vulnerable as well? If yes, can this be added to the bugzilla? > > https://www.redhat.com/archives/redhat-watch-list/2004-February/msg00007 >.htm l Jonny Strom added this to bugzilla, as well as python. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAPhR74v2HLvE71NURAgsHAJ9CvI9HN6iAvEjMESwjkRk875TFkwCfTJ5K v/MZqeR40/VTyGB7we9+PFo= =Fveb -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Thu Feb 26 19:31:44 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 26 Feb 2004 14:31:44 -0500 Subject: mach on RH 8.0 In-Reply-To: <20040226170004.1555.63172.Mailman@listman.back-rdu.redhat.com> References: <20040226170004.1555.63172.Mailman@listman.back-rdu.redhat.com> Message-ID: <403E49A0.3070400@ysu.edu> > Date: Thu, 26 Feb 2004 09:40 +0000 (GMT Standard Time) > From: andy.henson.fedora at zexia.co.uk (Andy Henson) > Subject: Re: mach on RH 8.0 > To: fedora-legacy-list at redhat.com > CC: andy.henson.fedora at zexia.co.uk > Reply-To: fedora-legacy-list at redhat.com > > Is it a general mach install problem or just a rh72 one? > What does "mach setup base" (without the -r) say? Does that work ok? Works fine. > > If it fails to work without the -r, make sure it's installed correctly and > you are su to "mach" before running it. Also make sure you got the rh8 apt > and mach packages... mach will get the rh72 bits you need. I built mach 0.4.3 from source (rpmbuild -ta) since I didn't see an RH 8.0 RPM for it. Is that the problem? I downgraded to the mach 0.4.2 RHL 8.0 binary package, but that didn't help. I still have no problems with "mach setup base" but "mach -r rh72 setup base" fails. I got Thomas' key from pgp.mit.edu with gpg --recv-keys 55f3aa6f. I ran gpg --list-keys and it showed the fingerprint as 55F3AA6F. I exported it from GPG and tried to import it to RPM. It showed up as gpg-pubkey-54a2acf1-3e3098f3. I had previously installed RPM and rpm-python from freshrpms.net, and rpm-build and rpm-devel from legacy-utils. I downloaded the legacy-utils rpm and rpm-python packages and "rpm -Uvh --replacefiles --replacepkgs"d them. This didn't fix the problem. Do I have to delete the RPM DB files? I noticed I had LANG set to en_US.UTF8. Man pages were displaying incorrectly with that setting. I changed it to en_US and the man pages showed up correctly again. Does that affect rpm's key import? Thanks, John > > Andy From ms-nospam-0306 at arcor.de Thu Feb 26 19:47:31 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 20:47:31 +0100 Subject: mach on RH 8.0 In-Reply-To: <403E49A0.3070400@ysu.edu> References: <20040226170004.1555.63172.Mailman@listman.back-rdu.redhat.com> <403E49A0.3070400@ysu.edu> Message-ID: <20040226204731.67d4b5fa.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 14:31:44 -0500, John Dalbec wrote: > I got Thomas' key from pgp.mit.edu with gpg --recv-keys 55f3aa6f. I ran gpg > --list-keys and it showed the fingerprint as 55F3AA6F. I exported it from GPG > and tried to import it to RPM. It showed up as gpg-pubkey-54a2acf1-3e3098f3. 54a2acf1 is Warren Togami's key. If that was really the result of rpm importing Thomas' key, you probably have run into rh bug #90952. As a work-around, try to get Thomas' key from him directly or a different keyserver, not any modified/signed version from pgp.mit.edu. -- From jpdalbec at ysu.edu Fri Feb 27 16:35:55 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 27 Feb 2004 11:35:55 -0500 Subject: RPM public key import bug Message-ID: <403F71EB.3050903@ysu.edu> When I rpm --import a public key with the RHL 8.0 legacy-utils RPM packages, the version of the gpg-pubkey package is not taken from the key ID. Instead RPM finds the first sig 3 (what does the 3 mean?) and versions the package after the key ID from that signature. In some cases this makes the key useless for verifying RPMs since the RPM version doesn't match the key ID. Is there a standard that says the first sig 3 should be from the key itself? Thanks, John [jpdalbec at testing07 jpdalbec]$ mkdir -m 700 gpghome [jpdalbec at testing07 jpdalbec]$ gpg --homedir gpghome --keyserver pgp.mit.edu --recv-keys 54a2acf1 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: keyring `gpghome/secring.gpg' created gpg: keyring `gpghome/pubring.gpg' created gpg: requesting key 54A2ACF1 from HKP keyserver pgp.mit.edu gpg: gpghome/trustdb.gpg: trustdb created gpg: key 54A2ACF1: public key imported gpg: Total number processed: 1 gpg: imported: 1 [jpdalbec at testing07 jpdalbec]$ gpg --homedir gpghome --list-sigs 54a2acf1 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 1024D/54A2ACF1 2002-11-25 Warren Togami (Linux) sig 9B649644 2003-02-09 [User id not found] sig BAE32F33 2003-08-24 [User id not found] sig 67899E2B 2003-02-20 [User id not found] sig 3ED6F034 2003-05-25 [User id not found] sig 2 D881FF60 2003-04-23 [User id not found] sig 2 B8AF1C54 2003-06-03 [User id not found] sig 2 1B0390E0 2002-11-25 [User id not found] sig 2 3FF87D98 2003-02-09 [User id not found] sig 2 BCD241CB 2003-02-13 [User id not found] sig 2 3C9DB0AA 2003-03-31 [User id not found] sig 2 E421D146 2003-05-27 [User id not found] sig 2 C58CF1CB 2003-06-27 [User id not found] sig 2 E42D547B 2003-08-19 [User id not found] sig 2 78688BF5 2004-01-08 [User id not found] sig 2 9D6B4012 2004-01-15 [User id not found] sig 2 A1906F09 2004-02-14 [User id not found] sig 3 780C9288 2003-01-30 [User id not found] sig 3 8E279021 2003-02-22 [User id not found] sig 3 AA168599 2002-11-25 [User id not found] sig 3 EE9FC38B 2003-01-24 [User id not found] sig 3 55F3AA6F 2003-01-24 [User id not found] sig 3 9B8DEC2A 2003-02-06 [User id not found] sig 3 D885D953 2003-03-21 [User id not found] sig 3 8DF56D05 2003-03-27 [User id not found] sig 3 99F0D661 2003-03-27 [User id not found] sig 3 C5575542 2003-05-27 [User id not found] sig 3 54A2ACF1 2002-11-25 Warren Togami (Linux) sig 3 54A2ACF1 2002-11-25 Warren Togami (Linux) sub 2048g/4AD75982 2002-11-25 [expires: 2007-11-24] sig 54A2ACF1 2002-11-25 Warren Togami (Linux) [jpdalbec at testing07 jpdalbec]$ gpg --homedir gpghome --armor --export 54a2acf1 > tmp gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information [jpdalbec at testing07 jpdalbec]$ mkdir rpmroot [jpdalbec at testing07 jpdalbec]$ rpm --root $(pwd)/rpmroot --import tmp [jpdalbec at testing07 jpdalbec]$ rpm --root $(pwd)/rpmroot -q gpg-pubkey gpg-pubkey-780c9288-3e38e07d [jpdalbec at testing07 jpdalbec]$ From Freedom_Lover at pobox.com Fri Feb 27 16:52:58 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 27 Feb 2004 11:52:58 -0500 Subject: RPM public key import bug In-Reply-To: <403F71EB.3050903@ysu.edu> References: <403F71EB.3050903@ysu.edu> Message-ID: <20040227165258.GE2063@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dalbec wrote: > When I rpm --import a public key with the RHL 8.0 legacy-utils RPM > packages, the version of the gpg-pubkey package is not taken from the key > ID. Like Michael said, you're running into an rpm bug. See here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90952 To me, this is a reason that the gpg functions should have remained in gpg and not rolled into rpm itself. This bug has existed for several versions now (rh{8.0,9}, fc1) and doesn't seem like a high priority to fix. (Anyone know if it's fixed in FC2 testing?) > Instead RPM finds the first sig 3 (what does the 3 mean?) The 3 marks how carefully the signer has checked the key. gpg allows for 4 levels and describes them as: (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking. > Is there a standard that says the first sig 3 should be from the key > itself? Not that I know of. I think rpm is just broken here. If you want to look though, the spec to read would be the OpenPGP spec, RFC2440. There is a draft of a successor to that which might have something relevant also, I think that's named 2440-bis, but you'll have to google to confirm, my memory isn't great and it's way too early for me to be thinking anyway. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Drugs may lead to nowhere, but at least it's the scenic route. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAP3Xpuv+09NZUB1oRAuZbAKDeZiOrVqZDUrRHY5loJD6vujEZ7gCfZwXc mdqNMe5qS1LAkBC+9vVTqSc= =vnQC -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Feb 27 17:30:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 27 Feb 2004 09:30:51 -0800 Subject: RPM public key import bug In-Reply-To: <20040227165258.GE2063@psilocybe.teonanacatl.org> References: <403F71EB.3050903@ysu.edu> <20040227165258.GE2063@psilocybe.teonanacatl.org> Message-ID: <200402270930.51569.jkeating@j2solutions.net> On Friday 27 February 2004 08:52, Todd wrote: > Not that I know of. I think rpm is just broken here. If you want to > look though, the spec to read would be the OpenPGP spec, RFC2440. > There is a draft of a successor to that which might have something > relevant also, I think that's named 2440-bis, but you'll have to > google to confirm, my memory isn't great and it's way too early for > me to be thinking anyway. This is why the Legacy key is published sans any signatures on our website. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.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 Fri Feb 27 19:30:44 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 27 Feb 2004 14:30:44 -0500 Subject: mach on RH 8.0 In-Reply-To: <20040227170003.4604.79426.Mailman@listman.back-rdu.redhat.com> References: <20040227170003.4604.79426.Mailman@listman.back-rdu.redhat.com> Message-ID: <403F9AE4.1060804@ysu.edu> > Date: Thu, 26 Feb 2004 20:47:31 +0100 > From: Michael Schwendt > To: fedora-legacy-list at redhat.com > Subject: Re: mach on RH 8.0 > Reply-To: fedora-legacy-list at redhat.com > > On Thu, 26 Feb 2004 14:31:44 -0500, John Dalbec wrote: > > >>I got Thomas' key from pgp.mit.edu with gpg --recv-keys 55f3aa6f. I ran gpg >>--list-keys and it showed the fingerprint as 55F3AA6F. I exported it from GPG >>and tried to import it to RPM. It showed up as gpg-pubkey-54a2acf1-3e3098f3. > > > 54a2acf1 is Warren Togami's key. If that was really the result of rpm > importing Thomas' key, you probably have run into rh bug #90952. As a > work-around, try to get Thomas' key from him directly or a different > keyserver, not any modified/signed version from pgp.mit.edu. > Thanks. I dug around on his website and eventually located the key. Back to my problem: I tried mach -r rh72u setup base and that failed. I tried mach -r rh72ufr setup base and that failed. I tried mach -r rh73 setup base and that worked. I can recover a consistent package set by invoking mach-helper directly and removing pam and whatever depends on it. I tried installing apt and ran into the same problem (almost; s/grent/pwent/). I backed out pam and tried installing rpm by itself, same problem. I have an strace of the rpm install attempt at http://cc.ysu.edu/~jpdalbec/install.strace.bz2 if that helps. I can see that libc.so.6 is opened first, then chroot() is called, then libnss_files is opened. So the program is mixing Red Hat 8.0's libc.so.6 with Red Hat 7.2's libnss_files. Do I need to install some kind of backward compatibility glibc package in Red Hat 8.0? Is there such a beast? John [mach at testing07 mach]$ mach -r rh72u setup base Preparing root Updating apt sources ..... Installing package set 'minimal' ........ Installing package set 'base' ........! error: /usr/sbin/mach-helper apt-get -c /var/lib/mach/states/redhat-72-i386-updates/apt.conf install -y fileutils findutils openssh-server net-tools file failed. Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: SysVinit (2.78-19) chkconfig (1.2.24-1) cracklib (2.7-12) cracklib-dicts (2.7-12) db3 (3.2.9-4) diffutils (2.7.2-2) e2fsprogs (1.26-1.72) gawk (3.1.0-3) glib (1.2.10-5) grep (2.4.2-7) info (4.0b-3) initscripts (6.43-1) iproute (2.4.7-7.72.1) iputils (20001110-6) logrotate (3.5.9-1) mingetty (0.9.4-18) modutils (2.4.18-3.7x) mount (2.11g-5) ncurses (5.2-12) openssh (3.1p1-14) openssl (0.9.6b-35.7) pam (0.75-46.7.2) popt (1.6.4-7x) procps (2.0.7-11) psmisc (20.1-2) pwdb (0.61.1-3) sed (3.02-10) sh-utils (2.0.11-5) shadow-utils (20000902-9.7) sysklogd (1.4.1-4) textutils (2.0.14-2) util-linux (2.11f-17.7.2) which (2.12-3) words (2-17) zlib (1.1.4-8.7x) The following NEW packages will be installed: SysVinit (2.78-19) chkconfig (1.2.24-1) cracklib (2.7-12) cracklib-dicts (2.7-12) db3 (3.2.9-4) diffutils (2.7.2-2) e2fsprogs (1.26-1.72) file (3.39-8.7x) fileutils (4.1-10.4) findutils (4.1.7-1) gawk (3.1.0-3) glib (1.2.10-5) grep (2.4.2-7) info (4.0b-3) initscripts (6.43-1) iproute (2.4.7-7.72.1) iputils (20001110-6) logrotate (3.5.9-1) mingetty (0.9.4-18) modutils (2.4.18-3.7x) mount (2.11g-5) ncurses (5.2-12) net-tools (1.60-3) openssh (3.1p1-14) openssh-server (3.1p1-14) openssl (0.9.6b-35.7) pam (0.75-46.7.2) popt (1.6.4-7x) procps (2.0.7-11) psmisc (20.1-2) pwdb (0.61.1-3) sed (3.02-10) sh-utils (2.0.11-5) shadow-utils (20000902-9.7) sysklogd (1.4.1-4) textutils (2.0.14-2) util-linux (2.11f-17.7.2) which (2.12-3) words (2-17) zlib (1.1.4-8.7x) 0 upgraded, 40 newly installed, 0 removed and 0 not upgraded. Need to get 0B/11.8MB of archives. After unpacking 29.0MB of additional disk space will be used. Committing changes... Preparing... ########################################### [100%] 1:zlib ########################################### [ 3%] 2:chkconfig ########################################### [ 5%] 3:ncurses ########################################### [ 8%] 4:info ########################################### [ 10%] 5:fileutils ########################################### [ 13%] 6:gawk ########################################### [ 15%] 7:sed ########################################### [ 18%] 8:grep ########################################### [ 20%] 9:openssl ########################################### [ 23%] 10:textutils ########################################### [ 25%] 11:cracklib ########################################### [ 28%] 12:procps ########################################### [ 30%] 13:diffutils ########################################### [ 33%] 14:mount ########################################### [ 35%] 15:psmisc ########################################### [ 38%] 16:db3 ########################################### [ 40%] 17:pwdb ########################################### [ 43%] 18:shadow-utils ########################################### [ 45%] 19:net-tools ########################################### [ 48%] 20:iputils ########################################### [ 50%] 21:iproute ########################################### [ 52%] 22:which ########################################### [ 55%] 23:popt ########################################### [ 58%] 24:logrotate ########################################### [ 60%] 25:e2fsprogs ########################################### [ 63%] 26:mingetty ########################################### [ 65%] 27:glib ########################################### [ 68%] 28:words ########################################### [ 70%] 29:cracklib-dicts ########################################### [ 73%] 30:pam ########################################### [ 75%] 31:sh-utils ########################################### [ 78%] 32:modutils ########################################### [ 80%] apt-get: relocation error: /lib/libnss_files.so.2: symbol _nss_files_parse_grent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Retrying installing package set 'base' ...! error: /usr/sbin/mach-helper apt-get -c /var/lib/mach/states/redhat-72-i386-updates/apt.conf install -y fileutils findutils openssh-server net-tools file failed. Reading Package Lists... Done Building Dependency Tree... Done fileutils is already the newest version. net-tools is already the newest version. You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: openssh-server: PreDepends: openssh (= 3.1p1-14) but it is not going to be installed pam: Depends: initscripts (>= 3.94) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). ERROR: Could not apt-get install -y fileutils findutils openssh-server net-tools file [mach at testing07 mach]$ /usr/sbin/mach-helper apt-get -c /var/lib/mach/states/redhat-72-i386-updates/apt.conf -f install Reading Package Lists... Done Building Dependency Tree... Done Correcting dependencies... Done The following extra packages will be installed: SysVinit (2.78-19) initscripts (6.43-1) sysklogd (1.4.1-4) util-linux (2.11f-17.7.2) The following NEW packages will be installed: SysVinit (2.78-19) initscripts (6.43-1) sysklogd (1.4.1-4) util-linux (2.11f-17.7.2) 0 upgraded, 4 newly installed, 0 removed and 0 not upgraded. Need to get 0B/1694kB of archives. After unpacking 4163kB of additional disk space will be used. Do you want to continue? [Y/n] Committing changes... Preparing... ########################################### [100%] apt-get: relocation error: /lib/libnss_files.so.2: symbol _nss_files_parse_grent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference [mach at testing07 mach]$ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 20:37:52 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 21:37:52 +0100 Subject: mach on RH 8.0 In-Reply-To: <403F9AE4.1060804@ysu.edu> References: <20040227170003.4604.79426.Mailman@listman.back-rdu.redhat.com> <403F9AE4.1060804@ysu.edu> Message-ID: <20040227213752.06cd1a5c@localhost> John Dalbec wrote : > Back to my problem: > I tried mach -r rh72u setup base and that failed. > I tried mach -r rh72ufr setup base and that failed. > I tried mach -r rh73 setup base and that worked. I'm not completely surprised. Releases older than 7.3 aren't really used by packagers anymore, me included. If you find fixes or workarounds to get them going, then I'm sure Thomas would love to get updates for the dist file. Unfortunately, problems that pop up when using mach are often packaging issues, like missing PreRequires and similar. Not really easy to get fixes back into RHL 7.x packages... :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.76 0.87 0.79