From colman at ppllc.com Wed Jun 1 13:31:58 2005 From: colman at ppllc.com (Jake Colman) Date: Wed, 01 Jun 2005 09:31:58 -0400 Subject: Two NIC Routing Question Message-ID: <76ekbmciep.fsf@newjersey.ppllc.com> I have a class two NIC firewall. eth0 is my external interface connected to my cablemodem, eth1 is my internal interface connected to my hub. I am using iptables-based firewall rules and using NAT so I can access the internet from all my desktops. Everything is working correctly. The problem is that it only works if I manually set up a default gateway route through the external interface. After I boot the system, I type the following command: route add default gw x.x.x.x where x.x.x.x is the address assigned to my external interface. If I don't do this, I cannot access anything on the internet from any my internal machines. Once I execute this command it all works as expected. I am certain, however, that as a RH 7.2 system, which is what I was before I started incrementally upgrading to FC1 where I am now, I did not need to do this for it to work. How can I get this routing between two NICs to work correctly without manually executing a 'route' command? Please don't tell me to add this command to rc.local. My external IP address is dynamic so it can change between reboots. I need some mechanism that works dynamically. I'm sure that it used to work this way! TIA! ...Jake -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 (201) 209-2467 www.principiapartners.com From ad+lists at uni-x.org Wed Jun 1 18:51:35 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Wed, 01 Jun 2005 20:51:35 +0200 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <1117651895.25585.74.camel@serendipity.dogma.lan> Am Mi, den 01.06.2005 schrieb Jake Colman um 15:31: > How can I get this routing between two NICs to work correctly without > manually executing a 'route' command? Please don't tell me to add this > command to rc.local. My external IP address is dynamic so it can change > between reboots. I need some mechanism that works dynamically. I'm sure > that it used to work this way! > ...Jake Be sure you have the GATEWAY entry (only) in /etc/sysconfig/network. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.27_FC2smp Serendipity 20:50:23 up 8 days, 19:28, load average: 0.23, 0.33, 0.42 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From wstockal at compusmart.ab.ca Wed Jun 1 19:44:00 2005 From: wstockal at compusmart.ab.ca (William Stockall) Date: Wed, 01 Jun 2005 13:44:00 -0600 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <429E1000.6090403@compusmart.ab.ca> Shouldn't the routing be automatically set up by DHCP? Will. Jake Colman wrote: > I have a class two NIC firewall. eth0 is my external interface connected to > my cablemodem, eth1 is my internal interface connected to my hub. I am using > iptables-based firewall rules and using NAT so I can access the internet from > all my desktops. Everything is working correctly. > > The problem is that it only works if I manually set up a default gateway > route through the external interface. After I boot the system, I type the > following command: > > route add default gw x.x.x.x > > where x.x.x.x is the address assigned to my external interface. If I don't do > this, I cannot access anything on the internet from any my internal machines. > Once I execute this command it all works as expected. I am certain, however, > that as a RH 7.2 system, which is what I was before I started incrementally > upgrading to FC1 where I am now, I did not need to do this for it to work. > > How can I get this routing between two NICs to work correctly without > manually executing a 'route' command? Please don't tell me to add this > command to rc.local. My external IP address is dynamic so it can change > between reboots. I need some mechanism that works dynamically. I'm sure > that it used to work this way! > > TIA! > > ...Jake > From patrickmailing at narmida.com Wed Jun 1 20:19:04 2005 From: patrickmailing at narmida.com ((Mailings) Patrick Lambooy) Date: Wed, 01 Jun 2005 22:19:04 +0200 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <429E1838.70600@narmida.com> should be gotten from dhcp so does ifdown eth0 / ipup eth0 work ? Jake Colman wrote: >I have a class two NIC firewall. eth0 is my external interface connected to >my cablemodem, eth1 is my internal interface connected to my hub. I am using >iptables-based firewall rules and using NAT so I can access the internet from >all my desktops. Everything is working correctly. > >The problem is that it only works if I manually set up a default gateway >route through the external interface. After I boot the system, I type the >following command: > > route add default gw x.x.x.x > >where x.x.x.x is the address assigned to my external interface. If I don't do >this, I cannot access anything on the internet from any my internal machines. >Once I execute this command it all works as expected. I am certain, however, >that as a RH 7.2 system, which is what I was before I started incrementally >upgrading to FC1 where I am now, I did not need to do this for it to work. > >How can I get this routing between two NICs to work correctly without >manually executing a 'route' command? Please don't tell me to add this >command to rc.local. My external IP address is dynamic so it can change >between reboots. I need some mechanism that works dynamically. I'm sure >that it used to work this way! > >TIA! > >...Jake > > > From lgu at pobox.com Wed Jun 1 21:35:10 2005 From: lgu at pobox.com (Larry Underhill) Date: Wed, 01 Jun 2005 17:35:10 -0400 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <1117661710.3687.93.camel@localhost.localdomain> Huh. I had a similar problem with my FC3 laptop. By chance are you running NetworkManager? /etc/init.d/NetworkManager status /etc/init.d/network status If you see that NetworkManger is started, then stop it and restart network. I am pretty sure this was the root of my problem... --Larry On Wed, 2005-06-01 at 09:31 -0400, Jake Colman wrote: > I have a class two NIC firewall. eth0 is my external interface connected to > my cablemodem, eth1 is my internal interface connected to my hub. I am using > iptables-based firewall rules and using NAT so I can access the internet from > all my desktops. Everything is working correctly. > > The problem is that it only works if I manually set up a default gateway > route through the external interface. After I boot the system, I type the > following command: > > route add default gw x.x.x.x > > where x.x.x.x is the address assigned to my external interface. If I don't do > this, I cannot access anything on the internet from any my internal machines. > Once I execute this command it all works as expected. I am certain, however, > that as a RH 7.2 system, which is what I was before I started incrementally > upgrading to FC1 where I am now, I did not need to do this for it to work. > > How can I get this routing between two NICs to work correctly without > manually executing a 'route' command? Please don't tell me to add this > command to rc.local. My external IP address is dynamic so it can change > between reboots. I need some mechanism that works dynamically. I'm sure > that it used to work this way! > > TIA! > > ...Jake > From marcdeslauriers at videotron.ca Wed Jun 1 21:42:56 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Jun 2005 17:42:56 -0400 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <1117662176.3498.4.camel@mdlinux> On Wed, 2005-06-01 at 09:31 -0400, Jake Colman wrote: > The problem is that it only works if I manually set up a default gateway > route through the external interface. After I boot the system, I type the > following command: > > route add default gw x.x.x.x > > where x.x.x.x is the address assigned to my external interface. If I don't do The address used by your external interface, or the address of your gateway? Please post the results of "netstat -rn" after a fresh reboot. 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 Thu Jun 2 00:33:08 2005 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 2 Jun 2005 10:33:08 +1000 Subject: Two NIC Routing Question In-Reply-To: <76ekbmciep.fsf@newjersey.ppllc.com> References: <76ekbmciep.fsf@newjersey.ppllc.com> Message-ID: <20050602001927.M59185@npgx.com.au> Hi Jake, > I have a class two NIC firewall. eth0 is my external interface > connected to my cablemodem, eth1 is my internal interface connected > to my hub. I am using iptables-based firewall rules and using NAT > so I can access the internet from all my desktops. Everything is > working correctly. > > The problem is that it only works if I manually set up a default gateway > route through the external interface. After I boot the system, I > type the following command: > > route add default gw x.x.x.x > > where x.x.x.x is the address assigned to my external interface. If I > don't do this, I cannot access anything on the internet from any my > internal machines. Once I execute this command it all works as > expected. I am certain, however, that as a RH 7.2 system, which is > what I was before I started incrementally upgrading to FC1 where I > am now, I did not need to do this for it to work. > > How can I get this routing between two NICs to work correctly without > manually executing a 'route' command? Please don't tell me to add this > command to rc.local. My external IP address is dynamic so it can change > between reboots. I need some mechanism that works dynamically. I'm > sure that it used to work this way! I was actually surprised to find that out of so many replies to you, people seemed to have missed the answer to your problem. In your /etc/sysconfig/network-scripts/ifcfg-ppp0 file, this is the file that's used to configure your link/routing when you dialup. There's a variable here you need to set: DEFROUTE=yes which will grab the default route information from your ISP and configure your routing for you. For this to work, you should _not_ set a GATEWAY variable in your /etc/sysconfig/network file. The GATEWAY flag adds a static default route to your routing table on system boot, which is not what you want in your situation. Within the /etc/sysconfig/network file remove the GATEWAY flag (if it's in there) and add: GATEWAYDEV="ppp0" which will tell the rc network script to use the default route supplied by the ifcfg-ppp0 script which picks that up from your ISP. Other interesting variables you can use in ifcfg-ppp0 are: ONBOOT PEERDNS CLAMPMSS FIREWALL there's docs in the system somewhere (I forgot where I read all this when first doing it) which explains what each variable does, you should review it to allow you to better understand how the process works. Regards, Michael. From pekkas at netcore.fi Thu Jun 2 06:35:49 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 2 Jun 2005 09:35:49 +0300 (EEST) Subject: changes are needed, we need keep moving Message-ID: Folks, The Fedora Legacy updates aren't progressing. Something needs to start happening. Ideas? My proposal: If one distribution version of a package has one VERIFY vote, all the versions will automatically be released after a timeout of XX (where I suggest XX is 2 weeks) from the first VERIFY -- except if someone identifies issues which require discussion or more work. This is a tradeoff between quality, timeliness and actually delivering the updates. Because most of the folks worried about quality of the updates are not actually doing much of testing, I don't see why we should be stalling because folks seem to be using updates-testing instead of updates. If something breaks with the update, we'll just fix it afterwards and say "well, you should have tested the update in 2 weeks and reported the problems". (FWIW, the current "issues" list is: http://www.netcore.fi/pekkas/buglist.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 mattdm at mattdm.org Thu Jun 2 12:28:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 08:28:35 -0400 Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: <20050602122835.GA13330@jadzia.bu.edu> On Thu, Jun 02, 2005 at 09:35:49AM +0300, Pekka Savola wrote: > If one distribution version of a package has one VERIFY vote, all the > versions will automatically be released after a timeout of XX (where > I suggest XX is 2 weeks) from the first VERIFY -- except if someone > identifies issues which require discussion or more work. I agree. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From madlists at teaparty.net Thu Jun 2 13:12:19 2005 From: madlists at teaparty.net (Tom Yates) Date: Thu, 2 Jun 2005 14:12:19 +0100 (BST) Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: On Thu, 2 Jun 2005, Pekka Savola wrote: > The Fedora Legacy updates aren't progressing. Something needs to start > happening. Ideas? > > My proposal: > > If one distribution version of a package has one VERIFY vote, all the > versions will automatically be released after a timeout of XX (where > I suggest XX is 2 weeks) from the first VERIFY -- except if someone > identifies issues which require discussion or more work. i'd still prefer that we released fixes for each OS as they passed the verify bar, instead of waiting until all affected OSes have been QA'ed before releasing any fix; that way, we don't release untested code, but unpopular distros can't hold the popular ones to ransom. but if that's unacceptable to the project as a whole, then pekka, your proposal seems sensible to me. two weeks seems like a good time. -- Tom Yates - http://www.teaparty.net From stickster at gmail.com Thu Jun 2 13:24:09 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 02 Jun 2005 09:24:09 -0400 Subject: Two NIC Routing Question In-Reply-To: <20050602001927.M59185@npgx.com.au> References: <76ekbmciep.fsf@newjersey.ppllc.com> <20050602001927.M59185@npgx.com.au> Message-ID: <1117718649.6929.55.camel@localhost.localdomain> On Thu, 2005-06-02 at 10:33 +1000, Michael Mansour wrote: > Hi Jake, > > > I have a class two NIC firewall. eth0 is my external interface > > connected to my cablemodem, eth1 is my internal interface connected > > to my hub. I am using iptables-based firewall rules and using NAT > > so I can access the internet from all my desktops. Everything is > > working correctly. > > > > The problem is that it only works if I manually set up a default gateway > > route through the external interface. After I boot the system, I > > type the following command: > > > > route add default gw x.x.x.x > > > > where x.x.x.x is the address assigned to my external interface. If I > > don't do this, I cannot access anything on the internet from any my > > internal machines. Once I execute this command it all works as > > expected. I am certain, however, that as a RH 7.2 system, which is > > what I was before I started incrementally upgrading to FC1 where I > > am now, I did not need to do this for it to work. > > > > How can I get this routing between two NICs to work correctly without > > manually executing a 'route' command? Please don't tell me to add this > > command to rc.local. My external IP address is dynamic so it can change > > between reboots. I need some mechanism that works dynamically. I'm > > sure that it used to work this way! > > I was actually surprised to find that out of so many replies to you, people > seemed to have missed the answer to your problem. > > In your /etc/sysconfig/network-scripts/ifcfg-ppp0 file, this is the file > that's used to configure your link/routing when you dialup. There's a variable > here you need to set: > > DEFROUTE=yes > > which will grab the default route information from your ISP and configure your > routing for you. For this to work, you should _not_ set a GATEWAY variable in > your /etc/sysconfig/network file. The GATEWAY flag adds a static default route > to your routing table on system boot, which is not what you want in your > situation. Within the /etc/sysconfig/network file remove the GATEWAY flag (if > it's in there) and add: > > GATEWAYDEV="ppp0" > > which will tell the rc network script to use the default route supplied by the > ifcfg-ppp0 script which picks that up from your ISP. > > Other interesting variables you can use in ifcfg-ppp0 are: > > ONBOOT > PEERDNS > CLAMPMSS > FIREWALL > > there's docs in the system somewhere (I forgot where I read all this when > first doing it) which explains what each variable does, you should review it > to allow you to better understand how the process works. I would guess you're referring to /usr/share/doc/initscripts-*/sysconfig.txt. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Jun 2 13:29:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 09:29:24 -0400 Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: <20050602132924.GA15764@jadzia.bu.edu> On Thu, Jun 02, 2005 at 02:12:19PM +0100, Tom Yates wrote: > i'd still prefer that we released fixes for each OS as they passed the > verify bar, instead of waiting until all affected OSes have been QA'ed > before releasing any fix; that way, we don't release untested code, but > unpopular distros can't hold the popular ones to ransom. These two aren't necessarily linked.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From pekkas at netcore.fi Thu Jun 2 13:45:48 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 2 Jun 2005 16:45:48 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: On Thu, 2 Jun 2005, Tom Yates wrote: >> If one distribution version of a package has one VERIFY vote, all the >> versions will automatically be released after a timeout of XX (where >> I suggest XX is 2 weeks) from the first VERIFY -- except if someone >> identifies issues which require discussion or more work. > > i'd still prefer that we released fixes for each OS as they passed the verify > bar, instead of waiting until all affected OSes have been QA'ed before > releasing any fix; that way, we don't release untested code, but unpopular > distros can't hold the popular ones to ransom. My problem with this approach is that I think it generates a LOT more work for the FLSA release folks because there is more "churn". For example, each event of publishing an update needs a separate FLSA advisory (or at least spamming all the mailing lists with an update to it), they have to be moved to updates one by one, etc. .. 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 colman at ppllc.com Thu Jun 2 14:13:09 2005 From: colman at ppllc.com (Jake Colman) Date: Thu, 02 Jun 2005 10:13:09 -0400 Subject: Two NIC Routing Question In-Reply-To: <20050602001927.M59185@npgx.com.au> (Michael Mansour's message of "Thu, 2 Jun 2005 10:33:08 +1000") References: <76ekbmciep.fsf@newjersey.ppllc.com> <20050602001927.M59185@npgx.com.au> Message-ID: <76is0wc0eh.fsf@newjersey.ppllc.com> >>>>> "MM" == Michael Mansour writes: MM> Hi Jake, >> I have a class two NIC firewall. eth0 is my external interface >> connected to my cablemodem, eth1 is my internal interface connected to >> my hub. I am using iptables-based firewall rules and using NAT so I >> can access the internet from all my desktops. Everything is working >> correctly. >> >> The problem is that it only works if I manually set up a default >> gateway route through the external interface. After I boot the system, >> I type the following command: >> >> route add default gw x.x.x.x >> >> where x.x.x.x is the address assigned to my external interface. If I >> don't do this, I cannot access anything on the internet from any my >> internal machines. Once I execute this command it all works as >> expected. I am certain, however, that as a RH 7.2 system, which is >> what I was before I started incrementally upgrading to FC1 where I am >> now, I did not need to do this for it to work. >> >> How can I get this routing between two NICs to work correctly without >> manually executing a 'route' command? Please don't tell me to add this >> command to rc.local. My external IP address is dynamic so it can >> change between reboots. I need some mechanism that works dynamically. >> I'm sure that it used to work this way! MM> I was actually surprised to find that out of so many replies to you, MM> people seemed to have missed the answer to your problem. MM> In your /etc/sysconfig/network-scripts/ifcfg-ppp0 file, this is the MM> file that's used to configure your link/routing when you MM> dialup. There's a variable here you need to set: MM> DEFROUTE=yes MM> which will grab the default route information from your ISP and MM> configure your routing for you. For this to work, you should _not_ set MM> a GATEWAY variable in your /etc/sysconfig/network file. The GATEWAY MM> flag adds a static default route to your routing table on system boot, MM> which is not what you want in your situation. Within the MM> /etc/sysconfig/network file remove the GATEWAY flag (if it's in there) MM> and add: MM> GATEWAYDEV="ppp0" MM> which will tell the rc network script to use the default route MM> supplied by the ifcfg-ppp0 script which picks that up from your ISP. MM> Other interesting variables you can use in ifcfg-ppp0 are: MM> ONBOOT MM> PEERDNS MM> CLAMPMSS MM> FIREWALL MM> there's docs in the system somewhere (I forgot where I read all this MM> when first doing it) which explains what each variable does, you MM> should review it to allow you to better understand how the process MM> works. MM> Regards, MM> Michael. Michael, Your answer is exactly the kind of answer I was hoping for since I am pretty sure it has to do with the various configuration variables not being set correctly. There is one problem, however, with your answer: I am not using a ppp device. My external NIC is dynamic since I am connected to a cablemodem and have not purchased a static IP address. The etho interface is configured via dhcp from my ISP; eth1 is hard-wired as 192.168.0.1. I believe that all the necessary magic comes from the /etc/sysconfig/networking-scripts directory. I have two files: ifcfg-eth0 and ifcfg-eth1. Contents of ifcfg-eth0: DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp Contents of ifcfg-eth1: DEVICE=eth1 BROADCAST=192.168.0.255 IPADDR=192.168.0.1 NETMASK=255.255.255.0 NETWORK=192.168.0.0 ONBOOT=yes The output of 'netstat -rn' following a reboot is: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 After I manually add a default route through eth0, I get the following: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 68.196.186.208 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 So what needs to be tweaked to make this all work correctly? And where can I find the documentation on those config files? Thanks! ...Jake -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 (201) 209-2467 www.principiapartners.com From colman at ppllc.com Thu Jun 2 14:15:49 2005 From: colman at ppllc.com (Jake Colman) Date: Thu, 02 Jun 2005 10:15:49 -0400 Subject: Two NIC Routing Question In-Reply-To: <1117662176.3498.4.camel@mdlinux> (Marc Deslauriers's message of "Wed, 1 Jun 2005 17:42:56 -0400") References: <1117662176.3498.4.camel@mdlinux> Message-ID: <76br6oc0a2.fsf@newjersey.ppllc.com> >>>>> "MD" == Marc Deslauriers writes: MD> On Wed, 2005-06-01 at 09:31 -0400, Jake Colman wrote: >> The problem is that it only works if I manually set up a default gateway >> route through the external interface. After I boot the system, I type the >> following command: >> >> route add default gw x.x.x.x >> >> where x.x.x.x is the address assigned to my external interface. If I don't do MD> The address used by your external interface, or the address of your MD> gateway? I have to add the IP adress of my external NIC as a default gw. MD> Please post the results of "netstat -rn" after a fresh reboot. The output of 'netstat -rn' following a reboot is: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 After I manually add a default route through eth0, I get the following: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 68.196.186.208 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 Why do your posts come through as a text attachment? -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 (201) 209-2467 www.principiapartners.com From bvermeul at blackstar.nl Thu Jun 2 15:47:59 2005 From: bvermeul at blackstar.nl (Bas Vermeulen) Date: Thu, 02 Jun 2005 17:47:59 +0200 Subject: Two NIC Routing Question In-Reply-To: <76br6oc0a2.fsf@newjersey.ppllc.com> References: <1117662176.3498.4.camel@mdlinux> <76br6oc0a2.fsf@newjersey.ppllc.com> Message-ID: <1117727279.2617.5.camel@laptop.blackstar.nl> On Thu, 2005-06-02 at 16:15, Jake Colman wrote: > I have to add the IP adress of my external NIC as a default gw. > > MD> Please post the results of "netstat -rn" after a fresh reboot. > > The output of 'netstat -rn' following a reboot is: > > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 > > After I manually add a default route through eth0, I get the following: > > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 68.196.176.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 68.196.186.208 0.0.0.0 UG 0 0 0 eth0 > 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 You have 192.168.0.254 configured as your gateway ( in /etc/sysconfig/network). Remove that entry, and let dhcp set it for you. dhcp won't set your default gateway if it's already set. Bas Vermeulen From rostetter at mail.utexas.edu Thu Jun 2 18:44:39 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 13:44:39 -0500 Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: <1117737879.c852097912420@mail.ph.utexas.edu> Quoting Pekka Savola : > Folks, > > The Fedora Legacy updates aren't progressing. Actually, they are. Just very slowly. > Something needs to > start happening. Ideas? People who have an interest in having packages released need to start doing QA (and/or other work for the group). > My proposal: > > If one distribution version of a package has one VERIFY vote, all the > versions will automatically be released after a timeout of XX (where > I suggest XX is 2 weeks) from the first VERIFY -- except if someone > identifies issues which require discussion or more work. You might as well just publish them without testing then. One verify vote isn't significantly different than no verify votes. I'd say any plan that requires only one verify vote is worthless. I'm not against the timeout, in fact there is supposed to be a timeout in the process, though I don't remember what it is. Perhaps we need to revisit the timeout issue, with the goal of putting someone in charge of watching the packages for timeout conditions. Right now, no one is AFAIK watching for such situations, so even if something had multiple verify votes and has stalled, no one notices and pushes it out. Seems like another essential job waiting to be filled. > This is a tradeoff between quality, timeliness and actually delivering > the updates. Your proposal as-is is no trade off. You're simply saying we should release updates without proper testing. But it does raise a valid issue (we're not actively watching for stalled issues, and pursuing them correctly). > Because most of the folks worried about quality of the > updates are not actually doing much of testing, I don't see why we > should be stalling because folks seem to be using updates-testing > instead of updates. If people are using testing-updates and not reporting their success, then that is the issue, and that is what needs to be fixed. I'm not sure if this is the case. If it is, maybe we could make posting a success report easier (e.g. a web form they fill out?) > If something breaks with the update, we'll just > fix it afterwards and say "well, you should have tested the update in > 2 weeks and reported the problems". And they will rightly say, "No, FL legacy released it as tested and passing QA, so the problem is with FL and not me." > (FWIW, the current "issues" list is: > http://www.netcore.fi/pekkas/buglist.html) I find posting that list is the thing that gets things rolling. In other words, very few people even consider testing until an issue list is posted at which point they check it out and start testing packages. I hate to say it, but regular posting of the issue list (at least those in updates-testing needed testing) would probably help greatly. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From pekkas at netcore.fi Thu Jun 2 19:16:31 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 2 Jun 2005 22:16:31 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: <1117737879.c852097912420@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> Message-ID: On Thu, 2 Jun 2005, Eric Rostetter wrote: >> Something needs to >> start happening. Ideas? > > People who have an interest in having packages released need to start > doing QA (and/or other work for the group). We've been calling out for that for months, but that has typically resulted in minor surges only, nothing major enough to go on with. >> If one distribution version of a package has one VERIFY vote, all the >> versions will automatically be released after a timeout of XX (where >> I suggest XX is 2 weeks) from the first VERIFY -- except if someone >> identifies issues which require discussion or more work. > > You might as well just publish them without testing then. One verify vote > isn't significantly different than no verify votes. I'd say any plan > that requires only one verify vote is worthless. I disagree. Patches are typically very similar across all the versions. The sanity of the patches has already been checked at PUBLISH. Checking that the program actually works in one platform is definitely better than nothing. > I'm not against the timeout, in fact there is supposed to be a timeout > in the process, though I don't remember what it is. Perhaps we need to > revisit the timeout issue, with the goal of putting someone in charge of > watching the packages for timeout conditions. AFAIK, there is no timeout, at least it isn't documented. You may be remembering the situation with RHL72/RHL73 and RHL8/RHL9 where I recall there was something like a timeout but that case no longer exists. > Right now, no one is AFAIK > watching for such situations, so even if something had multiple verify votes > and has stalled, no one notices and pushes it out. Seems like another > essential job waiting to be filled. Regardless of the timeout, there exists the case where VERIFY vote has been given but the fact has not been recorded in the status whiteboard, so the package is organized in the wrong place in the issues list. I've been monitoring these things, to a degree, myself, and I believe the current issue list is reasonably accurate. >> This is a tradeoff between quality, timeliness and actually delivering >> the updates. > > Your proposal as-is is no trade off. You're simply saying we should release > updates without proper testing. But it does raise a valid issue (we're not > actively watching for stalled issues, and pursuing them correctly). As said I disagree with this view, but even with this, a project like fedora legacy is even more worthless if it doesn't produce anything or doesn't do it in a sufficiently timely manner. Remember, we aren't cooking those patches ourselves. Almost all of them are directly copied from an already QA'd source (like RHEL), only a few of them require more than minor modifications. >> Because most of the folks worried about quality of the >> updates are not actually doing much of testing, I don't see why we >> should be stalling because folks seem to be using updates-testing >> instead of updates. > > If people are using testing-updates and not reporting their success, > then that is the issue, and that is what needs to be fixed. I'm not > sure if this is the case. If it is, maybe we could make posting a > success report easier (e.g. a web form they fill out?) Well, as I said half a year ago, all this fuss about PGP signatures and bugzilla turns people away. Most folks don't want to do self-introductions, pgp generations, register bugzilla accounts, etc. But at this point, I doubt there is much more to be done about it. >> If something breaks with the update, we'll just >> fix it afterwards and say "well, you should have tested the update in >> 2 weeks and reported the problems". > > And they will rightly say, "No, FL legacy released it as tested and > passing QA, so the problem is with FL and not me." If the users don't want to involve themselves in helping the project, I don't see how we should be concerned about "complaints" from such users. >> (FWIW, the current "issues" list is: >> http://www.netcore.fi/pekkas/buglist.html) > > I find posting that list is the thing that gets things rolling. In other > words, very few people even consider testing until an issue list is posted > at which point they check it out and start testing packages. I hate to say > it, but regular posting of the issue list (at least those in updates-testing > needed testing) would probably help greatly. I am not against posting the URL regularly, but I doubt it'll do much good. Those that want to know it, already do. Reposting it more than monthly probably doesn't make any difference. -- 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 jimpop at yahoo.com Thu Jun 2 19:31:11 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 02 Jun 2005 15:31:11 -0400 Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> Message-ID: <1117740671.21522.10.camel@localhost> On Thu, 2005-06-02 at 22:16 +0300, Pekka Savola wrote: > On Thu, 2 Jun 2005, Eric Rostetter wrote: > >> Something needs to > >> start happening. Ideas? > > > > People who have an interest in having packages released need to start > > doing QA (and/or other work for the group). > > We've been calling out for that for months, but that has typically > resulted in minor surges only, nothing major enough to go on with. A LOT of that is because there are a LOT of packages waiting for testing that people just plainly don't have interest in. Looking at http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that makes it difficult to focus on the 4 or 5% that I care about. Do we really need to be releasing a mozilla for rh73? Additionally, take the pending/not-pending kernel that is held up. Look at it's bugzilla report and then let me know what it's waiting on. (do this without beating your head against a wall, taking aspirin, or other drugs). The process isn't broke, the process just sadly isn't easy to be involved with. Some things on http://www.netcore.fi/pekkas/buglist-rhl73.html are also not apparently correct (or maybe bugzilla is incorrect). Take this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152827 for instance. Is it just a RH9 problem? what about this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152792 is it only RH9 too? Here's my predicament: I can test RH73 packages used in a "locked-down" server environment. So, what do I need to test? -Jim P. From rostetter at mail.utexas.edu Thu Jun 2 19:50:59 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 14:50:59 -0500 Subject: changes are needed, we need keep moving In-Reply-To: References: Message-ID: <1117741859.86d84ab3bb8e6@mail.ph.utexas.edu> Quoting Tom Yates : > i'd still prefer that we released fixes for each OS as they passed the > verify bar, instead of waiting until all affected OSes have been QA'ed > before releasing any fix; that way, we don't release untested code, but > unpopular distros can't hold the popular ones to ransom. That is much more reasonable than releasing packages without proper QA. > but if that's unacceptable to the project as a whole, then pekka, your > proposal seems sensible to me. two weeks seems like a good time. Your proposal is much better than releasing packages without proper QA. That is to say, your proposal is much more likely to be acceptable than Pekka's. -- Eric Rostetter From mattdm at mattdm.org Thu Jun 2 19:55:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 15:55:15 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117740671.21522.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> Message-ID: <20050602195515.GA3340@jadzia.bu.edu> On Thu, Jun 02, 2005 at 03:31:11PM -0400, Jim Popovitch wrote: > http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that > makes it difficult to focus on the 4 or 5% that I care about. Do we > really need to be releasing a mozilla for rh73? Yes, if we consider rh73 supported at all. There's important remote security flaws in the older version. > The process isn't broke, the process just sadly isn't easy to be > involved with. Arguably, that's broke. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From jimpop at yahoo.com Thu Jun 2 20:04:56 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 02 Jun 2005 16:04:56 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <20050602195515.GA3340@jadzia.bu.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> Message-ID: <1117742696.21522.16.camel@localhost> On Thu, 2005-06-02 at 15:55 -0400, Matthew Miller wrote: > On Thu, Jun 02, 2005 at 03:31:11PM -0400, Jim Popovitch wrote: > > http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that > > makes it difficult to focus on the 4 or 5% that I care about. Do we > > really need to be releasing a mozilla for rh73? > > Yes, if we consider rh73 supported at all. There's important remote security > flaws in the older version. I have rh73 installs that don't have mozilla installed. What's the impact on me? My question is this: Do we waste time and distract from important packages by crowding the field with application level patches for allications that few (if anyone) is using. Seriously, who is using RH73 in desktop environments? Do we have any stats on this? -Jim P. From gerry at pathtech.org Thu Jun 2 20:14:22 2005 From: gerry at pathtech.org (G. Roderick Singleton) Date: Thu, 02 Jun 2005 16:14:22 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117742696.21522.16.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> Message-ID: <1117743263.12461.9.camel@www.pathtech.org> On Thu, 2005-06-02 at 16:04 -0400, Jim Popovitch wrote: > On Thu, 2005-06-02 at 15:55 -0400, Matthew Miller wrote: > > On Thu, Jun 02, 2005 at 03:31:11PM -0400, Jim Popovitch wrote: > > > http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that > > > makes it difficult to focus on the 4 or 5% that I care about. Do we > > > really need to be releasing a mozilla for rh73? > > > > Yes, if we consider rh73 supported at all. There's important remote security > > flaws in the older version. > > I have rh73 installs that don't have mozilla installed. What's the > impact on me? > > My question is this: Do we waste time and distract from important > packages by crowding the field with application level patches for > allications that few (if anyone) is using. Seriously, who is using RH73 > in desktop environments? Do we have any stats on this? > >From the conversation on list that I had, I suspect not but in the same thread I suggested that FL help to establish a contributor repository so that those who do build apps such as mozilla for the older releases can offer them. I do not recall whether or not this was possible but it would sure ease things. Is it a possibility? -- G. Roderick Singleton PATH tech From marcdeslauriers at videotron.ca Thu Jun 2 20:23:29 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 02 Jun 2005 16:23:29 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117740671.21522.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> Message-ID: <1117743809.17100.3.camel@mdlinux> On Thu, 2005-06-02 at 15:31 -0400, Jim Popovitch wrote: > Additionally, take the pending/not-pending kernel that is held up. Look > at it's bugzilla report and then let me know what it's waiting on. (do > this without beating your head against a wall, taking aspirin, or other > drugs). It was waiting on a FC1 VERIFY. But, I just noticed someone said in bugzilla they were running it without problems, so that's good enough for me. I'll push it out to official releases tonight or tomorrow. And I am currently building a bunch of new packages for updates-testing. 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 marcdeslauriers at videotron.ca Thu Jun 2 20:24:17 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 02 Jun 2005 16:24:17 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117737879.c852097912420@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> Message-ID: <1117743857.17100.5.camel@mdlinux> On Thu, 2005-06-02 at 13:44 -0500, Eric Rostetter wrote: > I'm not against the timeout, in fact there is supposed to be a timeout > in the process, though I don't remember what it is. Perhaps we need to > revisit the timeout issue, with the goal of putting someone in charge of > watching the packages for timeout conditions. Right now, no one is AFAIK > watching for such situations, so even if something had multiple verify votes > and has stalled, no one notices and pushes it out. Seems like another > essential job waiting to be filled. I agree to the timeout. Let's decide on this list what that timeout should be and I'll watch for it. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Jun 2 20:44:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 16:44:12 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117742696.21522.16.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> Message-ID: <20050602204412.GA4998@jadzia.bu.edu> On Thu, Jun 02, 2005 at 04:04:56PM -0400, Jim Popovitch wrote: > > Yes, if we consider rh73 supported at all. There's important remote security > > flaws in the older version. > I have rh73 installs that don't have mozilla installed. What's the > impact on me? Yeah, that attitude *is* exactly the problem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mattdm at mattdm.org Thu Jun 2 20:44:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 16:44:50 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117743857.17100.5.camel@mdlinux> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> Message-ID: <20050602204450.GB4998@jadzia.bu.edu> On Thu, Jun 02, 2005 at 04:24:17PM -0400, Marc Deslauriers wrote: > I agree to the timeout. Let's decide on this list what that timeout > should be and I'll watch for it. Two weeks sounds good. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From jimpop at yahoo.com Thu Jun 2 21:10:58 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 02 Jun 2005 17:10:58 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <20050602204412.GA4998@jadzia.bu.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> <20050602204412.GA4998@jadzia.bu.edu> Message-ID: <1117746658.21522.26.camel@localhost> On Thu, 2005-06-02 at 16:44 -0400, Matthew Miller wrote: > On Thu, Jun 02, 2005 at 04:04:56PM -0400, Jim Popovitch wrote: > > > Yes, if we consider rh73 supported at all. There's important remote security > > > flaws in the older version. > > I have rh73 installs that don't have mozilla installed. What's the > > impact on me? > > Yeah, that attitude *is* exactly the problem. OK, what should be done to eliminate that attitude? Should I install mozilla on my RH73 servers just so that I have to update it? ;-) I'm not saying that because I don't use it nobody else should. What I am saying is that I don't use it and therefore don't see a need to test it. Are others using it? If so, why aren't they stepping up to test it? Do we have data on who needs what out of RH73? -Jim P. From guallar at easternrad.com Thu Jun 2 21:16:32 2005 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Thu, 2 Jun 2005 17:16:32 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117746658.21522.26.camel@localhost> References: <20050602204412.GA4998@jadzia.bu.edu> <1117746658.21522.26.camel@localhost> Message-ID: <200506021716.36186.guallar@easternrad.com> On Thursday 02 June 2005 17:10, Jim Popovitch wrote: > I'm not saying that because I don't use it nobody else should. What I > am saying is that I don't use it and therefore don't see a need to test > it. Are others using it? If so, why aren't they stepping up to test > it? Do we have data on who needs what out of RH73? I am using RHL 7.3 only as a server. No mozilla, no gnome, no kde, no X11, no nothing. Regards, Josep -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Jun 2 21:28:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 17:28:21 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117746658.21522.26.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> <20050602204412.GA4998@jadzia.bu.edu> <1117746658.21522.26.camel@localhost> Message-ID: <20050602212821.GA6651@jadzia.bu.edu> On Thu, Jun 02, 2005 at 05:10:58PM -0400, Jim Popovitch wrote: > > Yeah, that attitude *is* exactly the problem. > OK, what should be done to eliminate that attitude? Should I install > mozilla on my RH73 servers just so that I have to update it? ;-) Sorry, that came out crankier than I really meant it. Thanks for taking it lightly. :) > I'm not saying that because I don't use it nobody else should. What I > am saying is that I don't use it and therefore don't see a need to test > it. Are others using it? If so, why aren't they stepping up to test > it? Do we have data on who needs what out of RH73? It's really hard to predict what people are might be using. And, y'know, you don't want to accidentally fire up some client app on RH73 and unthinkingly access the network with it and discover your account compromised. And it's *also* really hard to get good testers for everything. It'd be nice if people (um, including me) would be able to volunteer a little extra effort to check out things that they're not absolutely needing themselves, to help the project as a whole. I keep meaning to do exactly what I'm talking about, but I'm *so* busy with work schedule right now. (Mailing list posts take much less mental effort than good package review, is my excuse here.... *grin*) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From marcdeslauriers at videotron.ca Thu Jun 2 21:37:28 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 02 Jun 2005 17:37:28 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <20050602204450.GB4998@jadzia.bu.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <20050602204450.GB4998@jadzia.bu.edu> Message-ID: <1117748248.17100.7.camel@mdlinux> On Thu, 2005-06-02 at 16:44 -0400, Matthew Miller wrote: > On Thu, Jun 02, 2005 at 04:24:17PM -0400, Marc Deslauriers wrote: > > I agree to the timeout. Let's decide on this list what that timeout > > should be and I'll watch for it. > > Two weeks sounds good. > Sounds good to me, Jesse? 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 jung at one.ekof.bg.ac.yu Thu Jun 2 22:23:22 2005 From: jung at one.ekof.bg.ac.yu (Igor =?iso-8859-2?Q?Nestorovi=E6?=) Date: Fri, 03 Jun 2005 00:23:22 +0200 Subject: changes are needed, we need keep moving In-Reply-To: <1117737879.c852097912420@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> Message-ID: <1117751002.4892.38.camel@lara> ? ?et, 02. 06. 2005. ? 13:44 -0500, Eric Rostetter ??????: > If people are using testing-updates and not reporting their success, > then that is the issue, and that is what needs to be fixed. I'm not > sure if this is the case. If it is, maybe we could make posting a > success report easier (e.g. a web form they fill out?) I think this is a good idea. I recognize myself here, sadly. Anyway, VERIFY+ on all updates-testing packages for rh9 from me (except /etc/gnome-vfs-2.0/modules/default-modules.conf issue I reported to John Dalbec, and that was from updates folder; but, maybe that was just me, since I haven't received the reply). I am using them with four-five days delay from the date of their original posting, and have found no problems. -- Igor Nestorovi? Home Page: http://jung.ekof.bg.ac.yu ICQ UIN: 31079000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ??? ?? ??? ?????? ?? ?????????? ???????? URL: From rostetter at mail.utexas.edu Fri Jun 3 02:01:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:01:33 -0500 Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> Message-ID: <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> Quoting Pekka Savola : > On Thu, 2 Jun 2005, Eric Rostetter wrote: > >> If one distribution version of a package has one VERIFY vote, all the > >> versions will automatically be released after a timeout of XX (where > >> I suggest XX is 2 weeks) from the first VERIFY -- except if someone > >> identifies issues which require discussion or more work. > > > > You might as well just publish them without testing then. One verify vote > > isn't significantly different than no verify votes. I'd say any plan > > that requires only one verify vote is worthless. > > I disagree. I'm wondering if I misunderstand what you are proposing. But I'm not sure. If you mean that it only takes 1 verify vote for any version of an update to publish an update (across all versions) than I stand by what I said. Otherwise, I'd have to ask that you clarify what you mean. > Patches are typically very similar across all the > versions. The sanity of the patches has already been checked at > PUBLISH. Checking that the program actually works in one platform is > definitely better than nothing. I didn't read your statement that way earlier. If you mean we get enough verify votes for a version, then publish the rest, fine. But I thought you said if we have one, single, lonely vote we should publish just because of a timeout, which is bad. For example, one of our first (if not our first) kernel updates published had to be immediately re-issued. It was verified by several people, so it should have been good. But all testers tested it with grub, and the problem was in lilo. So we need to have a larger number of people voting, to make sure we cover enough cases to allow the QA testing to be at all reasonable. Even with our current system, errors get through because the testing sample just isn't big enough. So I'm against anything that in principle allows us to publish with less testing in less-diverse environments. > > I'm not against the timeout, in fact there is supposed to be a timeout > > in the process, though I don't remember what it is. Perhaps we need to > > revisit the timeout issue, with the goal of putting someone in charge of > > watching the packages for timeout conditions. > > AFAIK, there is no timeout, at least it isn't documented. You may be > remembering the situation with RHL72/RHL73 and RHL8/RHL9 where I > recall there was something like a timeout but that case no longer > exists. I don't think there is anything in writing, but I think if we check the mailing lists from long ago this was covered, and a timeout was established. > > Right now, no one is AFAIK > > watching for such situations, so even if something had multiple verify > votes > > and has stalled, no one notices and pushes it out. Seems like another > > essential job waiting to be filled. > > Regardless of the timeout, there exists the case where VERIFY vote has > been given but the fact has not been recorded in the status > whiteboard, so the package is organized in the wrong place in the > issues list. Yes, this is a large part of the problem now (I've never figured out yet how to update the whiteboard). That is why I'm proposing this as a "job" that some one needs to step up and fill (remember we defined some jobs on the web site, most all of which are no filled yet). > As said I disagree with this view, but even with this, a project like > fedora legacy is even more worthless if it doesn't produce anything or > doesn't do it in a sufficiently timely manner. I may just not understand what you mean, so I'll give you that benefit of the doubt for now. > > If people are using testing-updates and not reporting their success, > > then that is the issue, and that is what needs to be fixed. I'm not > > sure if this is the case. If it is, maybe we could make posting a > > success report easier (e.g. a web form they fill out?) > > Well, as I said half a year ago, all this fuss about PGP signatures > and bugzilla turns people away. Most folks don't want to do > self-introductions, pgp generations, register bugzilla accounts, etc. Let's discuss how we can stream-line this then... > But at this point, I doubt there is much more to be done about it. Never know, maybe we can come up with something easier... > >> If something breaks with the update, we'll just > >> fix it afterwards and say "well, you should have tested the update in > >> 2 weeks and reported the problems". > > > > And they will rightly say, "No, FL legacy released it as tested and > > passing QA, so the problem is with FL and not me." > > If the users don't want to involve themselves in helping the project, > I don't see how we should be concerned about "complaints" from such > users. This is why Red Hat went commercial, and look at all the bad press they got from that, and how they got almost no good press. If you want commercial support, buy it from Red Hat or Progeny or someone. Otherwise, if you want "free" support you have to "work" for it. > I am not against posting the URL regularly, but I doubt it'll do much > good. Those that want to know it, already do. Reposting it more than > monthly probably doesn't make any difference. Actually, I think it makes a big difference. I think when it was posted weekly it made a big difference. And I know I look at it when it hits the mailing list, and I pretty much never look otherwise. So it definately has an effect on me. And I'd bet on others too. Getting it on the FL web page would also be a good thing though, and take some of the effort off you and/or others posting it e.g. weekly to the mailing list. Any progress on that yet Jesse? > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From jkeating at j2solutions.net Fri Jun 3 02:05:12 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 02 Jun 2005 19:05:12 -0700 Subject: changes are needed, we need keep moving In-Reply-To: <1117748248.17100.7.camel@mdlinux> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <20050602204450.GB4998@jadzia.bu.edu> <1117748248.17100.7.camel@mdlinux> Message-ID: <1117764312.2804.12.camel@yoda.loki.me> On Thu, 2005-06-02 at 17:37 -0400, Marc Deslauriers wrote: > Sounds good to me, Jesse? I think I can agree to that. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From rostetter at mail.utexas.edu Fri Jun 3 02:11:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:11:33 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <1117740671.21522.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> Message-ID: <1117764693.cd35718acc675@mail.ph.utexas.edu> Quoting Jim Popovitch : > A LOT of that is because there are a LOT of packages waiting for testing > that people just plainly don't have interest in. Looking at The older the OS release, the more problem that will be, indeed. > http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that > makes it difficult to focus on the 4 or 5% that I care about. Do we > really need to be releasing a mozilla for rh73? Yes. People do use mozilla on rh7, and it needs to be secure. Unfortunately there are not as many people using mozilla on rh7 as on say FC2, so it is harder to get them verified. In fact, I just upgraded some of my RH 7.3 machines to Centos, so I'll have even fewer machines to test things on. I'm sure others are doing the same. > The process isn't broke, the process just sadly isn't easy to be > involved with. We need to find ways to make it easier. The buglist postings are one way, but we need more. > Here's my predicament: I can test RH73 packages used in a "locked-down" > server environment. So, what do I need to test? Good question. I don't have an answer right now. I still have several 7.3 machines, server and desktop, but I'm slowly upgrading them to Centos 3/4, so I don't know how long I'll be able to help. But I'm a busy man, and a lazy man, and I often don't help unless I'm asked to and it is made easy. Like you, I'd love people to say "we need someone with RH 7.3 to test package X" and I'd probably do it if I could. But to go out and find out what needs testing which is almost ready for release but just needs one or two more verifies, that is something I'm not as likely to do. Hate to say it, but I'm lazy, and so are others. We need some non-lazy go-getters to make us do the work. > -Jim P. -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jun 3 02:17:28 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:17:28 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <1117742696.21522.16.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> Message-ID: <1117765048.1eaad6aa7fbdd@mail.ph.utexas.edu> Quoting Jim Popovitch : > On Thu, 2005-06-02 at 15:55 -0400, Matthew Miller wrote: > > On Thu, Jun 02, 2005 at 03:31:11PM -0400, Jim Popovitch wrote: > > > http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that > > > makes it difficult to focus on the 4 or 5% that I care about. Do we > > > really need to be releasing a mozilla for rh73? > > > > Yes, if we consider rh73 supported at all. There's important remote > security > > flaws in the older version. > > I have rh73 installs that don't have mozilla installed. What's the > impact on me? The impact on you is it helps to hold up the other updates you are interested in. > My question is this: Do we waste time and distract from important > packages by crowding the field with application level patches for > allications that few (if anyone) is using. Seriously, who is using RH73 > in desktop environments? Do we have any stats on this? No stats, but I am. I just upgraded 2 7.3 servers, so now I stand roughly a dozen 7.3 desktops left, and maybe 2 7.3 servers left. So yes, some of us still use the old systems as "desktop" systems, and not just servers. By the end of the summer, I hope to have all my 7.x systems upgraded off it though, so next year the answer will be different... > -Jim P. -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jun 3 02:36:35 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:36:35 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <20050602204412.GA4998@jadzia.bu.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> <20050602204412.GA4998@jadzia.bu.edu> Message-ID: <1117766195.8df66851f0e2e@mail.ph.utexas.edu> I've googled on FL timeouts, and it looks like at one time we said: If a similar update is available for multiple similar OS versions (e.g. for both RHL 7.2 and RHL 7.3), and has passed the publish criteria for one OS version but not for the other, the second OS version may be released after a timeout period if no one has tested it. This prevents updates from being published for one OS version due to lack of testers when it has passed on other similar OS versions and is believed to therefore be safe. Such releases are at the discretion of the Fedora Legacy package publishers. Now that surely applied to "PUBLISH" and I think it was meant to apply to "VERIFY" also. But it lacks details (what time period for the timeout, etc). >From Jesse Keating on 8-Feb-2004: Just needs some more people to look at it. Seems a few packages need either 7.2 or 8.0 or both QA before we can do anything with them. I'm going to continue with my policy of timeout on testing, and just push them if they've gotten good 7.3 feedback. If something breaks, thats really sucky, but perhaps it'll motivate the community to kick in some 7.2/8.0 love. It was the community that persuaded me to include 7.2/8.0 in the first place. Also got several bugzilla hits which say: Pushed to updates-testing due to QA timeout. So, in summary, I'd surely support something that said "if we've met the publish/verify status for one or more OS releases of a package, but not for other similar OS releases of a package, they should all be published after a timeout period of N days." For this we need to define two things yet: how many days (N), and what OS versions are similar (and this could vary by package; sometimes the package may be similar between OS versions even if the OS versions are not so close). Comments? -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jun 3 02:38:08 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:38:08 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <20050602204450.GB4998@jadzia.bu.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <20050602204450.GB4998@jadzia.bu.edu> Message-ID: <1117766288.f838d476add4e@mail.ph.utexas.edu> Quoting Matthew Miller : > On Thu, Jun 02, 2005 at 04:24:17PM -0400, Marc Deslauriers wrote: > > I agree to the timeout. Let's decide on this list what that timeout > > should be and I'll watch for it. > > Two weeks sounds good. At least 2 weeks, no more than 4 weeks. I'll agree to anything in the 2-4 week range. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > Current office temperature: 79 degrees Fahrenheit. -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jun 3 02:44:27 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Jun 2005 21:44:27 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <1117746658.21522.26.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <20050602195515.GA3340@jadzia.bu.edu> <1117742696.21522.16.camel@localhost> <20050602204412.GA4998@jadzia.bu.edu> <1117746658.21522.26.camel@localhost> Message-ID: <1117766667.d9fff231555a4@mail.ph.utexas.edu> Quoting Jim Popovitch : > > > I have rh73 installs that don't have mozilla installed. What's the > > > impact on me? > > > > Yeah, that attitude *is* exactly the problem. > > OK, what should be done to eliminate that attitude? Should I install > mozilla on my RH73 servers just so that I have to update it? ;-) Maybe you should setup a test RH7.3 server, if not a real one a virtual one (e.g. vmware, etc). > I'm not saying that because I don't use it nobody else should. What I > am saying is that I don't use it and therefore don't see a need to test > it. Only reason is to help speed up the entire process, as I said earlier. > Are others using it? Yes. > If so, why aren't they stepping up to test > it? Didn't know it was needed. If someone had directly asked, I surely would have helped out. But been busy, and didn't have time to crawl bugzilla to find out what needs to be done, etc. > Do we have data on who needs what out of RH73? No. > -Jim P. -- Eric Rostetter From pekkas at netcore.fi Fri Jun 3 05:51:49 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 08:51:49 +0300 (EEST) Subject: buglist-rhl73.html [Re: changes are needed, we need keep moving] In-Reply-To: <1117740671.21522.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> Message-ID: On Thu, 2 Jun 2005, Jim Popovitch wrote: > The process isn't broke, the process just sadly isn't easy to be > involved with. > > Some things on http://www.netcore.fi/pekkas/buglist-rhl73.html are also > not apparently correct (or maybe bugzilla is incorrect). Take this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152827 for > instance. Is it just a RH9 problem? what about this one: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152792 is it only > RH9 too? This is a feature :). You're looking at a wrong place. Note that the script only does RHL73-speficic listing for PUBLISH and VERIFY stages, because there's no guarantee that the rest are properly classified. For most QA purposes (unless you want to build packages and a little bit of something else), looking at PUBLISH and VERIFY only should be sufficient. -- 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 pekkas at netcore.fi Fri Jun 3 06:05:20 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 09:05:20 +0300 (EEST) Subject: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving] In-Reply-To: <1117764693.cd35718acc675@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> Message-ID: On Thu, 2 Jun 2005, Eric Rostetter wrote: > Quoting Jim Popovitch : > >> A LOT of that is because there are a LOT of packages waiting for testing >> that people just plainly don't have interest in. Looking at > > The older the OS release, the more problem that will be, indeed. > >> http://www.netcore.fi/pekkas/buglist-rhl73.html, I see 95% of cruft that >> makes it difficult to focus on the 4 or 5% that I care about. Do we >> really need to be releasing a mozilla for rh73? [...] If we could agree to some criteria, we could classify some bugs as "normal or high" severity and only be biggest ones "security". The latter show in the buglist in red, the former in black. Maybe that would help in identifying the most important updates. >> Here's my predicament: I can test RH73 packages used in a "locked-down" >> server environment. So, what do I need to test? > > Good question. I don't have an answer right now. I still have several > 7.3 machines, server and desktop, but I'm slowly upgrading them to > Centos 3/4, so I don't know how long I'll be able to help. Looking at: http://www.netcore.fi/pekkas/buglist-rhl73.html "All -rhl73 packages lacking VERIFY", we have for example, krb5, dhcp, [squid?], lvm, postgres, ethereal (and some others). Some of these are probably installed on a server system. I think at least krb5 and dhcp are in the default server installation. Under "All -rhl73 packages lacking PUBLISH (but excluding NEEDSWORK)", we have for example 'telnet' which is probably included in server systems as well. -- 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 pekkas at netcore.fi Fri Jun 3 06:16:45 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 09:16:45 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> Message-ID: On Thu, 2 Jun 2005, Eric Rostetter wrote: > If you mean that it only takes 1 verify vote for any version of an update > to publish an update (across all versions) than I stand by what I said. > Otherwise, I'd have to ask that you clarify what you mean. Yes, this is what I said. It currently requires 1 verify vote to VERIFY one version (in the past, the rules said two for each, but packages never got out that way so it has been taken down to 1). What I say is that if folks don't care enough to report their successes or problems within two weeks of someone formally first test of the package, they deserve what they get. That said, I could also live with two verify votes (for any version) plus the similar timeout, but I think timeliness is more important. >> Patches are typically very similar across all the >> versions. The sanity of the patches has already been checked at >> PUBLISH. Checking that the program actually works in one platform is >> definitely better than nothing. > > I didn't read your statement that way earlier. If you mean we get enough > verify votes for a version, then publish the rest, fine. But I thought > you said if we have one, single, lonely vote we should publish just > because of a timeout, which is bad. FYI, one verify vote is sufficient to VERIFY a distro version right now, so this is why I said one measly verify vote. > For example, one of our first (if not our first) kernel updates published > had to be immediately re-issued. It was verified by several people, so > it should have been good. But all testers tested it with grub, and the > problem was in lilo. So we need to have a larger number of people voting, > to make sure we cover enough cases to allow the QA testing to be at all > reasonable. Even with our current system, errors get through because > the testing sample just isn't big enough. So I'm against anything that > in principle allows us to publish with less testing in less-diverse > environments. We can't avoid these errors completely by testing, because there just aren't enough people willing to do the testing and report the errors. We'll just have to publish and revise if something breaks. > If you want commercial support, buy it from Red Hat or Progeny or someone. > Otherwise, if you want "free" support you have to "work" for it. Personally, I think this is a good principle. You may also get free support without any work, but you surely don't get the right to complain about it unless you contribute. -- 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 pekkas at netcore.fi Fri Jun 3 06:19:09 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 09:19:09 +0300 (EEST) Subject: rhl9 updates-testing verifies [Re: changes are needed, we need keep moving] In-Reply-To: <1117751002.4892.38.camel@lara> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117751002.4892.38.camel@lara> Message-ID: On Fri, 3 Jun 2005, Igor [iso-8859-2] Nestorovi^G wrote: > ?? ??et, 02. 06. 2005. ?? 13:44 -0500, Eric Rostetter ????????????: >> If people are using testing-updates and not reporting their success, >> then that is the issue, and that is what needs to be fixed. I'm not >> sure if this is the case. If it is, maybe we could make posting a >> success report easier (e.g. a web form they fill out?) > I think this is a good idea. I recognize myself here, sadly. > > Anyway, VERIFY+ on all updates-testing packages for rh9 from me > (except /etc/gnome-vfs-2.0/modules/default-modules.conf issue I reported > to John Dalbec, and that was from updates folder; but, maybe that was > just me, since I haven't received the reply). I am using them with > four-five days delay from the date of their original posting, and have > found no problems. Can you please state the exact packages (maybe you don't have everything installed) you've used. Based on http://www.netcore.fi/pekkas/buglist-rhl9.html, there are: kdelibs & kdebase krb5 gtk2 redhat-config-nfs rp-pppoe lesstif squid gd lvm postgres samba squirrelmail gaim mysql -- 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 mark.scott at csuk-solutions.net Fri Jun 3 09:01:03 2005 From: mark.scott at csuk-solutions.net (Mark Scott) Date: Fri, 03 Jun 2005 10:01:03 +0100 Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> Message-ID: <42A01C4F.3050806@csuk-solutions.net> Pekka Savola wrote: > On Thu, 2 Jun 2005, Eric Rostetter wrote: > >> If you mean that it only takes 1 verify vote for any version of an update >> to publish an update (across all versions) than I stand by what I said. >> Otherwise, I'd have to ask that you clarify what you mean. > > > Yes, this is what I said. It currently requires 1 verify vote to VERIFY > one version (in the past, the rules said two for each, but packages > never got out that way so it has been taken down to 1). > > What I say is that if folks don't care enough to report their successes > or problems within two weeks of someone formally first test of the > package, they deserve what they get. > > That said, I could also live with two verify votes (for any version) > plus the similar timeout, but I think timeliness is more important. > So... if I verify a package for FC1 or FC2 (the distros I have access to) then I can personally remove the 'verify-core1' or 'verify-fc2' from the whiteboard? I never wanted to do this in the past when it was 2 verifies as I assumed the Reporter / Assignee was responsible for this. With regards to verifying packages, there are several waiting for a verify on FC1 or FC2 that I would not feel comfortable verifying because I do not (or never have) used them, e.g. PostgreSQL, rp-pppoe, squirrelmail, gftp, ethereal. Obviously if this is true of all verifiers then this is a problem that will block their release. -- Mark Scott CSUK Solutions Technical Team Tel: +44 (0)845 6444 185 Email: mark.scott at csuk-solutions.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From shiva at sewingwitch.com Fri Jun 3 09:34:31 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 03 Jun 2005 02:34:31 -0700 Subject: changes are needed, we need keep moving In-Reply-To: <42A01C4F.3050806@csuk-solutions.net> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <42A01C4F.3050806@csuk-solutions.net> Message-ID: --On Friday, June 03, 2005 10:01 AM +0100 Mark Scott wrote: > With regards to verifying packages, there are several waiting for a > verify on FC1 or FC2 that I would not feel comfortable verifying because > I do not (or never have) used them, e.g. PostgreSQL, rp-pppoe, > squirrelmail, gftp, ethereal. Obviously if this is true of all verifiers > then this is a problem that will block their release. Was just looking at and see that all the Bugzilla links still point to fedora.us. Is there a query that will give all packages awaiting QA for a given releasever? Or should I just check the appropriate updates-testing repo? From pekkas at netcore.fi Fri Jun 3 10:00:33 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 13:00:33 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <42A01C4F.3050806@csuk-solutions.net> Message-ID: On Fri, 3 Jun 2005, Kenneth Porter wrote: >> With regards to verifying packages, there are several waiting for a >> verify on FC1 or FC2 that I would not feel comfortable verifying because >> I do not (or never have) used them, e.g. PostgreSQL, rp-pppoe, >> squirrelmail, gftp, ethereal. Obviously if this is true of all verifiers >> then this is a problem that will block their release. > > Was just looking at > and see that all the Bugzilla links still point to fedora.us. This should be fixed... > Is there a query that will give all packages awaiting QA for a given > releasever? Or should I just check the appropriate updates-testing repo? Yes, but the queries are pretty complex. These pick that stuff from the bugzilla for you: 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 As pointed out earlier, the release differentiation is only done for packages waiting for VERIFY or PUBLISH votes. -- 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 pekkas at netcore.fi Fri Jun 3 10:06:11 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 13:06:11 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: <42A01C4F.3050806@csuk-solutions.net> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <42A01C4F.3050806@csuk-solutions.net> Message-ID: On Fri, 3 Jun 2005, Mark Scott wrote: > So... if I verify a package for FC1 or FC2 (the distros I have access > to) then I can personally remove the 'verify-core1' or 'verify-fc2' from > the whiteboard? I never wanted to do this in the past when it was 2 > verifies as I assumed the Reporter / Assignee was responsible for this. You can do this, if you're able to. I'm not 100% sure whether this requires special permissions -- this may be something that only the reporter/assignee can do (and people with special bugzilla privileges, like myself). > With regards to verifying packages, there are several waiting for a > verify on FC1 or FC2 that I would not feel comfortable verifying because > I do not (or never have) used them, e.g. PostgreSQL, rp-pppoe, > squirrelmail, gftp, ethereal. Obviously if this is true of all verifiers > then this is a problem that will block their release. I've sometimes came across this issue. For simple applications like ethereal and gftp (which can be easily installed and tested), I've done the testing even if I hadn't used the application at all (or only very little). But I wouldn't feel comfortable testing a package which requires more complex set-up (like postgresql), but maybe that has been part laziness in my mind :) -- 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 guallar at easternrad.com Fri Jun 3 14:11:26 2005 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Fri, 3 Jun 2005 10:11:26 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <1117764693.cd35718acc675@mail.ph.utexas.edu> References: <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> Message-ID: <200506031011.29096.guallar@easternrad.com> On Thursday 02 June 2005 22:11, Eric Rostetter wrote: > In fact, I just upgraded some of my RH 7.3 machines to Centos, so I'll > have even fewer machines to test things on. ?I'm sure others are doing > the same. To what version of CentOS ? Were they servers or desktops? Did you found any trouble? Do you know of any upgrade-HOWTO url ? I'd like to upgrade my RHL 7.3 to CentOS for peace of mind. Regards, Josep -- Josep L. Guallar-Esteve Eastern Radiologists, Inc. Systems and PACS Administration http://www.easternrad.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rostetter at mail.utexas.edu Fri Jun 3 15:54:40 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Jun 2005 10:54:40 -0500 Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> Message-ID: <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> Quoting Pekka Savola : > On Thu, 2 Jun 2005, Eric Rostetter wrote: > > If you mean that it only takes 1 verify vote for any version of an update > > to publish an update (across all versions) than I stand by what I said. > > Otherwise, I'd have to ask that you clarify what you mean. > > Yes, this is what I said. It currently requires 1 verify vote to > VERIFY one version (in the past, the rules said two for each, but > packages never got out that way so it has been taken down to 1). That is very bad. We really need to restore it to 2 votes. One vote isn't enough. Seriously. If we're not able to get 2 votes, then plea to the list for the second. If we still don't get 2 votes then we need to disband this project, or change it into a different project. Seriously, if we can't get 2 votes for a package, then there is a real problem going on. > What I say is that if folks don't care enough to report their > successes or problems within two weeks of someone formally first test > of the package, they deserve what they get. That isn't the point of the project though. It would be much better to get two votes. Heck, if you do one, and I do one, we're done. The only time that would be a problem is the once or twice a year we go on vacation. > That said, I could also live with two verify votes (for any version) > plus the similar timeout, but I think timeliness is more important. I can agree to 2 votes plus timeout. If we give 2 weeks for the votes, and 2 additional weeks for the timeout, then everything is done in one month. Sounds reasonable to me. > FYI, one verify vote is sufficient to VERIFY a distro version right > now, so this is why I said one measly verify vote. I wasn't aware of this; last I knew we still needed two votes. How/when did this change? > We can't avoid these errors completely by testing, because there just > aren't enough people willing to do the testing and report the errors. > We'll just have to publish and revise if something breaks. But we can try better/harder to get more votes (including say, getting me to test/vote more, and getting those who run updates-testing but don't vote to vote). Worst of all is things like the recent post of "I reported a problem with package X to person Y but never heard back about it." > > If you want commercial support, buy it from Red Hat or Progeny or someone. > > Otherwise, if you want "free" support you have to "work" for it. > > Personally, I think this is a good principle. You may also get free > support without any work, but you surely don't get the right to > complain about it unless you contribute. But this list is a complaint heaven right now. We need to address this as a real problem, and try to get a real solution. Stopping the testing isn't a real solution. > -- > 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 > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jun 3 16:21:07 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Jun 2005 11:21:07 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <200506031011.29096.guallar@easternrad.com> References: <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <200506031011.29096.guallar@easternrad.com> Message-ID: <1117815667.bbda7f5a46a56@mail.ph.utexas.edu> Quoting "Josep L. Guallar-Esteve" : > On Thursday 02 June 2005 22:11, Eric Rostetter wrote: > > In fact, I just upgraded some of my RH 7.3 machines to Centos, so I'll > > have even fewer machines to test things on. I'm sure others are doing > > the same. > > To what version of CentOS ? Centos 3.5, via a "yum" package upgrade. Not recommended unless you are fearless. > Were they servers or desktops? Servers. One a print server, the other a NFS server. > Did you found any trouble? The print server went without too much trouble. Had to reconfigure the web interface to cups, other than that it worked fine. The NFS server had more problems, mostly NIS related. But in the end it seems to be working. > Do you know of any upgrade-HOWTO url ? There are lots on the net for going from RHL 9 to Centos 3. They all basically apply to RHL 7.x and 8.x as well. Just google. > I'd like to upgrade my RHL 7.3 to CentOS for peace of mind. Best way, not the way I did, is a fresh install. If that isn't possible, then the next best way is to do it from the cd-rom (at the boot prompt, use the undocumented 'upgradeany' of something like that; see google for details). If that doesn't work for you, you can try the live yum upgrade like I did, but it isn't really recommended, and yes you will probably have problems here and there (I was surpised my print server had no actual problems; I wasn't surprised the NFS server had lots of problems). Whether or not it is a good idea depends on how loaded your system is. The more packages, the less likely it is to work. My print server has very few packages, so it worked. My NFS server also has few packages, but some things like NIS support seem to have changed over the years. > Regards, > Josep > -- > Josep L. Guallar-Esteve Eastern Radiologists, Inc. > Systems and PACS Administration http://www.easternrad.com -- Eric Rostetter From mschout at gkg.net Fri Jun 3 16:53:59 2005 From: mschout at gkg.net (Michael Schout) Date: Fri, 03 Jun 2005 11:53:59 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> Message-ID: <42A08B27.9090508@gkg.net> Eric Rostetter wrote: > If we're not able to get 2 votes, then plea to the list for the second. > If we still don't get 2 votes then we need to disband this project, or > change it into a different project. > > Seriously, if we can't get 2 votes for a package, then there is a real > problem going on. Its hard to get even *ONE* vote! Just look at all of the packages waiting on VERIFY and/or PUBLISH votes in bugzilla, and look at how long they have been there. There simply are not enough people willing to put the time in to do QA testing. Regards, Michael Schout From jimpop at yahoo.com Fri Jun 3 17:07:56 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 03 Jun 2005 13:07:56 -0400 Subject: changes are needed, we need keep moving In-Reply-To: <42A08B27.9090508@gkg.net> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> <42A08B27.9090508@gkg.net> Message-ID: <1117818476.9828.2.camel@localhost> On Fri, 2005-06-03 at 11:53 -0500, Michael Schout wrote: > > Its hard to get even *ONE* vote! Just look at all of the packages > waiting on VERIFY and/or PUBLISH votes in bugzilla, and look at how long > they have been there. There simply are not enough people willing to put > the time in to do QA testing. Who runs the download server(s)? We need real factual data about what packages are being downloaded. I vote that we DROP packages (or publish a dummy package?) for which nobody is willing to test. -Jim P. From jimpop at yahoo.com Fri Jun 3 17:52:13 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 03 Jun 2005 13:52:13 -0400 Subject: Multiple Kerberos vulnerabilities (ID: 152773) Message-ID: <1117821133.9828.13.camel@localhost> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152773 I believe that this problem only affects those using Kerberos with a KDC, and that it does NOT affect those that just happen to have krb5-libs installed (due to RPM dependencies). Does anyone use Kerberos with RH73? Can you test this? If not can someone come up with a testing plan/strategy? -Jim P. From rostetter at mail.utexas.edu Fri Jun 3 18:35:43 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Jun 2005 13:35:43 -0500 Subject: changes are needed, we need keep moving In-Reply-To: <42A08B27.9090508@gkg.net> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> <42A08B27.9090508@gkg.net> Message-ID: <1117823743.be44c10b0c7a5@mail.ph.utexas.edu> Quoting Michael Schout : > Eric Rostetter wrote: > > > If we're not able to get 2 votes, then plea to the list for the second. > > If we still don't get 2 votes then we need to disband this project, or > > change it into a different project. > > > > Seriously, if we can't get 2 votes for a package, then there is a real > > problem going on. > > Its hard to get even *ONE* vote! Just look at all of the packages > waiting on VERIFY and/or PUBLISH votes in bugzilla, and look at how long > they have been there. There simply are not enough people willing to put > the time in to do QA testing. Then we need to do a better job of getting people to vote. As I already said, I can be coherced into voting, but someone has to do the cohercing. Right now, no one is actively pursuing getting people to vote, and hence people are not voting. The solution is to get people to test/vote, not to remove the testing/QA. And before you ask, yes, I really am serious about that. > Regards, > Michael Schout -- Eric Rostetter From colman at ppllc.com Fri Jun 3 19:16:44 2005 From: colman at ppllc.com (Jake Colman) Date: Fri, 03 Jun 2005 15:16:44 -0400 Subject: Two NIC Routing Question In-Reply-To: <1117727279.2617.5.camel@laptop.blackstar.nl> (Bas Vermeulen's message of "Thu, 02 Jun 2005 17:47:59 +0200") References: <1117662176.3498.4.camel@mdlinux> <76br6oc0a2.fsf@newjersey.ppllc.com> <1117727279.2617.5.camel@laptop.blackstar.nl> Message-ID: <76ekbj9roj.fsf@newjersey.ppllc.com> >>>>> "BV" == Bas Vermeulen writes: BV> You have 192.168.0.254 configured as your gateway ( in BV> /etc/sysconfig/network). Remove that entry, and let dhcp set it for you. BV> dhcp won't set your default gateway if it's already set. BINGO!!! I removed "NETWORK=" from /etc/sysconfig/network and all is well again. Interestingly, with RH 7.2 (from where this server started on its way to FC1) this worked anyway. Thanks for everyone's help! -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 (201) 209-2467 www.principiapartners.com From rostetter at mail.utexas.edu Fri Jun 3 19:55:38 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Jun 2005 14:55:38 -0500 Subject: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving] In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> Message-ID: <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> Quoting Pekka Savola : > "All -rhl73 packages lacking VERIFY", we have for example, > > krb5, dhcp, [squid?], lvm, postgres, ethereal (and some others). Some I just sent a VERIFY for krb5 and ethereal on 7.3 (I'd previously done ethereal on RHL 9). I can't change the status whiteboard (says I have to be the bug owner, or have super powers I don't possess). So, if someone can take on the job of changing whiteboard status for those, great. I see all bugzilla stuff is sent to a email list "bugs at fedoralegacy.org" and I note it would be cool if I could see all the bugzilla things, so I'm wondering if there is anyway someone could get added to that "bugs" address, or if another list could be setup and automatically added to each FL bug, so people could elect to get all bugzilla activity? I'll do more QA when I can (probably this weekend) on RHL 7.3 and RHL 9. I don't run FC releases, so someone else will have to do those. -- Eric Rostetter From bvermeul at blackstar.nl Fri Jun 3 20:05:30 2005 From: bvermeul at blackstar.nl (Bas Vermeulen) Date: Fri, 03 Jun 2005 22:05:30 +0200 Subject: Two NIC Routing Question In-Reply-To: <76ekbj9roj.fsf@newjersey.ppllc.com> References: <1117662176.3498.4.camel@mdlinux> <76br6oc0a2.fsf@newjersey.ppllc.com> <1117727279.2617.5.camel@laptop.blackstar.nl> <76ekbj9roj.fsf@newjersey.ppllc.com> Message-ID: <1117829130.2719.1.camel@laptop.blackstar.nl> On Fri, 2005-06-03 at 21:16, Jake Colman wrote: > >>>>> "BV" == Bas Vermeulen writes: > > BV> You have 192.168.0.254 configured as your gateway ( in > BV> /etc/sysconfig/network). Remove that entry, and let dhcp set it for you. > BV> dhcp won't set your default gateway if it's already set. > > BINGO!!! > > I removed "NETWORK=" from /etc/sysconfig/network and all is well again. > Interestingly, with RH 7.2 (from where this server started on its way to FC1) > this worked anyway. I think this is accidental though. The line to remove should be GATEWAY=x.x.x.x, not NETWORK=. RH 7.2 had the gateway in ifcfg-eth? I believe, but I'm not entirely sure. Regards, Bas Vermeulen From jkosin at beta.intcomgrp.com Fri Jun 3 20:26:22 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 03 Jun 2005 16:26:22 -0400 Subject: Kernel-2.4.22-1.2199.4.legacy.nptl Problems Message-ID: <42A0BCEE.6050009@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everyone, I'm having problems with the Kernel-2.4.22-1.2199.4.legacy.nptl build of the kernel. Things work OK in the 2.4.22-1.2199.nptl last released by Fedora group for FC1. The problem is the IDE-TAPE module not working correctly after the changes. I'm not sure of the problem.... Nothing in the IDE directory of the kernel has changed. Anyone have a clue as to where? I've also tried the latest 2.4.31 kernel source also whitch is also broken for me. I've included information below to the Linux ide-tape group who say that I should try using ide-scsi; but, alas, that is also broke for me. I'm willing to send a complete diff from 2.4.22-1.2199 sources and the 2.4.22-1.2199.4.legacy build for anyone willing to look at it. Any Ideas? Thanks, James Kosin | Information follows: | | | lspci info | | 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host | bridge (rev 03) | | 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP | bridge | (rev 03) | | 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) | | 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) | | 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) | | 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) | | 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 | (rev 10) | | 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX | (rev 20) | | 00:0b.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro | 215GP (rev 5c) | | /proc/ide/piix info | | | | Controller: 0 | | | | Intel PIIX4 Ultra 33 Chipset. | | --------------- Primary Channel ---------------- Secondary Channel | - ------------- | | enabled enabled | | --------------- drive0 --------- drive1 -------- drive0 ---------- | drive1 ------ | | DMA enabled: yes yes yes no | | UDMA enabled: yes yes yes no | | UDMA enabled: 2 2 2 X | | UDMA | | DMA | | PIO | | /proc/ide/hdd info | /proc/ide/hdd/driver | | ide-tape version 1.17c | /proc/ide/hdd/media | | tape | /proc/ide/hdd/model | | HP COLORADO 20GB | /proc/ide/hdd/name | | ht0 | /proc/ide/hdd/settings | | name value min max mode | | ---- ----- --- --- ---- | | avg_speed 0 0 | 65535 r | | buffer 432 0 | 32767 r | | current_speed 34 0 | 70 rw | | debug_level 5 0 | 65535 rw | | dsc_overlap 1 0 | 1 rw | | init_speed 34 0 | 70 rw | | io_32bit 0 0 | 3 rw | | keepsettings 0 0 | 1 rw | | nice1 1 0 | 1 rw | | number 3 0 | 3 rw | | pio_mode write-only 0 | 255 w | | pipeline 6336 32 | 2097120 rw | | pipeline_head_speed_c 0 0 | 65535 r | | pipeline_head_speed_u 0 0 | 65535 r | | pipeline_max 12672 32 | 2097120 rw | | pipeline_min 32 32 | 2097120 rw | | pipeline_pending 0 0 | 2097120 r | | pipeline_used 0 0 | 2097120 r | | slow 0 0 | 1 rw | | speed 650 0 | 65535 r | | stage 32 0 | 63 r | | tdsc 100 50 | 400 rw | | unmaskirq 0 0 | 1 rw | | using_dma 0 0 | 1 rw | | a deatiled log extracted from | /var/log/messages | | May 25 11:07:58 beta kernel: ide-tape: Dumping ATAPI Identify Device | tape parameters | | May 25 11:07:58 beta kernel: ide-tape: Protocol Type: ATAPI | | May 25 11:07:58 beta kernel: ide-tape: Device Type: 1 - Streaming | Tape | Device | | May 25 11:07:58 beta kernel: ide-tape: Removable: Yes | | May 25 11:07:58 beta kernel: ide-tape: Command Packet DRQ Type: | Interrupt DRQ | | May 25 11:07:58 beta kernel: ide-tape: Command Packet Size: 12 bytes | | May 25 11:07:58 beta kernel: ide-tape: Model: HP COLORADO 20GB | | May 25 11:07:58 beta kernel: ide-tape: Firmware Revision: 4.010000 | | May 25 11:07:58 beta kernel: ide-tape: Serial Number: MX00942598 | | May 25 11:07:58 beta kernel: ide-tape: Write buffer size: 0 bytes | | May 25 11:07:58 beta kernel: ide-tape: DMA: Yes | | May 25 11:07:58 beta kernel: ide-tape: LBA: Yes | | May 25 11:07:58 beta kernel: ide-tape: IORDY can be disabled: Yes | | May 25 11:07:58 beta kernel: ide-tape: IORDY supported: Yes | | May 25 11:07:58 beta kernel: ide-tape: ATAPI overlap supported: No | | May 25 11:07:58 beta kernel: ide-tape: PIO Cycle Timing Category: 2 | | May 25 11:07:58 beta kernel: ide-tape: DMA Cycle Timing Category: 2 | | May 25 11:07:58 beta insmod: Module ide-tape loaded, with warnings | | May 25 11:07:58 beta kernel: ide-tape: Single Word DMA supported | modes: 0 1 2 | | May 25 11:07:58 beta kernel: ide-tape: Multi Word DMA supported | modes: | 0 1 2 (active) | | May 25 11:07:58 beta kernel: ide-tape: Enhanced PIO Modes: Mode 3 | | May 25 11:07:58 beta kernel: ide-tape: Minimum Multi-word DMA cycle | per word: 120 ns | | May 25 11:07:58 beta kernel: ide-tape: Manufacturer's Recommended | Multi-word cycle: 120 ns | | May 25 11:07:58 beta kernel: ide-tape: Minimum PIO cycle without | IORDY: 240 ns | | May 25 11:07:58 beta kernel: ide-tape: Minimum PIO cycle with IORDY: | 120 ns | | May 25 11:07:58 beta kernel: hdd: attached ide-tape driver. | | May 25 11:07:58 beta kernel: ide-tape: hdd <-> ht0: HP COLORADO 20GB | rev 4.01 | | May 25 11:07:58 beta kernel: ide-tape: hdd: overriding | capabilities->speed (assuming 650KB/sec) | | May 25 11:07:58 beta kernel: ide-tape: hdd: overriding | capabilities->max_speed (assuming 650KB/sec) | | May 25 11:07:58 beta kernel: ide-tape: Dumping the results of the | MODE | SENSE packet command | | May 25 11:07:58 beta kernel: ide-tape: Mode Parameter Header: | | May 25 11:07:58 beta kernel: ide-tape: Mode Data Length - 23 | | May 25 11:07:58 beta kernel: ide-tape: Medium Type - 0 | | May 25 11:07:58 beta kernel: ide-tape: Device Specific Parameter - 16 | | May 25 11:07:58 beta kernel: ide-tape: Block Descriptor Length - 0 | | May 25 11:07:58 beta kernel: ide-tape: Capabilities and Mechanical | Status Page: | | May 25 11:07:58 beta kernel: ide-tape: Page code - 42 | | May 25 11:07:58 beta kernel: ide-tape: Page length - 18 | | May 25 11:07:58 beta kernel: ide-tape: Read only - No | | May 25 11:07:58 beta kernel: ide-tape: Supports reverse space - Yes | | May 25 11:07:58 beta kernel: ide-tape: Supports erase initiated | formatting - Yes | | May 25 11:07:58 beta kernel: ide-tape: Supports QFA two Partition | format - Yes | | May 25 11:07:58 beta kernel: ide-tape: Supports locking the medium | - No | | May 25 11:07:58 beta kernel: ide-tape: The volume is currently | locked - No | | May 25 11:07:58 beta kernel: ide-tape: The device defaults in the | prevent state - No | | May 25 11:07:58 beta kernel: ide-tape: Supports ejecting the | medium - No | | May 25 11:07:58 beta kernel: ide-tape: Supports error correction - | Yes | | May 25 11:07:58 beta kernel: ide-tape: Supports data compression - No | | May 25 11:07:58 beta kernel: ide-tape: Supports 512 bytes block | size - Yes | | May 25 11:07:58 beta kernel: ide-tape: Supports 1024 bytes block | size - No | | May 25 11:07:58 beta kernel: ide-tape: Supports 32768 bytes block | size | / Restricted byte count for PIO transfers - No | | May 25 11:07:58 beta kernel: ide-tape: Maximum supported speed in | KBps | - - 650 | | May 25 11:07:58 beta kernel: ide-tape: Continuous transfer limits in | blocks - 64 | | May 25 11:07:58 beta kernel: ide-tape: Current speed in KBps - 650 | | May 25 11:07:58 beta kernel: ide-tape: Buffer size - 442368 | | May 25 11:07:58 beta kernel: ide-tape: Adjusted block size - 512 | | May 25 11:07:58 beta kernel: ide-tape: hdd <-> ht0: 650KBps, 13*32kB | buffer, 6336kB pipeline, 100ms tDSC | | May 25 11:07:58 beta kernel: ide-tape: Reached idetape_chrdev_open | | May 25 11:07:58 beta kernel: ide-tape: Block location is unknown to | the tape | | May 25 11:07:58 beta kernel: ide-tape: Block location is unknown to | the tape | | May 25 11:07:58 beta kernel: ide-tape: ht0: I/O error, pc = 0, key = | 3, asc = 30, ascq = 0 | | May 25 11:07:58 beta kernel: ide-tape: ht0: drive not ready | /// I set logging to debug_level 5 here!!! | /// re-ran mt -f /dev/ht0 status | | May 25 11:09:51 beta kernel: ide-tape: Reached idetape_chrdev_open | | May 25 11:09:51 beta kernel: ide-tape: Reached idetape_read_position | | May 25 11:09:51 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:51 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:51 beta kernel: ide-tape: Retry number - 0, cmd = 34 | | May 25 11:09:51 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:51 beta kernel: ide-tape: [cmd 34] done 20 | | May 25 11:09:51 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:51 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:51 beta kernel: ide-tape: Reached | idetape_read_position_callback | | May 25 11:09:51 beta kernel: ide-tape: BOP - No | | May 25 11:09:51 beta kernel: ide-tape: EOP - No | | May 25 11:09:51 beta kernel: ide-tape: Block location is unknown to | the tape | | May 25 11:09:51 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_rewind_tape | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 01 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_callback | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 34 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: [cmd 34]: check condition | | May 25 11:09:52 beta kernel: ide-tape: pc_stack_index=5 | | May 25 11:09:52 beta kernel: ide-tape: rq_stack_index=5 | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 03 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 3] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_request_sense_callback | | May 25 11:09:52 beta kernel: ide-tape: pc = 34, sense key = 2, asc = | 3a, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: pc = READ_POSITION_CMD, sense | key = 2, asc = 3a, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 91, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 1, cmd = 34 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 34] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_read_position_callback | | May 25 11:09:52 beta kernel: ide-tape: BOP - No | | May 25 11:09:52 beta kernel: ide-tape: EOP - No | | May 25 11:09:52 beta kernel: ide-tape: Block location is unknown to | the tape | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 00 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: [cmd 0]: check condition | | May 25 11:09:52 beta kernel: ide-tape: pc_stack_index=6 | | May 25 11:09:52 beta kernel: ide-tape: rq_stack_index=6 | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 03 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 3] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_request_sense_callback | | May 25 11:09:52 beta kernel: ide-tape: pc = 0, sense key = 3, asc = | 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: pc = TEST_UNIT_READY_CMD, | sense | key = 3, asc = 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 91, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 1, cmd = 00 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: [cmd 0]: check condition | | May 25 11:09:52 beta kernel: ide-tape: pc_stack_index=7 | | May 25 11:09:52 beta kernel: ide-tape: rq_stack_index=7 | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 03 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 3] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_request_sense_callback | | May 25 11:09:52 beta kernel: ide-tape: pc = 0, sense key = 3, asc = | 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: pc = TEST_UNIT_READY_CMD, | sense | key = 3, asc = 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 91, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 2, cmd = 00 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: [cmd 0]: check condition | | May 25 11:09:52 beta kernel: ide-tape: pc_stack_index=8 | | May 25 11:09:52 beta kernel: ide-tape: rq_stack_index=8 | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 03 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 3] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_request_sense_callback | | May 25 11:09:52 beta kernel: ide-tape: pc = 0, sense key = 3, asc = | 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: pc = TEST_UNIT_READY_CMD, | sense | key = 3, asc = 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 91, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 3, cmd = 00 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 0 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: [cmd 0]: check condition | | May 25 11:09:52 beta kernel: ide-tape: pc_stack_index=9 | | May 25 11:09:52 beta kernel: ide-tape: rq_stack_index=9 | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 90, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: Retry number - 0, cmd = 03 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: [cmd 3] done 20 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_intr | interrupt handler | | May 25 11:09:52 beta kernel: ide-tape: Packet command completed, 20 | bytes transferred | | May 25 11:09:52 beta kernel: ide-tape: Reached | idetape_request_sense_callback | | May 25 11:09:52 beta kernel: ide-tape: pc = 0, sense key = 3, asc = | 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: pc = TEST_UNIT_READY_CMD, | sense | key = 3, asc = 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: rq_status: 1, rq_dev: 5696, | cmd: 91, errors: 0 | | May 25 11:09:52 beta kernel: ide-tape: sector: 0, nr_sectors: 0, | current_nr_sectors: 0 | | May 25 11:09:52 beta kernel: ide-tape: ht0: I/O error, pc = 0, key = | 3, asc = 30, ascq = 0 | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_pc_callback | | May 25 11:09:52 beta kernel: ide-tape: Reached idetape_end_request | | May 25 11:09:52 beta kernel: ide-tape: ht0: drive not ready -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCoLztkNLDmnu1kSkRAn2nAJ0SRLTbNAEa+Y42tRsrPbi/k9DLhACfZt4r 6xACcE9pxmhGEywD398KmpA= =FrA8 -----END PGP SIGNATURE----- From pekkas at netcore.fi Fri Jun 3 20:22:53 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jun 2005 23:22:53 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> Message-ID: On Fri, 3 Jun 2005, Eric Rostetter wrote: >>> If you mean that it only takes 1 verify vote for any version of an update >>> to publish an update (across all versions) than I stand by what I said. >>> Otherwise, I'd have to ask that you clarify what you mean. >> >> Yes, this is what I said. It currently requires 1 verify vote to >> VERIFY one version (in the past, the rules said two for each, but >> packages never got out that way so it has been taken down to 1). > > That is very bad. We really need to restore it to 2 votes. One vote > isn't enough. Seriously. > > If we're not able to get 2 votes, then plea to the list for the second. > If we still don't get 2 votes then we need to disband this project, or > change it into a different project. > > Seriously, if we can't get 2 votes for a package, then there is a real > problem going on. It's pretty clear we've had a real problem going on for a long time. (A smaller, specific instance of lack of testing seems to be that sufficiently many people aren't interested in FC1/FC2 and lack of verifies for those stall the updates for other distros.) >> What I say is that if folks don't care enough to report their >> successes or problems within two weeks of someone formally first test >> of the package, they deserve what they get. > > That isn't the point of the project though. It would be much better to > get two votes. Heck, if you do one, and I do one, we're done. The only > time that would be a problem is the once or twice a year we go on vacation. That doesn't seem to have happened all that much, however. >> That said, I could also live with two verify votes (for any version) >> plus the similar timeout, but I think timeliness is more important. > > I can agree to 2 votes plus timeout. If we give 2 weeks for the votes, > and 2 additional weeks for the timeout, then everything is done in one > month. Sounds reasonable to me. 4 weeks is a long time for more important security bugs. 2 weeks is maximum after the stuff has been pushed to updates-testing (which typically has also taken quite a while). >> FYI, one verify vote is sufficient to VERIFY a distro version right >> now, so this is why I said one measly verify vote. > > I wasn't aware of this; last I knew we still needed two votes. How/when > did this change? A long time ago, maybe a bit over 6 months or so ago. >> We can't avoid these errors completely by testing, because there just >> aren't enough people willing to do the testing and report the errors. >> We'll just have to publish and revise if something breaks. > > But we can try better/harder to get more votes (including say, getting me > to test/vote more, and getting those who run updates-testing but don't > vote to vote). I encourage you and others to do that. However, IMHO, we've stalled already long enough with that and folks (yourself included) have started (or already done) moved away from some releases. I suggest we make some process changes now (I don't specify which, but the impact has to be significant), AND you (and others) try to get more people to do QA as well. -- 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 michal at harddata.com Fri Jun 3 20:25:50 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 3 Jun 2005 14:25:50 -0600 Subject: Two NIC Routing Question In-Reply-To: <1117829130.2719.1.camel@laptop.blackstar.nl>; from bvermeul@blackstar.nl on Fri, Jun 03, 2005 at 10:05:30PM +0200 References: <1117662176.3498.4.camel@mdlinux> <76br6oc0a2.fsf@newjersey.ppllc.com> <1117727279.2617.5.camel@laptop.blackstar.nl> <76ekbj9roj.fsf@newjersey.ppllc.com> <1117829130.2719.1.camel@laptop.blackstar.nl> Message-ID: <20050603142550.A27254@mail.harddata.com> On Fri, Jun 03, 2005 at 10:05:30PM +0200, Bas Vermeulen wrote: > > I think this is accidental though. The line to remove should be > GATEWAY=x.x.x.x, not NETWORK=. > > RH 7.2 had the gateway in ifcfg-eth? I believe, but I'm not entirely > sure. GATEWAY=x.x.x.x may show up in one place or another. If you have a machine with multiple network interfaces then various interfaces may have different gateways although often you want a default one. Michal From shiva at sewingwitch.com Sat Jun 4 07:30:08 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 04 Jun 2005 00:30:08 -0700 Subject: changes are needed, we need keep moving In-Reply-To: <42A08B27.9090508@gkg.net> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> <42A08B27.9090508@gkg.net> Message-ID: <453C84022824E7E7234C96A8@[10.0.0.14]> --On Friday, June 03, 2005 11:53 AM -0500 Michael Schout wrote: > Its hard to get even *ONE* vote! Just look at all of the packages > waiting on VERIFY and/or PUBLISH votes in bugzilla, and look at how long > they have been there. There simply are not enough people willing to put > the time in to do QA testing. There's some degree of awareness problem. How many people using FC2 and earlier are even aware of this list? How many read the whole page in the wiki on how to QA packages? How many then go on to make a GPG key? For packages anywhere in the process, you might get more traction by going upstream for each package and posting the status and links to that package's upstream mailing list or newsgroup. I generally join the lists for the packages critical to my server and often upgrade to the upstream version if an RPM is available. If there's a devel list for a package, you could get permission to CC bugs to that list. From pekkas at netcore.fi Sat Jun 4 18:56:26 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 4 Jun 2005 21:56:26 +0300 (EEST) Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> Message-ID: On Fri, 3 Jun 2005, Eric Rostetter wrote: > I see all bugzilla stuff is sent to a email list "bugs at fedoralegacy.org" > and I note it would be cool if I could see all the bugzilla things, so I'm > wondering if there is anyway someone could get added to that "bugs" > address, or if another list could be setup and automatically added to each > FL bug, so people could elect to get all bugzilla activity? Good to bring up bugs at fedoralegacy.org. It seems to me that we should, 1) create a web-accessible mail archive of all of these mails, and/or 2) make that "mailing-list" subscribable. -- 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 Sat Jun 4 19:26:48 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Jun 2005 15:26:48 -0400 Subject: Fedora Legacy Test Update Notification: spamassassin Message-ID: <42A20078.6010609@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-129284 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129284 2005-06-04 --------------------------------------------------------------------- Name : spamassassin Versions : fc2: spamassassin-2.64-2.1.legacy Summary : Spam filter for email which can be invoked from mail delivery agents. Description : SpamAssassin provides you with a way to reduce if not completely eliminate Unsolicited Commercial Email (SPAM) from your incoming email. It can be invoked by a MDA such as sendmail or postfix, or can be called from a procmail script, .forward file, etc. It uses a genetic-algorithm evolved scoring system to identify messages which look spammy, then adds headers to the message so they can be filtered by the user's mail reading software. This distribution includes the spamd/spamc components which create a server that considerably speeds processing of mail. --------------------------------------------------------------------- Update Information: An updated spamassassin package that fixes a denial of service bug when parsing malformed messages is now available. SpamAssassin provides a way to reduce unsolicited commercial email (SPAM) from incoming email. A denial of service bug has been found in SpamAssassin versions below 2.64. A malicious attacker could construct a message in such a way that would cause spamassassin to stop responding, potentially preventing the delivery or filtering of email. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0796 to this issue. Users of SpamAssassin should update to these updated packages which contain an updated version and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs fc2: * Fri May 06 2005 Marc Deslauriers 2.64-2.1.legacy - Updated to 2.64 to fix CAN-2004-0796 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc2: 6b7fbf447dce761c6dc6c85df6cc336cb31a939a fedora/2/updates-testing/i386/spamassassin-2.64-2.1.legacy.i386.rpm 8808655655b574f905a0308f0a0eca0c5e7d09c8 fedora/2/updates-testing/SRPMS/spamassassin-2.64-2.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: 251 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Jun 4 19:27:13 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Jun 2005 15:27:13 -0400 Subject: Fedora Legacy Test Update Notification: openssl Message-ID: <42A20091.80200@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152841 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152841 2005-06-04 --------------------------------------------------------------------- Name : openssl Versions : rh73: openssl-0.9.6b-39.7.legacy Versions : rh9: openssl-0.9.7a-20.4.legacy Versions : fc1: openssl-0.9.7a-33.11.legacy Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. --------------------------------------------------------------------- Update Information: Updated OpenSSL packages that fix security issues are now available. OpenSSL is a toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. A flaw was found in the way the der_chop script creates temporary files. It is possible that a malicious local user could cause der_chop to overwrite files (CAN-2004-0975). Users are advised to update to these erratum packages which contain a patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Tue May 31 2005 Marc Deslauriers 0.9.6b-39.7.legacy - Added missing zlib-devel BuildPrereq * Fri Mar 11 2005 Marc Deslauriers 0.9.6b-38.7.legacy - Fixed the CAN-2004-0975 patch * Sat Mar 05 2005 Marc Deslauriers 0.9.6b-37.7.legacy - add security fix for CAN-2004-0975 rh9: * Fri Mar 11 2005 Marc Deslauriers 0.9.7a-20.4.legacy - Fixed the CAN-2004-0975 patch * Sat Mar 05 2005 Marc Deslauriers 0.9.7a-20.3.legacy - Added patch for CAN-2004-0975 fc1: * Sat Mar 05 2005 Marc Deslauriers 0.9.7a-33.11.legacy - Added security patch for CAN-2004-0975 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 23e338ea168362be064b0fc5818ca75fb0ff478d redhat/7.3/updates-testing/i386/openssl-0.9.6b-39.7.legacy.i386.rpm 909d19843a102c8db726f4ce19bec343e468c205 redhat/7.3/updates-testing/i386/openssl-0.9.6b-39.7.legacy.i686.rpm e5d2ded644fc5e6efd947ce85c6889e8f3d85cf9 redhat/7.3/updates-testing/i386/openssl-devel-0.9.6b-39.7.legacy.i386.rpm 94f5abf2da579c8546b26a579d125a402c517cd4 redhat/7.3/updates-testing/i386/openssl-perl-0.9.6b-39.7.legacy.i386.rpm 22e61ba5e83c0f2ffb1cf01c2f440e0f5778aeb5 redhat/7.3/updates-testing/SRPMS/openssl-0.9.6b-39.7.legacy.src.rpm rh9: fc4ccd852dbdb32d35feda73d57dfec9695bb124 redhat/9/updates-testing/i386/openssl-0.9.7a-20.4.legacy.i386.rpm 53d60e01f25892efcc5da5281110259f15560f95 redhat/9/updates-testing/i386/openssl-0.9.7a-20.4.legacy.i686.rpm 6044af703d7b8915a0ff64cd57862c09f202884b redhat/9/updates-testing/i386/openssl-devel-0.9.7a-20.4.legacy.i386.rpm 366b375b6e77103d41e2b3b1fbdf2e4fd11ff31c redhat/9/updates-testing/i386/openssl-perl-0.9.7a-20.4.legacy.i386.rpm 55334c3b4a44b6743d86d7a5e40ec2ac853cfca9 redhat/9/updates-testing/SRPMS/openssl-0.9.7a-20.4.legacy.src.rpm fc1: 76fa768ce6ead9d3a2fe5a4bafa7c78c7d73049c fedora/1/updates-testing/i386/openssl-0.9.7a-33.11.legacy.i386.rpm b0eadfbcbfe4b8306eff0d0d9fe1abc56e77633b fedora/1/updates-testing/i386/openssl-0.9.7a-33.11.legacy.i686.rpm 7b24ed7cdbd8c55dbe0f7c9234314383c1cb90ca fedora/1/updates-testing/i386/openssl-devel-0.9.7a-33.11.legacy.i386.rpm 196577ad1b00b1285a41c30d8e42cf2c22d4063a fedora/1/updates-testing/i386/openssl-perl-0.9.7a-33.11.legacy.i386.rpm adfbc1d2c8753ae170cc9badee8ed56f5f4cf5cb fedora/1/updates-testing/SRPMS/openssl-0.9.7a-33.11.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: 251 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Jun 4 19:27:47 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Jun 2005 15:27:47 -0400 Subject: Updated: Fedora Legacy Test Update Notification: gaim Message-ID: <42A200B3.7020608@videotron.ca> This test update was updated to fix additional issues and add Fedora Core 2 packages. --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-158543 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158543 2005-06-04 --------------------------------------------------------------------- Name : gaim 7.3 Version : gaim-1.3.0-0.73.1.legacy 9 Version : gaim-1.3.0-0.90.1.legacy fc1 Version : gaim-1.3.0-1.fc1.legacy fc2 Version : gaim-1.3.0-1.fc2.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. 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.3.0 and is not vulnerable to these issues. --------------------------------------------------------------------- 7.3 changelog: * 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: * Mon May 23 2005 Marc Deslauriers 1:1.3.0-0.90.1.legacy - Rebuilt as Fedora Legacy rh9 security update - Added mozilla-nspr-devel and mozilla-nss BuildRequires - Reverted to rh9-style desktop file - Disabled PIE patch - Added fix for perl plugin fc1 changelog: * Mon May 23 2005 Marc Deslauriers 1:1.3.0-1.fc1.1.legacy - Rebuilt as Fedora Legacy FC1 security update fc2 changelog: * Mon May 23 2005 Marc Deslauriers 1:1.3.0-1.fc2.legacy - Rebuilt as Fedora Legacy update for FC2 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) 076d2a121549c48b680135dc0e9d73b9ced15b49 redhat/7.3/updates-testing/i386/gaim-1.3.0-0.73.1.legacy.i386.rpm a14a81c748d02f296314ac6f88596d417dba66e6 redhat/7.3/updates-testing/SRPMS/gaim-1.3.0-0.73.1.legacy.src.rpm ccc3631f257e56867bc2d618321e89d8681ae6c7 redhat/9/updates-testing/i386/gaim-1.3.0-0.90.1.legacy.i386.rpm 9bc9aa7e15616e6f21fa569b65f203a7a703c89b redhat/9/updates-testing/SRPMS/gaim-1.3.0-0.90.1.legacy.src.rpm 5df0ef03698e8f9e8bc2b5e5135fc32d472d750b fedora/1/updates-testing/i386/gaim-1.3.0-1.fc1.legacy.i386.rpm 4bbe74ce4caf178a9b04dfe7d8616af1daa83ac2 fedora/1/updates-testing/SRPMS/gaim-1.3.0-1.fc1.legacy.src.rpm 1aa7d01186700303098f49fe3348a2833b98e4b5 fedora/2/updates-testing/i386/gaim-1.3.0-1.fc2.legacy.i386.rpm 5c6d271e3c8c4eb0b42ade249ddaf9291d94a700 fedora/2/updates-testing/SRPMS/gaim-1.3.0-1.fc2.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: 251 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Jun 4 19:28:10 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Jun 2005 15:28:10 -0400 Subject: Fedora Legacy Test Update Notification: mozilla Message-ID: <42A200CA.806@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-158149 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158149 2005-06-04 --------------------------------------------------------------------- Name : mozilla Versions : rh7.3: mozilla-1.7.8-0.73.1.legacy Versions : rh9: mozilla-1.7.8-0.90.1.legacy Versions : fc1: mozilla-1.7.8-1.1.1.legacy Versions : fc2: mozilla-1.7.8-1.2.1.legacy Summary : A Web browser. Description : Mozilla is an open-source Web browser, designed for standards compliance, performance, and portability. --------------------------------------------------------------------- Update Information: Updated mozilla packages that fix various security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Several bugs were found in the way Mozilla executes javascript code. Javascript executed from a web page should run with a restricted access level, preventing dangerous actions. It is possible that a malicious web page could execute javascript code with elevated privileges, allowing access to protected data and functions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-1476, CAN-2005-1477, CAN-2005-1531, and CAN-2005-1532 to these issues. Users of Mozilla are advised to upgrade to this updated package, which contains Mozilla version 1.7.8 to correct these issues. --------------------------------------------------------------------- Changelogs rh7.3: * Mon May 23 2005 Marc Deslauriers 37:1.7.8-0.73.1.legacy - Rebuild as a Fedora Legacy update for Red Hat Linux 7.3 - Added missing freetype-devel BuildRequires - Fix missing icons in desktop files rh9: * Mon May 23 2005 Marc Deslauriers 37:1.7.8-0.90.1.legacy - Rebuilt as a Fedora Legacy update for Red Hat Linux 9 - Disabled desktop-file-utils - Disabled gtk2 - Added missing BuildRequires - Force build with gcc296 to remain compatible with plugins - Added xft font preferences and patch back in - Removed mozilla-compose.desktop fc1: * Mon May 23 2005 Marc Deslauriers 37:1.7.8-1.1.1.legacy - Rebuilt as Fedora Legacy update for Fedora Core 1 - Changed useragent vendor tag to Fedora - Removed Network category from mozilla.desktop - Added missing gnome-vfs2-devel and desktop-file-utils to BuildRequires fc2: * Mon May 23 2005 Marc Deslauriers 37:1.7.8-1.2.1.legacy - Rebuilt as a Fedora Legacy update to Fedora Core 2 - Reverted to desktop-file-utils 0.4 - Removed desktop-update-database - Disabled pango support - Added missing gnome-vfs2-devel, desktop-file-utils and krb5-devel BuildPrereq --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 53bfba163e4771b025d445b797325241c2f64cc5 redhat/7.3/updates-testing/i386/mozilla-1.7.8-0.73.1.legacy.i386.rpm 1adb3bd0f07970e08a68ad7885455291c715057e redhat/7.3/updates-testing/i386/mozilla-chat-1.7.8-0.73.1.legacy.i386.rpm 00b6c60d5595977f421566918da4c61aef8fe575 redhat/7.3/updates-testing/i386/mozilla-devel-1.7.8-0.73.1.legacy.i386.rpm 8a41e399f0db66efd9ab716d0a6a8ff6d5d62566 redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.8-0.73.1.legacy.i386.rpm f7d191586e65e40bff5a68efda356628dbfb5ecf redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.8-0.73.1.legacy.i386.rpm f3659f9a5c7f90abbc6e8ed95867103773f7a032 redhat/7.3/updates-testing/i386/mozilla-mail-1.7.8-0.73.1.legacy.i386.rpm b3891f513e1ac4473811b3fb9d6d6cf10fc793eb redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.8-0.73.1.legacy.i386.rpm 4ec6616b781f1f94ad807525327084435b5be477 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.8-0.73.1.legacy.i386.rpm 5af05b2836009b2081c3ac035ab82661a056705a redhat/7.3/updates-testing/i386/mozilla-nss-1.7.8-0.73.1.legacy.i386.rpm 3b41861da189e369bafdca92e22a7ba5cd403d3b redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.8-0.73.1.legacy.i386.rpm 3c0dec35034ceec86ccbe5976d7bcaa937372c99 redhat/7.3/updates-testing/SRPMS/mozilla-1.7.8-0.73.1.legacy.src.rpm f1d71f876d9a14884a2c78e6f52b0d85eda58420 redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.3.legacy.i386.rpm c7c74a1d0c0e82963ae297b299870c0266a6fd29 redhat/7.3/updates-testing/SRPMS/galeon-1.2.14-0.73.3.legacy.src.rpm rh9: 19f88b4dc5a45a4252dafe81ecefa575caafac72 redhat/9/updates-testing/i386/mozilla-1.7.8-0.90.1.legacy.i386.rpm 575d3b0ede7f8b9f44b2e5490ac35df7a2b6dbf4 redhat/9/updates-testing/i386/mozilla-chat-1.7.8-0.90.1.legacy.i386.rpm 378b0f97133657932c4cd3d37bc7253382ff4a36 redhat/9/updates-testing/i386/mozilla-devel-1.7.8-0.90.1.legacy.i386.rpm 4d95a0a8aa165cf936ed8241429a6ab79eba2503 redhat/9/updates-testing/i386/mozilla-dom-inspector-1.7.8-0.90.1.legacy.i386.rpm 65c8f757d727d0f9574a453487075150062d67f4 redhat/9/updates-testing/i386/mozilla-js-debugger-1.7.8-0.90.1.legacy.i386.rpm 7293d848df84337a70c2a9a1b1d91761e74ec0a9 redhat/9/updates-testing/i386/mozilla-mail-1.7.8-0.90.1.legacy.i386.rpm 1b82a4b2c9b949d81ee15847e8d60175a164012e redhat/9/updates-testing/i386/mozilla-nspr-1.7.8-0.90.1.legacy.i386.rpm 743753ebcfa235ab55d2973bf1f27f29edd58740 redhat/9/updates-testing/i386/mozilla-nspr-devel-1.7.8-0.90.1.legacy.i386.rpm 581ba496932635198b89e90b73bdbc2e3960a535 redhat/9/updates-testing/i386/mozilla-nss-1.7.8-0.90.1.legacy.i386.rpm 3a1564245d1fb4f7fec69dc8d804630ae0289846 redhat/9/updates-testing/i386/mozilla-nss-devel-1.7.8-0.90.1.legacy.i386.rpm d2ec94bec7f180a30689df5ef71dfce501803514 redhat/9/updates-testing/SRPMS/mozilla-1.7.8-0.90.1.legacy.src.rpm a9d0d67e3e1decf95935fb586e2c20169342a6d9 redhat/9/updates-testing/i386/galeon-1.2.14-0.90.3.legacy.i386.rpm 05aeb7cbb8752b2329a8d8fdda5c8a79fcd6546f redhat/9/updates-testing/SRPMS/galeon-1.2.14-0.90.3.legacy.src.rpm fc1: f2ccc30d5dee06f1154ba54adac985750e530adf fedora/1/updates-testing/i386/mozilla-1.7.8-1.1.1.legacy.i386.rpm 0048085efd174b33a9eeed00e48aa687aaee7f99 fedora/1/updates-testing/i386/mozilla-chat-1.7.8-1.1.1.legacy.i386.rpm d0d0cc511d4d2ffc84073927e34b38345f6abab9 fedora/1/updates-testing/i386/mozilla-devel-1.7.8-1.1.1.legacy.i386.rpm 1b886dbcef418cc55ca974ca3d80850bffe30052 fedora/1/updates-testing/i386/mozilla-dom-inspector-1.7.8-1.1.1.legacy.i386.rpm 177808f5cfe0aa7bd3aa881b3667f8c19c2e0269 fedora/1/updates-testing/i386/mozilla-js-debugger-1.7.8-1.1.1.legacy.i386.rpm 1655745d989c7d66b8f99e0864be7860a59e92fe fedora/1/updates-testing/i386/mozilla-mail-1.7.8-1.1.1.legacy.i386.rpm 07b0a00586ef0daac144ef99b1af769bb93e9b8c fedora/1/updates-testing/i386/mozilla-nspr-1.7.8-1.1.1.legacy.i386.rpm 1d613a99f63808f47bc7187012c58211e455ba8d fedora/1/updates-testing/i386/mozilla-nspr-devel-1.7.8-1.1.1.legacy.i386.rpm 39ff2c9023453a8288010d4c51bfaa08575989f4 fedora/1/updates-testing/i386/mozilla-nss-1.7.8-1.1.1.legacy.i386.rpm 4f48517697ddd63df94272a19ea381b591dad2f5 fedora/1/updates-testing/i386/mozilla-nss-devel-1.7.8-1.1.1.legacy.i386.rpm bcc8e1337881d00774d61109b795ff26dbaef05f fedora/1/updates-testing/SRPMS/mozilla-1.7.8-1.1.1.legacy.src.rpm 54323a70f1a98fed5e2cfe1f110ebe36e6b369f0 fedora/1/updates-testing/i386/epiphany-1.0.8-1.fc1.3.legacy.i386.rpm 5fdcb7b6eb361740d92ee428c13896bf279d4d42 fedora/1/updates-testing/SRPMS/epiphany-1.0.8-1.fc1.3.legacy.src.rpm fc2: 4c9998181a6aec013277b6033fb76d995ca744fa fedora/2/updates-testing/i386/mozilla-1.7.8-1.2.1.legacy.i386.rpm f63261e90613cc48ab9890481b9ba79dbe57e32f fedora/2/updates-testing/i386/mozilla-chat-1.7.8-1.2.1.legacy.i386.rpm ac6deaaa97b6a07a751c85002e119158a65ae6bc fedora/2/updates-testing/i386/mozilla-devel-1.7.8-1.2.1.legacy.i386.rpm 31391d41a8e4580761ee6d8f769f98ac60695e6a fedora/2/updates-testing/i386/mozilla-dom-inspector-1.7.8-1.2.1.legacy.i386.rpm dbc5b635361a4c81a16f40e24aa2b5a431bd8cb9 fedora/2/updates-testing/i386/mozilla-js-debugger-1.7.8-1.2.1.legacy.i386.rpm eb40fa6b6ea9a346a92940341b436a10db1447ab fedora/2/updates-testing/i386/mozilla-mail-1.7.8-1.2.1.legacy.i386.rpm 6d2ef4fcf9f89756e21a2446584e8e64a3ebc1f2 fedora/2/updates-testing/i386/mozilla-nspr-1.7.8-1.2.1.legacy.i386.rpm c1096bad603bf508c86e1dbef2a7def8dd5bc457 fedora/2/updates-testing/i386/mozilla-nspr-devel-1.7.8-1.2.1.legacy.i386.rpm 8f576d7491bf3f342ca561f4fd0d7958204f90f1 fedora/2/updates-testing/i386/mozilla-nss-1.7.8-1.2.1.legacy.i386.rpm 852ca275701aca0661fd10135432438f28f3dba4 fedora/2/updates-testing/i386/mozilla-nss-devel-1.7.8-1.2.1.legacy.i386.rpm 4325b3cc4308aa7a0f38da1916b1660762470984 fedora/2/updates-testing/SRPMS/mozilla-1.7.8-1.2.1.legacy.src.rpm 271bcd5329cd2de25c7e306bad38b7fb3c06e0d3 fedora/2/updates-testing/i386/epiphany-1.2.10-0.2.4.legacy.i386.rpm 782fa5b86e1c01c6913c8c17ccba29a807de8443 fedora/2/updates-testing/SRPMS/epiphany-1.2.10-0.2.4.legacy.src.rpm d90b234dbaeca4b4ade39c5b9dd56cefd6891e90 fedora/2/updates-testing/i386/devhelp-0.9.1-0.2.7.legacy.i386.rpm 76064f34923bafe79ab89a47e2a95d944fdfda51 fedora/2/updates-testing/i386/devhelp-devel-0.9.1-0.2.7.legacy.i386.rpm 11d23437935e95917a803662e6475dc4ea8037ff fedora/2/updates-testing/SRPMS/devhelp-0.9.1-0.2.7.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: 251 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Jun 4 19:29:08 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 04 Jun 2005 15:29:08 -0400 Subject: [FLSA-2005:152532] Updated kernel packages fix security issues Message-ID: <42A20104.2030801@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel packages fix security issues Advisory ID: FLSA:152532 Issue date: 2005-06-04 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2004-1058 CAN-2004-1333 CAN-2005-0384 CAN-2005-0400 CAN-2005-0449 CAN-2005-0504 CAN-2005-0749 CAN-2005-0750 CAN-2005-0815 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix several security issues are now available. The Linux kernel handles the basic functions of the operating system. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: This update includes fixes for several security issues: A race condition was discovered. Local users could use this flaw to read the environment variables of another process that is still spawning via /proc/.../cmdline. (CAN-2004-1058) An integer overflow was discovered in the vc_resize function. A local user could cause a denial of service (kernel crash) via a short new screen value, which leads to a buffer overflow. (CAN-2004-1333) A flaw was discovered in the Linux PPP driver. On systems allowing remote users to connect to a server using ppp, a remote client could cause a denial of service (system crash). (CAN-2005-0384) A flaw was discovered in ext2 filesystem support. When a new directory is created, the ext2 block written to disk is not initialized, leading to an information leak. (CAN-2005-0400) A flaw in fragment queuing was discovered affecting the netfilter subsystem. On systems configured to filter or process network packets (for example those configured to do firewalling), a remote attacker could send a carefully crafted set of fragmented packets to a machine and cause a denial of service (system crash). In order to sucessfully exploit this flaw, the attacker would need to know (or guess) some aspects of the firewall ruleset in place on the target system to be able to craft the right fragmented packets. (CAN-2005-0449) The moxa char driver was missing a CAP_SYS_RAWIO check which could allow a local user the ability to do things like replace the firmware. (CAN-2005-0504) A flaw when freeing a pointer in load_elf_library was discovered. A local user could potentially use this flaw to cause a denial of service (system crash). (CAN-2005-0749) A flaw was discovered in the bluetooth driver system. On system where the bluetooth modules are loaded, a local user could use this flaw to gain elevated (root) privileges. (CAN-2005-0750) Michal Zalewski discovered some flaws in the iso9660 filesystem. These flaws could allow a malicious iso filesystem to cause a DoS or potentially execute arbitrary code if mounted/examined. (CAN-2005-0815) All users are advised to upgrade their kernels to the packages associated with their machine architectures and configurations as listed in this erratum. Please note that the fix for CAN-2005-0449 required changing the external symbol linkages (kernel module ABI) for the ip_defrag() and ip_ct_gather_frags() functions. Any third-party module using either of these would also need to be fixed. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To install kernel packages manually, use "rpm -ivh " and modify system settings to boot the kernel you have installed. To do this, edit /boot/grub/grub.conf and change the default entry to "default=0" (or, if you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and run lilo) 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. Note that this may not automatically pull the new kernel in if you have configured apt/yum to ignore kernels. If so, follow the manual instructions above. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152532 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/kernel-2.4.20-43.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-BOOT-2.4.20-43.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-doc-2.4.20-43.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-source-2.4.20-43.7.legacy.i386.rpm i586: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i586.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.i586.rpm i686: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-bigmem-2.4.20-43.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.i686.rpm athlon: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.athlon.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/kernel-2.4.20-43.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-BOOT-2.4.20-43.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-doc-2.4.20-43.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-source-2.4.20-43.9.legacy.i386.rpm i586: http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i586.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.i586.rpm i686: http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-bigmem-2.4.20-43.9.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.i686.rpm athlon: http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.athlon.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.5.legacy.nptl.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.5.legacy.nptl.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.5.legacy.nptl.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2199.5.legacy.nptl.i386.rpm i586: http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.i586.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.i586.rpm i686: http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.i686.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.i686.rpm athlon: http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.athlon.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.athlon.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 33794472a5fa20539f29eb7cc4a1d2e6ce769b06 redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.athlon.rpm 230a9443c30eb7d9733c16568a4d937ea2276bd4 redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i386.rpm 17d0026c8cf717ed74be70b25b13da6063ec7e30 redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i586.rpm 5dc8f0385fd068bd2274337989faebc7c6ec1726 redhat/7.3/updates/i386/kernel-2.4.20-43.7.legacy.i686.rpm f286d3c08cf28c9c4a20c950d2eb795c5b5737ff redhat/7.3/updates/i386/kernel-bigmem-2.4.20-43.7.legacy.i686.rpm ddb00a518b2426230fe5e1da5e115691e39f09c8 redhat/7.3/updates/i386/kernel-BOOT-2.4.20-43.7.legacy.i386.rpm 904f2b51aaed8aa96583b7e2bd40365b75cb6faa redhat/7.3/updates/i386/kernel-doc-2.4.20-43.7.legacy.i386.rpm b332b272d0a4854af3131693708c05f39797e9af redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.athlon.rpm 933b9cb0ca14334c320c7458f61a700a8e002abd redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.i586.rpm 95339a7d9b57381d6a967d7fa0c70675b1c2e34a redhat/7.3/updates/i386/kernel-smp-2.4.20-43.7.legacy.i686.rpm c054c08870c77ce47030511ebfc35566fcd216f5 redhat/7.3/updates/i386/kernel-source-2.4.20-43.7.legacy.i386.rpm c7b8495a1c84cdcf22bf99748e1346614777cdba redhat/7.3/updates/SRPMS/kernel-2.4.20-43.7.legacy.src.rpm 06664b11750a20c552ef4f9f391976429335516e redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.athlon.rpm 523c7336e869cc3aac6356b838eb3e7458f7b471 redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i386.rpm 66a5186361dcdb4cb4c8c1dccb63e56d11a14f58 redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i586.rpm a138ce79569e85745c9cc2e352ec03c32d048de5 redhat/9/updates/i386/kernel-2.4.20-43.9.legacy.i686.rpm e595403bc87b08c1dd4090de032bf7d9b4400a67 redhat/9/updates/i386/kernel-bigmem-2.4.20-43.9.legacy.i686.rpm ec99c85958ab259128855cc1b0be74c83e6e3f0e redhat/9/updates/i386/kernel-BOOT-2.4.20-43.9.legacy.i386.rpm 536fa79aa0a5f02e9f8b54c5c88e5a429dbdb114 redhat/9/updates/i386/kernel-doc-2.4.20-43.9.legacy.i386.rpm b16cc40913f423d5c8adbcf755c07621d42b1df0 redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.athlon.rpm 8db2f89803e02ee40af386e192813c3441d9ef12 redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.i586.rpm 9665eda39738126699e2e999c5563e47826270c8 redhat/9/updates/i386/kernel-smp-2.4.20-43.9.legacy.i686.rpm 6a61f8971a1ba0f51399956aed24789065ece2b4 redhat/9/updates/i386/kernel-source-2.4.20-43.9.legacy.i386.rpm 35d0fc7714b2c0274b6af35996c26335ea8d3555 redhat/9/updates/SRPMS/kernel-2.4.20-43.9.legacy.src.rpm e1dd5d1ee6ba69871dd06ce679734eadf5c4c9ed fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.athlon.rpm 23a4afe07cd72f23b429730c32f88f5fe92e8f6f fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.i586.rpm 5da916582b12a4625e54eb0cfb3d200dbeb5360b fedora/1/updates/i386/kernel-2.4.22-1.2199.5.legacy.nptl.i686.rpm fbdf463056180fd41abe4d8afc165d187163390d fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.5.legacy.nptl.i386.rpm 03298f9d3057661b2912fefa73cde94c42d2377e fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.5.legacy.nptl.i386.rpm 2419d19c66420c55a50ca82d0ef41aaab7992136 fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.athlon.rpm 8dcd88461c7922a07b7c1bad054b480a997828ea fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.i586.rpm c95bddfc477c11c46d562c3bd28f407ebdcd8ae3 fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.5.legacy.nptl.i686.rpm 0fe3402917235049865cedc80ad5eb72c1984df2 fedora/1/updates/i386/kernel-source-2.4.22-1.2199.5.legacy.nptl.i386.rpm cfb0d7b297116b99ef08a30d7d9fef0c9e24a490 fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.5.legacy.nptl.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-1058 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1333 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0384 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0400 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0449 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0504 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0749 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0750 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0815 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: 251 bytes Desc: OpenPGP digital signature URL: From rostetter at mail.utexas.edu Sat Jun 4 21:40:57 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 4 Jun 2005 16:40:57 -0500 Subject: changes are needed, we need keep moving In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> Message-ID: <1117921257.652e61ba92aef@mail.ph.utexas.edu> Quoting Pekka Savola : > On Fri, 3 Jun 2005, Eric Rostetter wrote: > > Seriously, if we can't get 2 votes for a package, then there is a real > > problem going on. > > It's pretty clear we've had a real problem going on for a long time. Well, the urgency hasn't been made apparent enough. I'm serious here. I'm involved in the project, and I didn't know there was as big a problem as we have. So how would people not involved know? > (A smaller, specific instance of lack of testing seems to be that > sufficiently many people aren't interested in FC1/FC2 and lack of > verifies for those stall the updates for other distros.) That is, IMHO, a separate issue. Lack of votes for any OS is the problem, not lack of votes for a particular OS. We could work around the lack of votes for a particular OS, but we can't work around a total lack of votes. > > That isn't the point of the project though. It would be much better to > > get two votes. Heck, if you do one, and I do one, we're done. The only > > time that would be a problem is the once or twice a year we go on vacation. > > That doesn't seem to have happened all that much, however. Then let's make it happen, okay? > >> That said, I could also live with two verify votes (for any version) > >> plus the similar timeout, but I think timeliness is more important. > > > > I can agree to 2 votes plus timeout. If we give 2 weeks for the votes, > > and 2 additional weeks for the timeout, then everything is done in one > > month. Sounds reasonable to me. > > 4 weeks is a long time for more important security bugs. 2 weeks is > maximum after the stuff has been pushed to updates-testing (which > typically has also taken quite a while). I think if it is a important security bug, it will not need the timeout as much. I don't want to rush the less important updates though. Yes, there's a judgement call as to what is important and what isn't. But let's try the longer timeout and see how it works. If it doesn't work, we can go back and shorten it. > >> FYI, one verify vote is sufficient to VERIFY a distro version right > >> now, so this is why I said one measly verify vote. > > > > I wasn't aware of this; last I knew we still needed two votes. How/when > > did this change? > > A long time ago, maybe a bit over 6 months or so ago. Strange that as the web site, FAQ, etc. maintainer I'm so out of touch with reality. > > But we can try better/harder to get more votes (including say, getting me > > to test/vote more, and getting those who run updates-testing but don't > > vote to vote). > > I encourage you and others to do that. However, IMHO, we've stalled > already long enough with that and folks (yourself included) have > started (or already done) moved away from some releases. Yeah, but I'm not moving away fast. I've still got almost all legacy systems. I've over 100 machines, and only 2 are now non-legacy. Sure by the fall I hope to make that at least half non-legacy. But realistically I'll be legacy for a while, and even if all the machines I run directly are non-legacy I'll probably have to help support others here who still have legacy machines. So, let's not kill the project yet... Besides, the FC project basically guarantees new people will be dropping by, as long as we can provide the service we were formed to provide. > I suggest we make some process changes now (I don't specify which, but > the impact has to be significant), AND you (and others) try to get > more people to do QA as well. Yes, I'm not against that. But I'd like to at least state my input and my reasons behind process changes. What we really have in this project is a communication problem. Review the lists, as well as this thread, and you'll see everyone involved in the project is having communications problems, even at the top level (Warren and Jesse). That would be were I start to change the process. We won't suceed if we can't communicate effectively, and keep people informed about what is going on, including problems. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From dsccable at comcast.net Sun Jun 5 04:29:08 2005 From: dsccable at comcast.net (David Curry) Date: Sun, 05 Jun 2005 00:29:08 -0400 Subject: Fedora Legacy Test Update Notification: mozilla In-Reply-To: <42A200CA.806@videotron.ca> References: <42A200CA.806@videotron.ca> Message-ID: <42A27F94.2020502@comcast.net> Marc Deslauriers wrote: >--------------------------------------------------------------------- >Fedora Legacy Test Update Notification >FEDORALEGACY-2005-158149 >Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158149 >2005-06-04 >--------------------------------------------------------------------- > >Name : mozilla >Versions : rh7.3: mozilla-1.7.8-0.73.1.legacy >Versions : rh9: mozilla-1.7.8-0.90.1.legacy >Versions : fc1: mozilla-1.7.8-1.1.1.legacy >Versions : fc2: mozilla-1.7.8-1.2.1.legacy >Summary : A Web browser. >Description : >Mozilla is an open-source Web browser, designed for standards >compliance, performance, and portability. > > FWIW, I have tried to download and install the FC2 mozilla and gaim updates for QA testing but have encountered a problem with the gpg signatures. The signatures available at http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY had been downloaded and installed previously for earlier updates. After the Mozilla and Gaim update packages failed the gpg check, the fedoralegacy gpg keys were re-installed and a further attempt to install the Mozilla and Gaim updates was made. Other than forgoing the gpg check, I am open to suggestions/recommendations on how I might proceed with QA testings of the proposed update packages. From shiva at sewingwitch.com Sun Jun 5 08:52:19 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 05 Jun 2005 01:52:19 -0700 Subject: Fedora Legacy Test Update Notification: spamassassin In-Reply-To: <42A20078.6010609@videotron.ca> References: <42A20078.6010609@videotron.ca> Message-ID: <5E5953124EF603210CBDED41@[10.0.0.14]> --On Saturday, June 04, 2005 3:26 PM -0400 Marc Deslauriers wrote: > Versions : fc2: spamassassin-2.64-2.1.legacy I'll forward this to the SA mailing list. FWIW, SA 3.0.3 works great on FC2. I don't recall if there were any special upgrade issues going to 3.x (you might need to back up and restore your Bayes databases, for instance), but I'd strongly recommend any mail server operators staying up to date with upstream to get the latest functionality. For instance, the SURBL URL-based blacklisting is invaluable. ... ah, just found the wiki entry on how to upgrade: This includes a link to the official upgrade file in the 3.0 distro. SA 3.1 is about to go prerelease. Follow SA's -devel mailing list if you're interested in that development. From marcdeslauriers at videotron.ca Sun Jun 5 13:25:03 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 05 Jun 2005 09:25:03 -0400 Subject: Fedora Legacy Test Update Notification: mozilla In-Reply-To: <42A27F94.2020502@comcast.net> References: <42A200CA.806@videotron.ca> <42A27F94.2020502@comcast.net> Message-ID: <1117977903.4858.5.camel@mdlinux> On Sun, 2005-06-05 at 00:29 -0400, David Curry wrote: > I have tried to download and install the FC2 mozilla and gaim updates > for QA testing but have encountered a problem with the gpg signatures. > The signatures available at > http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY had been downloaded > and installed previously for earlier updates. After the Mozilla and > Gaim update packages failed the gpg check, the fedoralegacy gpg keys > were re-installed and a further attempt to install the Mozilla and Gaim > updates was made. > > Other than forgoing the gpg check, I am open to > suggestions/recommendations on how I might proceed with QA testings of > the proposed update packages. You were probably downloading from a mirror that had not completed sync yet, or had corrupted packages. They are properly signed with the Fedora Legacy key. Try running a "yum clean all" and trying again. 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 jung at one.ekof.bg.ac.yu Sun Jun 5 14:11:46 2005 From: jung at one.ekof.bg.ac.yu (Igor =?iso-8859-2?Q?Nestorovi=E6?=) Date: Sun, 05 Jun 2005 16:11:46 +0200 Subject: changes are needed, we need keep moving In-Reply-To: <1117921257.652e61ba92aef@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> <1117921257.652e61ba92aef@mail.ph.utexas.edu> Message-ID: <1117980706.4377.24.camel@lara> If the present tactics show flaws, maybe we should take a look at how other projects, like the i18n, are organized. What about creating teams for each release? Such a team may be consisted of a team leader and QA crew. QA crew may vary in number, depending on avaliable and willing men. Also, QA crew may split among themselves packages in types. For instance, those in a position of testing network packages more seriously (in server enviroments, say) are likely to to take on those packages, and those using Legacy releases as desktops (home users, for instance) may take on applications such as OpenOffice.org, mozilla, gaim etc. Database packages should be left for those that actually use them, they are the most competent to test them in an actual production. In occasions when a crew member is unable to do his share, the team leader can coordinate and delegate to some other avaliable member, who may already finished his regular task. Also, I think that constant and regular reminders about the Legacy policy are needed, both here, on the web site and elsewhere that seems fit, so people joining the project can be educated, and maybe wish to contribute. This is just a working idea. I thought, the problem is real, and any proposal to a solution, however distant, may only contribute to its solution. It cannot hurt, anyway. -- Igor Nestorovi? Home Page: http://jung.ekof.bg.ac.yu ICQ UIN: 31079000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ??? ?? ??? ?????? ?? ?????????? ???????? URL: From dsccable at comcast.net Sun Jun 5 14:44:19 2005 From: dsccable at comcast.net (David Curry) Date: Sun, 05 Jun 2005 10:44:19 -0400 Subject: Fedora Legacy Test Update Notification: mozilla In-Reply-To: <1117977903.4858.5.camel@mdlinux> References: <42A200CA.806@videotron.ca> <42A27F94.2020502@comcast.net> <1117977903.4858.5.camel@mdlinux> Message-ID: <42A30FC3.2010801@comcast.net> Marc Deslauriers wrote: >On Sun, 2005-06-05 at 00:29 -0400, David Curry wrote: > > >>I have tried to download and install the FC2 mozilla and gaim updates >>for QA testing but have encountered a problem with the gpg signatures. >>The signatures available at >>http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY had been downloaded >>and installed previously for earlier updates. After the Mozilla and >>Gaim update packages failed the gpg check, the fedoralegacy gpg keys >>were re-installed and a further attempt to install the Mozilla and Gaim >>updates was made. >> >>Other than forgoing the gpg check, I am open to >>suggestions/recommendations on how I might proceed with QA testings of >>the proposed update packages. >> >> > >You were probably downloading from a mirror that had not completed sync >yet, or had corrupted packages. They are properly signed with the Fedora >Legacy key. Try running a "yum clean all" and trying again. > >Marc > A "yum clean all" was followed by another attempt to install the testing packages. Same result - a message reading, "Using ftp, http[s], or file for servers, Aborting - gpgcheck=1. My yum.conf reads > [main] > cachedir=/var/cache/yum > debuglevel=2 > logfile=/var/log/yum.log > pkgpolicy=newest > distroverpkg=redhat-release > tolerant=1 > exactarch=1 > retries=20 > > [base] > gpgcheck=1 > name=Fedora Core $releasever - $basearch - Base > baseurl=http://download.fedoralegacy.org/fedora/$releasever/os/$basearch > > [updates-released] > gpgcheck=1 > name=Fedora Core $releasever Updates > baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch > > #[updates-testing] > #name=Red Hat Linux $releasever - $basearch - Updates-testing > #baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates-testing/$basearch/ > > [dag] > name=Dag RPM Repository for Fedora Core > baseurl=http://apt.sw.be/fedora/$releasever/en/$basearch/dag > gpgcheck=1 enabled=1 From jkeating at j2solutions.net Sun Jun 5 15:35:03 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 05 Jun 2005 08:35:03 -0700 Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> Message-ID: <1117985703.2804.43.camel@yoda.loki.me> On Sat, 2005-06-04 at 21:56 +0300, Pekka Savola wrote: > Good to bring up bugs at fedoralegacy.org. > > It seems to me that we should, > 1) create a web-accessible mail archive of all of these mails, > and/or > 2) make that "mailing-list" subscribable. bugs@ is just an alias. I can add whoever wants to be on it to it. Just let me know. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jimpop at yahoo.com Sun Jun 5 22:27:44 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sun, 05 Jun 2005 18:27:44 -0400 Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: <1117985703.2804.43.camel@yoda.loki.me> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> <1117985703.2804.43.camel@yoda.loki.me> Message-ID: <1118010464.9620.1.camel@localhost> On Sun, 2005-06-05 at 08:35 -0700, Jesse Keating wrote: > On Sat, 2005-06-04 at 21:56 +0300, Pekka Savola wrote: > > Good to bring up bugs at fedoralegacy.org. > > > > It seems to me that we should, > > 1) create a web-accessible mail archive of all of these mails, > > and/or > > 2) make that "mailing-list" subscribable. > > bugs@ is just an alias. I can add whoever wants to be on it to it. How about aliasing bugs@ to a new Mailman list (fedora-legacy-bugs at redhat.com) so that A) people can subscribe to it and B) it can be archived and later searched. -Jim P. From jkeating at j2solutions.net Sun Jun 5 23:50:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 05 Jun 2005 16:50:51 -0700 Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: <1118010464.9620.1.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> <1117985703.2804.43.camel@yoda.loki.me> <1118010464.9620.1.camel@localhost> Message-ID: <1118015451.2797.9.camel@yoda.loki.me> On Sun, 2005-06-05 at 18:27 -0400, Jim Popovitch wrote: > How about aliasing bugs@ to a new Mailman list > (fedora-legacy-bugs at redhat.com) so that A) people can subscribe to it > and B) it can be archived and later searched. Hrm, not sure why? Bugzilla chatter is pretty lame, and I don't want discussion about bugs to happen on a different list than the main list or in the bug itself. History of a bug can be found on the bug itself, not in the email chatter from the bugzilla system. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jimpop at yahoo.com Mon Jun 6 03:17:14 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sun, 05 Jun 2005 23:17:14 -0400 Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: <1118015451.2797.9.camel@yoda.loki.me> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> <1117985703.2804.43.camel@yoda.loki.me> <1118010464.9620.1.camel@localhost> <1118015451.2797.9.camel@yoda.loki.me> Message-ID: <1118027834.9708.2.camel@localhost> On Sun, 2005-06-05 at 16:50 -0700, Jesse Keating wrote: > On Sun, 2005-06-05 at 18:27 -0400, Jim Popovitch wrote: > > How about aliasing bugs@ to a new Mailman list > > (fedora-legacy-bugs at redhat.com) so that A) people can subscribe to it > > and B) it can be archived and later searched. > > Hrm, not sure why? Bugzilla chatter is pretty lame, and I don't want > discussion about bugs to happen on a different list than the main list > or in the bug itself. Easily solved. Just set the Reply-To config field in Mailman to this list (fedora-legacy-list at redhat.com) and the bugs@ list will be read-only. > History of a bug can be found on the bug itself, not in the email > chatter from the bugzilla system. That's part of the problem (IMHO), people aren't even seeing the bugzilla system. Perhaps having some of the bugzilla Q&A coming back to this list will liven things up. -Jim P. From pekkas at netcore.fi Mon Jun 6 05:33:22 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 6 Jun 2005 08:33:22 +0300 (EEST) Subject: bugs@fedoralegacy.org [Re: priorization and rhl73 server-only help [Re: changes are needed, we need keep moving]] In-Reply-To: <1118015451.2797.9.camel@yoda.loki.me> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117740671.21522.10.camel@localhost> <1117764693.cd35718acc675@mail.ph.utexas.edu> <1117828538.73b02a7f7bf8d@mail.ph.utexas.edu> <1117985703.2804.43.camel@yoda.loki.me> <1118010464.9620.1.camel@localhost> <1118015451.2797.9.camel@yoda.loki.me> Message-ID: On Sun, 5 Jun 2005, Jesse Keating wrote: > On Sun, 2005-06-05 at 18:27 -0400, Jim Popovitch wrote: >> How about aliasing bugs@ to a new Mailman list >> (fedora-legacy-bugs at redhat.com) so that A) people can subscribe to it >> and B) it can be archived and later searched. > > Hrm, not sure why? Bugzilla chatter is pretty lame, and I don't want > discussion about bugs to happen on a different list than the main list > or in the bug itself. History of a bug can be found on the bug itself, > not in the email chatter from the bugzilla system. Those folks who are interested in seeing the latest developments in all the packages (but wouldn't want to add themselves as Cc: to all the bugs individually) could use this approach. In particular, the person(s) watching that the status whiteboard corresponds to the VERIFY/PUBLISH status should be able to see all the messages easily. -- 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 akopps at LS.Berkeley.EDU Mon Jun 6 18:15:28 2005 From: akopps at LS.Berkeley.EDU (Akop Pogosian) Date: Mon, 6 Jun 2005 11:15:28 -0700 Subject: mozilla-chat installation error Message-ID: <20050606181528.GA32549@ls.berkeley.edu> I get the following error when installing the latest mozilla-chat update for Fedora Core 1: Installing /var/spool/up2date/mozilla-chat-1.7.7-1.1.2.legacy.i386.rpm... /var/tmp/rpm-tmp.63155: line 1: update-desktop-database: command not found Which package provides the update-desktop-database command on FC1? -akop From pekkas at netcore.fi Mon Jun 6 20:14:16 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 6 Jun 2005 23:14:16 +0300 (EEST) Subject: changes are needed, we need keep moving In-Reply-To: <1117921257.652e61ba92aef@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117764093.f90b3b50e10cd@mail.ph.utexas.edu> <1117814080.2dc12a08f2ab6@mail.ph.utexas.edu> <1117921257.652e61ba92aef@mail.ph.utexas.edu> Message-ID: On Sat, 4 Jun 2005, Eric Rostetter wrote: > Quoting Pekka Savola : >> On Fri, 3 Jun 2005, Eric Rostetter wrote: >>> Seriously, if we can't get 2 votes for a package, then there is a real >>> problem going on. >> >> It's pretty clear we've had a real problem going on for a long time. > > Well, the urgency hasn't been made apparent enough. I'm serious here. > I'm involved in the project, and I didn't know there was as big a problem > as we have. So how would people not involved know? Umm, how plainly do you want to get it? At least I have tried to get people realize that these updates don't happen just by themselves, but if you refuse to believe it (or just prefer to wait for the others do the work), there isn't all that much to be done. A couple of examples, https://www.redhat.com/archives/fedora-legacy-list/2005-February/msg00168.html https://www.redhat.com/archives/fedora-legacy-list/2005-March/msg00142.html https://www.redhat.com/archives/fedora-legacy-list/2005-March/msg00254.html https://www.redhat.com/archives/fedora-legacy-list/2005-March/msg00269.html [close to end] https://www.redhat.com/archives/fedora-legacy-list/2005-May/msg00065.html How should folks (me and others) have said it instead to make it sufficently plain that there's a problem? >> (A smaller, specific instance of lack of testing seems to be that >> sufficiently many people aren't interested in FC1/FC2 and lack of >> verifies for those stall the updates for other distros.) > > That is, IMHO, a separate issue. Lack of votes for any OS is the > problem, not lack of votes for a particular OS. We could work around > the lack of votes for a particular OS, but we can't work around a > total lack of votes. I think obtaining two verify votes (for any OS version) would still be feasible at this point. For more than that (like 1 x OS or 2 x OS version) won't really cut it. >>> That isn't the point of the project though. It would be much better to >>> get two votes. Heck, if you do one, and I do one, we're done. The only >>> time that would be a problem is the once or twice a year we go on vacation. >> >> That doesn't seem to have happened all that much, however. > > Then let's make it happen, okay? I encourage you to to do it. However, I want the project to do something _now_, not in some unspecified time in the future (when/if willing testers have been recruited). Just going on as before is unacceptable at this point. >>>> That said, I could also live with two verify votes (for any version) >>>> plus the similar timeout, but I think timeliness is more important. >>> >>> I can agree to 2 votes plus timeout. If we give 2 weeks for the votes, >>> and 2 additional weeks for the timeout, then everything is done in one >>> month. Sounds reasonable to me. >> >> 4 weeks is a long time for more important security bugs. 2 weeks is >> maximum after the stuff has been pushed to updates-testing (which >> typically has also taken quite a while). > > I think if it is a important security bug, it will not need the timeout > as much. I don't want to rush the less important updates though. Yes, > there's a judgement call as to what is important and what isn't. But > let's try the longer timeout and see how it works. If it doesn't work, > we can go back and shorten it. There have been bugs like php, perl, kernel etc. which have been in progress for a very long time, and the problems have been significant. I suggest we make sufficiently big changes now (two weeks), and based on the results, adjust as appropriate. Remember, it's two weeks from the first VERIFY. Usually getting even that may take a while. If folks agree that it should be two VERIFY votes, I could accept (4 weeks from the first verify) || (2 weeks from the second verify), whichever is the soonest. >>>> FYI, one verify vote is sufficient to VERIFY a distro version right >>>> now, so this is why I said one measly verify vote. >>> >>> I wasn't aware of this; last I knew we still needed two votes. How/when >>> did this change? >> >> A long time ago, maybe a bit over 6 months or so ago. > > Strange that as the web site, FAQ, etc. maintainer I'm so out of touch > with reality. Well, the change was done in Wiki, so it didn't require action from you. Not looking at wiki or actively testing packages may not reveal such changes which are required to keep us moving. -- 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 pekkas at netcore.fi Mon Jun 6 20:17:47 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 6 Jun 2005 23:17:47 +0300 (EEST) Subject: "timeout" [Re: changes are needed, we need keep moving] In-Reply-To: <1117743857.17100.5.camel@mdlinux> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> Message-ID: Request for clarification: what _timeout_ are we talking about here? The earlier documentation had some timeouts for RHL72/RHL73 and RHL8/RHL9 but those no longer apply. Are we just talking about the time at maximum which it should take from getting a VERIFY vote to ensuring Status whiteboard has been updated? I don't think that could be called a timeout.. On Thu, 2 Jun 2005, Marc Deslauriers wrote: > On Thu, 2005-06-02 at 13:44 -0500, Eric Rostetter wrote: >> I'm not against the timeout, in fact there is supposed to be a timeout >> in the process, though I don't remember what it is. Perhaps we need to >> revisit the timeout issue, with the goal of putting someone in charge of >> watching the packages for timeout conditions. Right now, no one is AFAIK >> watching for such situations, so even if something had multiple verify votes >> and has stalled, no one notices and pushes it out. Seems like another >> essential job waiting to be filled. > > I agree to the timeout. Let's decide on this list what that timeout > should be and I'll watch for it. [in later mails the agreement seemed to be that 2 weeks was OK] -- 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 Mon Jun 6 20:40:49 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 06 Jun 2005 16:40:49 -0400 Subject: mozilla-chat installation error In-Reply-To: <20050606181528.GA32549@ls.berkeley.edu> References: <20050606181528.GA32549@ls.berkeley.edu> Message-ID: <1118090449.24957.5.camel@mdlinux> On Mon, 2005-06-06 at 11:15 -0700, Akop Pogosian wrote: > I get the following error when installing the latest mozilla-chat > update for Fedora Core 1: > > Installing /var/spool/up2date/mozilla-chat-1.7.7-1.1.2.legacy.i386.rpm... > /var/tmp/rpm-tmp.63155: line 1: update-desktop-database: command not found > > > Which package provides the update-desktop-database command on FC1? That is weird. Could you do a "rpm -q -i -p /var/spool/up2date/mozilla- chat-1.7.7-1.1.2.legacy.i386.rpm" please. 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 pekkas at netcore.fi Tue Jun 7 07:49:41 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Jun 2005 10:49:41 +0300 (EEST) Subject: Multiple Kerberos vulnerabilities (ID: 152773) In-Reply-To: <1117821133.9828.13.camel@localhost> References: <1117821133.9828.13.camel@localhost> Message-ID: On Fri, 3 Jun 2005, Jim Popovitch wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152773 > > I believe that this problem only affects those using Kerberos with a > KDC, and that it does NOT affect those that just happen to have > krb5-libs installed (due to RPM dependencies). At least CAN-2004-0642 seems to affect the library as well, so it could be an attack vector. I have not analyzed the code to see if this is true or not. This may also be possible for some of the other CAN's. By the way, #154276 (waiting for publish) includes superset of fixes, also bugfixing the two telnet client vulnerabilities. I suggest folks give it a PUBLISH and after it has been rebuilt for updates-testing, verify it instead. -- 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 akopps at LS.Berkeley.EDU Tue Jun 7 16:30:50 2005 From: akopps at LS.Berkeley.EDU (Akop Pogosian) Date: Tue, 7 Jun 2005 09:30:50 -0700 Subject: mozilla-chat installation error In-Reply-To: <1118090449.24957.5.camel@mdlinux> References: <20050606181528.GA32549@ls.berkeley.edu> <1118090449.24957.5.camel@mdlinux> Message-ID: <20050607163050.GA3702@ls.berkeley.edu> On Mon, Jun 06, 2005 at 04:40:49PM -0400, Marc Deslauriers wrote: > On Mon, 2005-06-06 at 11:15 -0700, Akop Pogosian wrote: > > I get the following error when installing the latest mozilla-chat > > update for Fedora Core 1: > > > > Installing /var/spool/up2date/mozilla-chat-1.7.7-1.1.2.legacy.i386.rpm... > > /var/tmp/rpm-tmp.63155: line 1: update-desktop-database: command not found > > > > > > Which package provides the update-desktop-database command on FC1? > > That is weird. Could you do a "rpm -q -i -p /var/spool/up2date/mozilla- > chat-1.7.7-1.1.2.legacy.i386.rpm" please. > > Marc. > Name : mozilla-chat Relocations: /usr Version : 1.7.7 Vendor: (none) Release : 1.1.2.legacy Build Date: Tue 31 May 2005 11:28:15 PM PDT Install Date: (not installed) Build Host: XXX Group : Applications/Internet Source RPM: mozilla-1.7.7-1.1.2.legacy.src.rpm Size : 756761 License: MPL/NPL/GPL/LGPL Signature : DSA/SHA1, Fri 03 Jun 2005 06:34:43 PM PDT, Key ID 6245d51354a940b0Summary : IRC client integrated with Mozilla. Description : IRC client that is integrated with the Mozilla Web browser. Note that I have rebuilt it on an RHEL 3.0 box. The only thing I changed in the spec file was the Epoch. Could that somehow cause this warning message? -- A k o p P o g o s i a n (akopps at ls.berkeley.edu) Unix Consultant Letters & Science Computer Resources 461 Birge Hall (phone: 510-643-2989) From michal at harddata.com Tue Jun 7 17:08:17 2005 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 7 Jun 2005 11:08:17 -0600 Subject: mozilla-chat installation error In-Reply-To: <20050607163050.GA3702@ls.berkeley.edu>; from akopps@LS.Berkeley.EDU on Tue, Jun 07, 2005 at 09:30:50AM -0700 References: <20050606181528.GA32549@ls.berkeley.edu> <1118090449.24957.5.camel@mdlinux> <20050607163050.GA3702@ls.berkeley.edu> Message-ID: <20050607110817.D31020@mail.harddata.com> On Tue, Jun 07, 2005 at 09:30:50AM -0700, Akop Pogosian wrote: > > > > > > Installing /var/spool/up2date/mozilla-chat-1.7.7-1.1.2.legacy.i386.rpm... > > > /var/tmp/rpm-tmp.63155: line 1: update-desktop-database: command not found ..... > > Note that I have rebuilt it on an RHEL 3.0 box. If you are rebuilding packages on a different distribution then you often have to do various tweaks in specs to adjust them accordingly. The error you are seeing surely comes from a postinstallation scripts. You can check them with a command like rpm -q --scripts /var/spool/up2date/mozilla-chat-1.7.7-1.1.2.legacy.i386.rpm 'update-desktop-database' is a program from desktop-file-utils package but I do not know what was the earliest version of the later when this utility showed up. You can make your installation scripts in a spec file make less "version sensitive" if you will write them in a style like that: type -p update-desktop-database >/dev/null && update-desktop-database ... If you are using a full path then check with [ -x /full/path/to/this ] && /full/path/to/this .... Then with a missing program you will not see attempts of execution. Michal From marcdeslauriers at videotron.ca Tue Jun 7 20:23:45 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Jun 2005 16:23:45 -0400 Subject: mozilla-chat installation error In-Reply-To: <20050607163050.GA3702@ls.berkeley.edu> References: <20050606181528.GA32549@ls.berkeley.edu> <1118090449.24957.5.camel@mdlinux> <20050607163050.GA3702@ls.berkeley.edu> Message-ID: <1118175825.6743.5.camel@mdlinux> > Name : mozilla-chat Relocations: /usr > Version : 1.7.7 Vendor: (none) > Release : 1.1.2.legacy Build Date: Tue 31 May 2005 11:28:15 PM PDT > Install Date: (not installed) Build Host: XXX > Group : Applications/Internet Source RPM: mozilla-1.7.7-1.1.2.legacy.src.rpm > Size : 756761 License: MPL/NPL/GPL/LGPL > Signature : DSA/SHA1, Fri 03 Jun 2005 06:34:43 PM PDT, Key ID 6245d51354a940b0Summary : IRC client integrated with Mozilla. > Description : > IRC client that is integrated with the Mozilla Web browser. > > Note that I have rebuilt it on an RHEL 3.0 box. The only thing I > changed in the spec file was the Epoch. Could that somehow cause this > warning message? > You are installing a mozilla package rebuilt on RHEL3 on FC1? I really don't see where the update-desktop-database is coming from as it is not in the original FC1 package. Why don't you just install the legacy built package without rebuilding it? 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 marcdeslauriers at videotron.ca Wed Jun 8 12:08:13 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 08 Jun 2005 08:08:13 -0400 Subject: Openssh public key auth broken logging In-Reply-To: <42A6CA99.20507@interlude.eu.org> References: <42A6CA99.20507@interlude.eu.org> Message-ID: <1118232493.16501.3.camel@mdlinux> On Wed, 2005-06-08 at 11:38 +0100, Joe Doran wrote: > Hi, > > > I have been using the fedora legacy mirrors for redhat 9.0 recently. > I have noticed that openssh package (openssh-server-3.5p1-11) does not > honour the strictmodes setting in sshd_config files. > After spending some time chasing this down I have narrowed the fault > down to auth2-pubkey.c line 199 which should be strict_modes not > strictmodes. > > 199c199 > < if (options.strictmodes && > --- > > if (options.strict_modes && > > > I have download the original source from the legacy mirror and checked > that I am not running a hacked up version. The sources on openbsd sites > do not seem to display this fault as far as I can tell. However I am not > very experienced in CVS and am not sure whether I am looking at the > right branch. Openssh for redhat 9.0 from: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ shows the correct "strict_modes" line. Where did you get your altered openssh package from? Is it signed? Could you post a "rpm -q -i -p openssh..." please? 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 pekkas at netcore.fi Wed Jun 8 19:41:43 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Jun 2005 22:41:43 +0300 (EEST) Subject: updated 'tree' on download.fedoralegacy.org In-Reply-To: <200503011109.47431.guallar@easternrad.com> References: <1109690391.13489.12.camel@localhost.localdomain> <200503011109.47431.guallar@easternrad.com> Message-ID: I just realized that 'tree' on download.fedoralegacy.org hasn't been updated since March 1st. Has it been replaced with something else, or doesn't the updating just work. No matter what, could we _please_ have at least something to work with. On Tue, 1 Mar 2005, Josep L. Guallar-Esteve wrote: > On Tuesday 01 March 2005 10:19, Jesse Keating wrote: >> ls -lR doesn't generate clickable links. ?However find . -print does. >> Still toying with ideas. > > Try something like this: > > echo "
    " > index.html && ls *.rpm | grep -v index.html | awk > '{print "
  • " $1"
    • "} ' >> index.html && echo > "
" >> index.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 jkeating at j2solutions.net Wed Jun 8 21:44:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 08 Jun 2005 14:44:51 -0700 Subject: updated 'tree' on download.fedoralegacy.org In-Reply-To: References: <1109690391.13489.12.camel@localhost.localdomain> <200503011109.47431.guallar@easternrad.com> Message-ID: <1118267091.6416.124.camel@localhost.localdomain> On Wed, 2005-06-08 at 22:41 +0300, Pekka Savola wrote: > I just realized that 'tree' on download.fedoralegacy.org hasn't been > updated since March 1st. > > Has it been replaced with something else, or doesn't the updating > just > work. > > No matter what, could we _please_ have at least something to work > with. Sorry, it was a test thing I was playing with. We had some discussion about a more usable item, however it got lost in the FC2 launch shuffle. I've added it back to my list of things to poke at. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From terabite at bigpond.com Thu Jun 9 06:01:24 2005 From: terabite at bigpond.com (Frank Hamersley) Date: Thu, 9 Jun 2005 16:01:24 +1000 Subject: Is .config file for FLSA:2336 RH7.3 kernel fixes available Message-ID: <008c01c56cb8$b65a7150$0100007f@CPQ7380> G'day LnxFrks, I am looking to compile this on the same .config that was used to produce the RedHat 7.3 kernel-2.4.20-42.7.legacy.i686.rpm file. Once I have that settled in as a baseline I will be patching in new code for iptables etc. Is the file about somewhere or can it be generated with a make command. Cheers, Frank. From fhe-ml-sec at ferma.fr Thu Jun 9 13:06:04 2005 From: fhe-ml-sec at ferma.fr (Frederic Hermann) Date: Thu, 09 Jun 2005 15:06:04 +0200 Subject: Self-Introduction: Frederic Hermann Message-ID: <42A83EBC.7010104@ferma.fr> Hi there, I'm Frederic Hermann, I live in France (Grenoble), and I work as Netadmin in Ferma SA, a company defined as "As a global provider of solutions to launch value-added services" to telecom operators. I have several Redhat 7.3 and Fedora Core 2 servers to manage (about 12),so I'm particulary interested in security packages for these 2 versions. I also still have one RH6.2, and 2 RH7.1 (and one slackware...), but I hope to migrate them this summer. I can test packages to be released, and I'm also quite familiar with rpm build&packaging process. I'm not a professionnal developer, but I'm still able to debug some C, C++, or Java, if necessary. Of course, as a Sysadmin, I'm used to write and read shell & perl scripts, and to configure typical internet services (web, mail, ftp, ldap), mgt tools (snmp, ntop, nagios), or firewalls (but I know ipfilter better than netfilter). Beside Linux, I'm a casual Solaris admin, and a lazy WinNT one. I've not been working on any opensource project, but I'm a professional lurker, and you can find some tracks I left in google, in different mailing list archives. As you may have guessed, English is not my native language, so I may use strange expressions from times to times. Here's my gpg identity : Key Info : pub 1024D/57CE41B2 2005-06-06 Frederic Hermann (0xA3C82E92 is obsolete for long) Primary key fingerprint: 0492 EE54 AF81 9709 912F 93CF 2452 812A 57CE 41B2 Have a nice day, Fred. From ad+lists at uni-x.org Thu Jun 9 15:22:33 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 09 Jun 2005 17:22:33 +0200 Subject: Is .config file for FLSA:2336 RH7.3 kernel fixes available In-Reply-To: <008c01c56cb8$b65a7150$0100007f@CPQ7380> References: <008c01c56cb8$b65a7150$0100007f@CPQ7380> Message-ID: <1118330552.18979.207.camel@serendipity.dogma.lan> Am Do, den 09.06.2005 schrieb Frank Hamersley um 8:01: > I am looking to compile this on the same .config that was used to produce > the RedHat 7.3 kernel-2.4.20-42.7.legacy.i686.rpm file. > > Once I have that settled in as a baseline I will be patching in new code for > iptables etc. > > Is the file about somewhere or can it be generated with a make command. > > Cheers, > Frank. If you are running RH7.3 with the mentioned kernel you have it's config file in /boot/. Else you can extract it from the kernel rpm using rpm2cpio. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.27_FC2smp Serendipity 17:20:31 up 16 days, 15:58, load average: 0.25, 0.14, 0.09 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From Axel.Thimm at ATrpms.net Thu Jun 9 23:22:02 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 10 Jun 2005 01:22:02 +0200 Subject: Fedora Legacy and Fedora Extras Message-ID: <20050609232202.GA26569@neu.nirvana> Hi, will Fedora Legacy pick up Fedora Extras support for the distributions carrying it, or only Fedora Core? Or is this not yet decided/discussed? -- 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 Thu Jun 9 23:29:13 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 09 Jun 2005 16:29:13 -0700 Subject: Fedora Legacy and Fedora Extras In-Reply-To: <20050609232202.GA26569@neu.nirvana> References: <20050609232202.GA26569@neu.nirvana> Message-ID: <1118359753.6416.194.camel@localhost.localdomain> On Fri, 2005-06-10 at 01:22 +0200, Axel Thimm wrote: > Hi, > > will Fedora Legacy pick up Fedora Extras support for the distributions > carrying it, or only Fedora Core? Or is this not yet > decided/discussed? Right now we are targetting Fedora Core. Extras is just a bit to big for our little group to take on. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at ombrepixel.com Fri Jun 10 09:03:34 2005 From: david at ombrepixel.com (David ROBERT) Date: Fri, 10 Jun 2005 11:03:34 +0200 (CEST) Subject: Identify vulnerabilities in Red Hat 7.2 Message-ID: <23578083.1118394214093.JavaMail.ghislaine@mail.ombrepixel.com> Hello, My company use a self made linux distribution mainly based on a Red Hat 7.2. Support is done by a small team. The support offered by the team is new hardware support, specific software queries but no security updates. Now, the company wants to use this distribution for internet servers. It's not secure since the latests updates that comes with it are the fedoralegacy for Red Hat 7.2 (latest : 05/2004). I think that we sould use a supported distribution for our linux servers connected to internet : security updates available (RHEL or other). The company don't really like the idea of using another linux distribution and ask me about the "cost" of securing our distribution. The first thing I want to do is to find out all the known vulnerabilities in the Red Hat 7.2. Since 05/2004, no updates has been avalaible for this distribution. Since you have good experience for supporting non-supported distribution. Can you give me some clues about how I should proceed ? I can look at all fedoralegacy updated for Red Hat 7.3 and try to figure out if each vulnerability is relevent to Red Hat 7.2. But maybe I'll miss some vulnerabilties that are in Red Hat 7.2 and NOT in Red Hat 7.3 ? Thank you if you can give me any clue or idea. David ROBERT. -- http://www.ombrepixel.com/drobert/ From pekkas at netcore.fi Fri Jun 10 09:23:26 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 10 Jun 2005 12:23:26 +0300 (EEST) Subject: Identify vulnerabilities in Red Hat 7.2 In-Reply-To: <23578083.1118394214093.JavaMail.ghislaine@mail.ombrepixel.com> References: <23578083.1118394214093.JavaMail.ghislaine@mail.ombrepixel.com> Message-ID: On Fri, 10 Jun 2005, David ROBERT wrote: > I can look at all fedoralegacy updated for Red Hat 7.3 and try to figure out if each > vulnerability is relevent to Red Hat 7.2. But maybe I'll miss some vulnerabilties > that are in Red Hat 7.2 and NOT in Red Hat 7.3 ? If Fedora Legacy process was working properly, the easiest approach would probably be updating from 7.2 to 7.3 online, using yum, up2date, or whatever. I have done a couple of dozen of such upgrades and they're very straightforward. But as FL doesn't exactly work at the moment, I don't think there's much of advise to give right now. -- 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 david at ombrepixel.com Fri Jun 10 09:40:05 2005 From: david at ombrepixel.com (David ROBERT) Date: Fri, 10 Jun 2005 11:40:05 +0200 (CEST) Subject: Identify vulnerabilities in Red Hat 7.2 Message-ID: <7182746.1118396405069.JavaMail.ghislaine@mail.ombrepixel.com> Pekka Savola a ?crit : > If Fedora Legacy process was working properly, the easiest approach > would probably be updating from 7.2 to 7.3 online, using yum, up2date, > or whatever. I have done a couple of dozen of such upgrades and > they're very straightforward. My problem is that I need to fix security issues on a Red Hat 7.2, not to upgrade the distribution to a Red Hat 7.3. It's not the same thing since packages versions (not releases) are different between 7.2 and 7.3. This is the reason my company is reticent to upgrade the distribution. Maybe (and I think) the only cost acceptable solution is to change the distribution, but I have to evaluate this before. -- David ROBERT http://www.ombrepixel.com/drobert/ From pekkas at netcore.fi Fri Jun 10 09:51:40 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 10 Jun 2005 12:51:40 +0300 (EEST) Subject: list of all updates for $foo Message-ID: Hi, I wrote the attached script half a year ago or so, maybe some of you might find it useful. Basically you say something like 'list-latest iptables', and it shows all the iptables packages in all Fedora Legacy directories, as well as the updates in RHEL21/RHEL3. This allows quick & easy answers to the questions, "what is the latest package out there? If I need to build a new package with a security fix, which package should I use as a basis? Has there been an update to RHEL yet?" Requires lftp. HTH, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------- next part -------------- A non-text attachment was scrubbed... Name: list-latest.sh Type: application/x-sh Size: 1204 bytes Desc: URL: From brian.t.brunner at gai-tronics.com Fri Jun 10 14:28:37 2005 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Fri, 10 Jun 2005 07:28:37 -0700 Subject: Identify vulnerabilities in Red Hat 7.2 Message-ID: WBEL (White Box Enterprise Linux) is a free re-compile of the RHEL sources. This should contain the costs, and give you an up-to-date kernel (relative to 7.2) Also, CentOS (another project doing the same thing as WBEL for the same price) is a good choice. Either way you get a kernel current to some time this year, and 5 years of RH "support" (meaning when RH releases kernel patches, you can grab and use those patches as you need). Fedora Legacy dropped 7.2 for lack of public support, and has kept up on 7.3 and 9 (plus Fedora Core releases). Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> david at ombrepixel.com 06/10/05 05:03AM >>> Hello, My company use a self made linux distribution mainly based on a Red Hat 7.2. Support is done by a small team. The support offered by the team is new hardware support, specific software queries but no security updates. Now, the company wants to use this distribution for internet servers. It's not secure since the latests updates that comes with it are the fedoralegacy for Red Hat 7.2 (latest : 05/2004). I think that we sould use a supported distribution for our linux servers connected to internet : security updates available (RHEL or other). The company don't really like the idea of using another linux distribution and ask me about the "cost" of securing our distribution. The first thing I want to do is to find out all the known vulnerabilities in the Red Hat 7.2. Since 05/2004, no updates has been avalaible for this distribution. Since you have good experience for supporting non-supported distribution. Can you give me some clues about how I should proceed ? I can look at all fedoralegacy updated for Red Hat 7.3 and try to figure out if each vulnerability is relevent to Red Hat 7.2. But maybe I'll miss some vulnerabilties that are in Red Hat 7.2 and NOT in Red Hat 7.3 ? Thank you if you can give me any clue or idea. David ROBERT. -- http://www.ombrepixel.com/drobert/ -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated From matt.followers at gmail.com Fri Jun 10 15:00:00 2005 From: matt.followers at gmail.com (Matthew Nuzum) Date: Fri, 10 Jun 2005 10:00:00 -0500 Subject: Identify vulnerabilities in Red Hat 7.2 In-Reply-To: <23578083.1118394214093.JavaMail.ghislaine@mail.ombrepixel.com> Message-ID: <42a9aaf4.40009c03.555c.05fa@mx.gmail.com> > Hello, > > My company use a self made linux distribution mainly based on a Red Hat > 7.2. > Support is done by a small team. The support offered by the team is > new hardware support, specific software queries but no security updates. ... > > The first thing I want to do is to find out all the known vulnerabilities > in the > Red Hat 7.2. Since 05/2004, no updates has been avalaible for this > distribution. > > Since you have good experience for supporting non-supported distribution. > Can you > give me some clues about how I should proceed ? It's a pain in the butt getting updates for 7.2. Many packages, especially web related packages, use newer versions of the Berkley DB and it's very hard to find that for the older RH versions. I've got several computers that I did an in-place upgrade to 7.3 that worked perfectly. I've found it slightly easier to get updates for 7.3, but it's getting more difficult with each passing month. You're at the moment of truth and I'd strongly urge you to go to a supported distro. I can definitely relate to the problems of updating versions because it takes months for us to retest our software on a new OS. (We started in December and we're just about done) Since I've been there, here's my 2 cents worth: Supported server-class distros I know of: (i.e. have a financially stable, commercial backing for support) RedHat Enterprise (3 - 4 years support) Suse Enterprise (3 - 4 years support) Ubuntu (18 months support) Of those, the only that is freely available is Ubuntu. Choosing an RHEL clone is, IMHO, a joke, because you *think* you're getting support because you're using a freely available variant of a supported distribution, but the fact is, the user communities behind the RHEL clones are rather small. CentOS seems the largest and most active. White Box has a lot of name recognition, but to me it appears that it's one man and when he goes on vacation everything stops. I don't know much about the Tao RHEL clone. We like Ubuntu/Debian. Of all the free-bies out there, they seem the most stable, which is what I need. The migration from 7.3 to Ubuntu/Debian is non-trivial. However, Ubuntu has a large software repository called "Universe" that contains many of the software packages we standardized on, so things have worked very well. Sorry for dragging on so much in this message. I could say a lot more, so if you'd like more details, e-mail me. -- 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 pekkas at netcore.fi Sat Jun 11 04:34:50 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 11 Jun 2005 07:34:50 +0300 (EEST) Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> Message-ID: OK, almost a week has passed since the last message on this thread. I think we need to decide what to do. Specific suggestions? I've seen at least the following proposals: 1) 1 VERIFY vote needed (for any version), after that packages are published after 2 weeks of timeout unless needswork/discuss or issues are identified. 2) 2 VERIFY votes are needed (for any version), after that packages are published after 2 weeks of timeout unless needswork/discuss or issues are identified. a) timeout is counted from the first VERIFY b) timeout is counted from the second VERIFY 3) 2 VERIFY votes are needed (for any version), after that packages are published after at most 4 weeks of timeout after the first verify, but two weeks after the second, unless needswork/discuss or issues are identified. 4) 2 VERIFY votes are needed (for any version), after that packages are published after 4 weeks of timeout unless needswork/discuss or issues are identified. 1) or 2) are OK by me. I could also live with 3) but I think it's overly complex. 4) does not seem like a sufficient change. Let's have the opinions by Monday, and make the decision then? We can't stall anymore. -- 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 jimpop at yahoo.com Sat Jun 11 17:16:46 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 11 Jun 2005 13:16:46 -0400 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> Message-ID: <1118510207.15793.10.camel@localhost> On Sat, 2005-06-11 at 07:34 +0300, Pekka Savola wrote: > OK, almost a week has passed since the last message on this thread. I > think we need to decide what to do. > > Specific suggestions? How about 2 Verifies for core/server packages and 1 Verify for everything else? Also, only 1 Verify would be needed for a core/server package that is being re-released within a 3 month period. -Jim P. From pekkas at netcore.fi Sat Jun 11 20:33:29 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 11 Jun 2005 23:33:29 +0300 (EEST) Subject: changes are still needed In-Reply-To: <1118510207.15793.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> Message-ID: On Sat, 11 Jun 2005, Jim Popovitch wrote: > On Sat, 2005-06-11 at 07:34 +0300, Pekka Savola wrote: >> OK, almost a week has passed since the last message on this thread. I >> think we need to decide what to do. >> >> Specific suggestions? > > How about 2 Verifies for core/server packages and 1 Verify for > everything else? Also, only 1 Verify would be needed for a core/server > package that is being re-released within a 3 month period. How do you define 'core/server packages'? This would be OK with me, but maybe a bit complex for my taste. -- 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 jimpop at yahoo.com Sat Jun 11 21:25:39 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 11 Jun 2005 17:25:39 -0400 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> Message-ID: <1118525140.10253.7.camel@localhost> On Sat, 2005-06-11 at 23:33 +0300, Pekka Savola wrote: > On Sat, 11 Jun 2005, Jim Popovitch wrote: > > On Sat, 2005-06-11 at 07:34 +0300, Pekka Savola wrote: > >> OK, almost a week has passed since the last message on this thread. I > >> think we need to decide what to do. > >> > >> Specific suggestions? > > > > How about 2 Verifies for core/server packages and 1 Verify for > > everything else? Also, only 1 Verify would be needed for a core/server > > package that is being re-released within a 3 month period. > > How do you define 'core/server packages'? 1) any mandatory (based on rpm dependencies) package (i.e. krb5-libs, inetd, vi) 2) any package that opens an external port <= 1024 by default (i.e. apache, named/bind9, openssh, etc) 3) any package that potentially listens on an external port <= 1024 (telnet-server, wsftp, etc) 4) any package that is used for non-gui server administration (i.e. nslookup, dig, tcpdump, etc). 5) any package that is a dependency of any of the above (i.e. openssl, etc) -Jim P. From rostetter at mail.utexas.edu Sun Jun 12 05:30:59 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sun, 12 Jun 2005 00:30:59 -0500 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> Message-ID: <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> Quoting Pekka Savola : > OK, almost a week has passed since the last message on this thread. I > think we need to decide what to do. Sorry, I've not been available lately. > I've seen at least the following proposals: > > 1) 1 VERIFY vote needed (for any version), after that packages are > published after 2 weeks of timeout unless needswork/discuss or issues > are identified. If we assume the person who created the package has done some QA before submitting it for QA, then one vote could be seen as two, unless that only vote is from the creator. I'm not sure why some/most package creators don't submit QA feedback on their own packages, but maybe we can get them to do so in the future? Anyway, if the creator posts a QA, this would guarantee all packages get released in 2 weeks. I like that everything gets out, but I think 2 weeks is maybe too fast for only the creator doing QA (possibly on only one OS version for a patch that covers multiple OS versions). See my concern here? I guess you could modify it as "1 VERIFY from someone other than the package/patch creator" but... > 2) 2 VERIFY votes are needed (for any version), after that packages > are published after 2 weeks of timeout unless needswork/discuss or > issues are identified. I like this one, and could live with it. Even if the creator does a QA, the creator must do multiple OS version QA, or we still need someone else to do QA. This is much better than #1 because a creator can't force an otherwise untested package out the door. > a) timeout is counted from the first VERIFY > b) timeout is counted from the second VERIFY It seems to be logical it would have to be after the second, since there could be more than 2 weeks between the first and second... > 3) 2 VERIFY votes are needed (for any version), after that packages > are published after at most 4 weeks of timeout after the first verify, > but two weeks after the second, unless needswork/discuss or issues are > identified. I think this is the very best. I'd also be able to settle for a modified version: 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify votes (for any version) and 2 weeks of no activity after the first verify vote. The above modification means everything is released (if the creator does a QA) after at most 4 weeks... > 4) 2 VERIFY votes are needed (for any version), after that packages > are published after 4 weeks of timeout unless needswork/discuss or > issues are identified. No, as a package might never get released if we don't get the 2 votes. And that would seem to be a problem. > 1) or 2) are OK by me. I could also live with 3) but I think it's > overly complex. 4) does not seem like a sufficient change. See my above comments. I only agree with you 100% on the idea that #4 won't help, and hence isn't in consideration. > Let's have the opinions by Monday, and make the decision then? We > can't stall anymore. Agreed. Sorry I've been absent, but life marches on whether I like it or not. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From warren at togami.com Sun Jun 12 21:13:16 2005 From: warren at togami.com (Warren Togami) Date: Sun, 12 Jun 2005 11:13:16 -1000 Subject: Updates Politics Proposal In-Reply-To: <20050524221036.GA22637@jadzia.bu.edu> References: <1116969062.12813.24.camel@lara> <1116971879.5520.18.camel@jkeating2.hq.pogolinux.com> <20050524221036.GA22637@jadzia.bu.edu> Message-ID: <42ACA56C.10801@togami.com> Matthew Miller wrote: > On Tue, May 24, 2005 at 02:57:59PM -0700, Jesse Keating wrote: > >>>What say you? >> >>That leads to releases being upgraded on previous OS releases. This is >>against the policy of Fedora Legacy, as it is no longer a backport. We >>need to avoid this as much as possible. > > > To elaborate -- the concern is that this actually causes *more* work, > because upgrading packages can have all sorts of interactions and > consequences. Keeping the package versions the same means that less > extensive testing is required, and rarely if ever does changing one package > mean that some other package needs to be updated too. > I cannot generalize about other packages, but keeping the same version makes a lot of sense for gaim specifically. Rawhide's gaim package should work on all legacy distributions after flipping switches and rebuilding. And there is no good reason not to upgrade gaim's version. Nothing depends on gaim, and especially not server functionality. Just do it for gaim. Save time for other more important backports. Warren From pekkas at netcore.fi Mon Jun 13 11:27:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 13 Jun 2005 14:27:59 +0300 (EEST) Subject: changes are still needed In-Reply-To: <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> Message-ID: It would be interesting to hear what others think the direction should be. If you think "just pick a direction, I don't care which", stating so wouldn't hurt either. On Sun, 12 Jun 2005, Eric Rostetter wrote: >> published after 2 weeks of timeout unless needswork/discuss or issues >> are identified. > > If we assume the person who created the package has done some QA before > submitting it for QA, then one vote could be seen as two, unless that > only vote is from the creator. I'm not sure why some/most package creators > don't submit QA feedback on their own packages, but maybe we can get > them to do so in the future? > > Anyway, if the creator posts a QA, this would guarantee all packages get > released in 2 weeks. I like that everything gets out, but I think 2 weeks > is maybe too fast for only the creator doing QA (possibly on only one OS > version for a patch that covers multiple OS versions). See my concern > here? > > I guess you could modify it as "1 VERIFY from someone other than the > package/patch creator" but... Purely from the administrative perspective, IMHO, the package creator must not give PUBLISH or VERIFY votes, though such can be implicit. There is too much conflict of interest there, so recusing is IMHO the only option. >> 2) 2 VERIFY votes are needed (for any version), after that packages >> are published after 2 weeks of timeout unless needswork/discuss or >> issues are identified. > > I like this one, and could live with it. Even if the creator does a QA, > the creator must do multiple OS version QA, or we still need someone else > to do QA. This is much better than #1 because a creator can't force an > otherwise untested package out the door. > >> a) timeout is counted from the first VERIFY >> b) timeout is counted from the second VERIFY > > It seems to be logical it would have to be after the second, since there > could be more than 2 weeks between the first and second... I'm OK with either approach, but I'd prefer a) with the interpretation that the creator does not do formal QA (so if you'd always count that as one, it would be equivalent to what you're thinking). >> 3) 2 VERIFY votes are needed (for any version), after that packages >> are published after at most 4 weeks of timeout after the first verify, >> but two weeks after the second, unless needswork/discuss or issues are >> identified. > > I think this is the very best. I'd also be able to settle for a modified > version: > > 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify > votes (for any version) and 2 weeks of no activity after the first > verify vote. > > The above modification means everything is released (if the creator > does a QA) after at most 4 weeks... As stated above, I don't think we should recommend (or even allow) the package creator doing QA for his/her own packages. That's the other people's job, and ensures the logical separation of functions. Of course, we could assume that most package creators do test the packages they create, and implicitly include that here (i.e., require just one "external" verify vote to approve a package after a timeout). -- 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 rostetter at mail.utexas.edu Mon Jun 13 14:29:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Jun 2005 09:29:33 -0500 Subject: changes are still needed In-Reply-To: <1118510207.15793.10.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> Message-ID: <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> Quoting Jim Popovitch : > On Sat, 2005-06-11 at 07:34 +0300, Pekka Savola wrote: > > OK, almost a week has passed since the last message on this thread. I > > think we need to decide what to do. > > > > Specific suggestions? > > How about 2 Verifies for core/server packages and 1 Verify for > everything else? Who decides what a core/server package is, and what isn't? Also, if the packager/creator is the only voter, do we really have any QA at all if only one vote is needed? > Also, only 1 Verify would be needed for a core/server > package that is being re-released within a 3 month period. Hmm... Interesting twist. Not sure I'd agree with it though. Maybe if you want to say "a re-release to fix a bug in a previous FL release" (which happens). > -Jim P. -- Eric Rostetter From rostetter at mail.utexas.edu Mon Jun 13 14:45:36 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Jun 2005 09:45:36 -0500 Subject: changes are still needed In-Reply-To: <1118525140.10253.7.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> Message-ID: <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> Quoting Jim Popovitch : > > How do you define 'core/server packages'? > > 1) any mandatory (based on rpm dependencies) package > (i.e. krb5-libs, inetd, vi) > 2) any package that opens an external port <= 1024 by default > (i.e. apache, named/bind9, openssh, etc) > 3) any package that potentially listens on an external port <= 1024 > (telnet-server, wsftp, etc) > 4) any package that is used for non-gui server administration > (i.e. nslookup, dig, tcpdump, etc). > 5) any package that is a dependency of any of the above > (i.e. openssl, etc) > > -Jim P. 1 and 5 seem to be about the same thing really. 2 and 3 are pretty close, since telnet/ftp/etc traditionally use ports < 1024 and are server apps. But generally I could accept all the above except for number 4. Number 4 is the one open to endless debate. And many people like gui server apps (see the whole redhat-config-* line of gui programs, the industry wide move to web based configuration, etc). Some will say that some of the apps you listed are not important, depreciated, or otherwise not of value to them. Others will insist something is of great use for server admin, even though no one else sees their point. Open to lots of debate here. > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From jkeating at j2solutions.net Mon Jun 13 17:08:25 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 13 Jun 2005 10:08:25 -0700 Subject: [Fwd: Re: Summary of FC4 vulnerabilities] Message-ID: <1118682505.13606.19.camel@localhost.localdomain> Useful wiki page... I'm still working on arranging proper access to the Fedora Project wiki system for legacy pages. Look for more news on this soon. -------- Forwarded Message -------- From: Rahul Sundaram Reply-To: Development discussions related to Fedora Core To: Development discussions related to Fedora Core , mjc at redhat.com Subject: Re: Summary of FC4 vulnerabilities Date: Mon, 13 Jun 2005 22:31:57 +0530 Mark J Cox wrote: > Quick Summary: > > For 20030101-20050607 there are a potential 863 CVE named > vulnerabilities that could have affected FC4 packages. 759 (88%) of > those are fixed because FC4 includes an upstream version that includes > a fix, 10 (1%) are still outstanding, and 94 (11%) are fixed with a > backported patch. This is very good amount of details. I have created a wiki page with this information at http://fedoraproject.org/wiki/securitystatus. Regards Rahul -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Mon Jun 13 18:16:24 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 13 Jun 2005 21:16:24 +0300 (EEST) Subject: changes are still needed In-Reply-To: <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> Message-ID: On Mon, 13 Jun 2005, Eric Rostetter wrote: > 1 and 5 seem to be about the same thing really. 2 and 3 are pretty close, > since telnet/ftp/etc traditionally use ports < 1024 and are server apps. > But generally I could accept all the above except for number 4. > > Number 4 is the one open to endless debate. And many people like gui server > apps (see the whole redhat-config-* line of gui programs, the industry > wide move to web based configuration, etc). Some will say that some of > the apps you listed are not important, depreciated, or otherwise not of > value to them. Others will insist something is of great use for server > admin, even though no one else sees their point. Open to lots of debate here. .. which is why we shouldn't go for this kind of separation, IMHO. It's a bit complex, and if the "server guys" are interested in higher QA, I'm sure they will participate more actively in QA'ing the server packages :) -- 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 jimpop at yahoo.com Mon Jun 13 18:27:17 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 13 Jun 2005 14:27:17 -0400 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> Message-ID: <1118687238.21418.6.camel@localhost> On Mon, 2005-06-13 at 21:16 +0300, Pekka Savola wrote: > It's a bit complex, and if the "server guys" are interested in higher > QA, I'm sure they will participate more actively in QA'ing the server > packages :) I *DO* Q&A the RH73 server packages, the problem is they are still held up by the lack of interest in FC1, RH9, etc. I *DO NOT* do Q&A on packages I have no interest (and/or knowledge) in, nor do I expect anyone else to. We are not doing Q&A for CUA reasons. We are doing Q&A for security and stability reasons. Therefore I think it is foolish to keep asking people unfamiliar with an application (not to mention the bug/flaw/fix) to do Q&A on said application. -Jim P. From rostetter at mail.utexas.edu Mon Jun 13 21:42:38 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 13 Jun 2005 16:42:38 -0500 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> Message-ID: <1118698958.4f65bd5d3288c@mail.ph.utexas.edu> Quoting Pekka Savola : > It would be interesting to hear what others think the direction should > be. If you think "just pick a direction, I don't care which", stating > so wouldn't hurt either. Warren Togami once said (see http://www.redhat.com/archives/fedora-legacy-list/2003-November/msg00025.html for details): > fedora.us and I believe Legacy should REFUSE to publish anything that > has not been thoroughly checked by more than one trusted person. This > is especially important for Legacy because far fewer people would be > doing quality assurance and real world testing. And I have to say, I feel we should stick with this. He also later said (see http://www.redhat.com/archives/fedora-legacy-list/2004-January/msg00365.html for details): >> C) How can we verify that the tester is really testing the package? > > That is why multiple testers are needed. One of the testers should be the > packager of course. People that have submitted good testing results and > especially found ERRORS in the past are to be trusted more than new people. > >> D) Since we release the package across multiple releases, how long do we >> wait on a specific release to be tested before releasing the rest of the >> packages? > > Use best judgement. Wait for enough clearsigned feedback based upon the > importance of a package to avoid regressions. Something like apache would need > far more testing than something like screen. But NEVER push it too soon. and no on to the question at hand: > Purely from the administrative perspective, IMHO, the package creator > must not give PUBLISH or VERIFY votes, though such can be implicit. I know it was discussed on list and stated that the package creator *may* vote, though I can't find the reference to it. And if you read Warren's quotes above, you can see he clearly accounts for the creator to be able to vote. So, past history says that yes, the creator can vote. > There is too much conflict of interest there, so recusing is IMHO the > only option. Well, if you say it only takes one vote, then I agree. Otherwise, I disagree. We have two few people working on the project to eliminate anyone. > I'm OK with either approach, but I'd prefer a) with the interpretation > that the creator does not do formal QA (so if you'd always count that > as one, it would be equivalent to what you're thinking). This would be a change of policy we'd have to bring up and get consensus on. > As stated above, I don't think we should recommend (or even allow) the > package creator doing QA for his/her own packages. That's the other > people's job, and ensures the logical separation of functions. But historically we have allowed this, and no one has yet approved a change to that. > Of course, we could assume that most package creators do test the > packages they create, and implicitly include that here (i.e., require > just one "external" verify vote to approve a package after a timeout). See above statements by Warren, which agree with my own opinions. > -- > 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 > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From pekkas at netcore.fi Tue Jun 14 05:43:41 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Jun 2005 08:43:41 +0300 (EEST) Subject: changes are still needed In-Reply-To: <1118698958.4f65bd5d3288c@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> <1118698958.4f65bd5d3288c@mail.ph.utexas.edu> Message-ID: On Mon, 13 Jun 2005, Eric Rostetter wrote: >> As stated above, I don't think we should recommend (or even allow) the >> package creator doing QA for his/her own packages. That's the other >> people's job, and ensures the logical separation of functions. > > But historically we have allowed this, and no one has yet approved a > change to that. Has this ever occurred? I have not seen a single instance of package creator doing a PUBLISH or VERIFY during the time I've been active in the project (like 7-8 months or so). But never mind. Maybe Warren and others had higher hopes for the participation enthusiasm which just didn't materialize to that degree for many reasons (like being too difficult to participate). If we don't manage to get updates out, we'd be better dead. -- 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 pekkas at netcore.fi Tue Jun 14 07:55:05 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Jun 2005 10:55:05 +0300 (EEST) Subject: how/when to QA [Re: changes are still needed] In-Reply-To: <1118687238.21418.6.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> <1118687238.21418.6.camel@localhost> Message-ID: On Mon, 13 Jun 2005, Jim Popovitch wrote: > I *DO NOT* do Q&A on packages I have no interest (and/or knowledge) in, > nor do I expect anyone else to. We are not doing Q&A for CUA reasons. > We are doing Q&A for security and stability reasons. Therefore I think > it is foolish to keep asking people unfamiliar with an application (not > to mention the bug/flaw/fix) to do Q&A on said application. How do you think RHEL is doing QA for the updates they release? Are the testers intimate with the packages they test? Do you require a higher degree of quality from Fedora Legacy than from RHEL? We would need hundreds if not thousands of active people if the people doing QA would have to fulfill the above goals (which, would naturally be desirable, but not realistic). So, we have to make best of our resources, and that IMHO means trying to get anyone with access to a suitable distro/package do the QA. Remember, almost all patches we use come from ***already QA'd sources***. -- 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 pekkas at netcore.fi Tue Jun 14 07:59:58 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Jun 2005 10:59:58 +0300 (EEST) Subject: proposed verify change In-Reply-To: <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> Message-ID: In the interest of stopping the discussion and getting back to action, I propose the following change (from Eric): 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify votes (for any version) and 2 weeks of no activity after the first verify vote. I also suggest that unless there is significant objection, this is implemented already this week by adding something like "timeout=20050618" in the status whiteboard for the packages. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jonny.strom at netikka.fi Tue Jun 14 08:07:46 2005 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 14 Jun 2005 11:07:46 +0300 Subject: proposed verify change In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> Message-ID: <42AE9052.7070201@netikka.fi> Pekka Savola wrote: > In the interest of stopping the discussion and getting back to action, I > propose the following change (from Eric): > > 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify > votes (for any version) and 2 weeks of no activity after the first > verify vote. > > I also suggest that unless there is significant objection, this is > implemented already this week by adding something like > "timeout=20050618" in the status whiteboard for the packages. > Hi I have no objections to this lets make it official. Thanks Johnny From drees76 at gmail.com Tue Jun 14 08:11:07 2005 From: drees76 at gmail.com (David Rees) Date: Tue, 14 Jun 2005 01:11:07 -0700 Subject: proposed verify change In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> Message-ID: <72dbd31505061401116078975b@mail.gmail.com> On 6/14/05, Pekka Savola wrote: > > 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify > votes (for any version) and 2 weeks of no activity after the first > verify vote. > > I also suggest that unless there is significant objection, this is > implemented already this week by adding something like > "timeout=20050618" in the status whiteboard for the packages. Sounds like a reasonable compromise. -Dave From dom at earth.li Tue Jun 14 09:08:25 2005 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 14 Jun 2005 10:08:25 +0100 Subject: changes are still needed In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118554259.f39db0a6c3f5c@mail.ph.utexas.edu> <1118698958.4f65bd5d3288c@mail.ph.utexas.edu> Message-ID: <20050614090825.GJ32369@urchin.earth.li> On Tue, Jun 14, 2005 at 08:43:41AM +0300, Pekka Savola wrote: > On Mon, 13 Jun 2005, Eric Rostetter wrote: > >>As stated above, I don't think we should recommend (or even allow) the > >>package creator doing QA for his/her own packages. That's the other > >>people's job, and ensures the logical separation of functions. > > > >But historically we have allowed this, and no one has yet approved a > >change to that. > > Has this ever occurred? I have not seen a single instance of package > creator doing a PUBLISH or VERIFY during the time I've been active in > the project (like 7-8 months or so). A handful of packages have gone straight to update-testing without a separate PUBLISH when built by myself or Marc. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From jimpop at yahoo.com Tue Jun 14 13:11:21 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 14 Jun 2005 09:11:21 -0400 Subject: how/when to QA [Re: changes are still needed] In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> <1118687238.21418.6.camel@localhost> Message-ID: <1118754681.25828.4.camel@localhost> On Tue, 2005-06-14 at 10:55 +0300, Pekka Savola wrote: > Remember, almost all patches we use come from ***already QA'd > sources***. So why do inexperienced people need to do more Q&A on those packages? -Jim P. From pekkas at netcore.fi Tue Jun 14 19:44:58 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Jun 2005 22:44:58 +0300 (EEST) Subject: how/when to QA [Re: changes are still needed] In-Reply-To: <1118754681.25828.4.camel@localhost> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118525140.10253.7.camel@localhost> <1118673936.8ccf2edfc6d0e@mail.ph.utexas.edu> <1118687238.21418.6.camel@localhost> <1118754681.25828.4.camel@localhost> Message-ID: On Tue, 14 Jun 2005, Jim Popovitch wrote: > On Tue, 2005-06-14 at 10:55 +0300, Pekka Savola wrote: >> Remember, almost all patches we use come from ***already QA'd >> sources***. > > So why do inexperienced people need to do more Q&A on those packages? So that at least someone has tested that the application seems to work. The application has compiled, it doesn't crash outright with basic functionality, etc. -- that's trivial testing but it has non-trivial impact. If we add tools to the mix (e.g., ways more easily to detect if the file list provided by the package, dependencies, libraries, etc. have changed), we've achieved a great deal. Personally, I'd be OK with just publishing "trivial updates" if built by a trusted developer without any QA at all, but trivial QA like above should be doable by any FL user, might help get the community more involved with the project, etc. For more critical updates, or patches we create on on our, I agree it would be strongly desirable to get more QA -- but unfortunately even that doesn't seem to be happening all that often. -- 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 rostetter at mail.utexas.edu Wed Jun 15 14:28:36 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 15 Jun 2005 09:28:36 -0500 Subject: proposed verify change In-Reply-To: <42AE9052.7070201@netikka.fi> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> <42AE9052.7070201@netikka.fi> Message-ID: <1118845716.887ac4fd1e27c@mail.ph.utexas.edu> Quoting Johnny Strom : > Pekka Savola wrote: > > In the interest of stopping the discussion and getting back to action, I > > propose the following change (from Eric): Yes, I've spent more time on this e-mail thread than I have doing QA, which is sad. I'd like to see it end. > > 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify > > votes (for any version) and 2 weeks of no activity after the first > > verify vote. I'm of course in favor of it. We can re-evaluate it after a couple months to see how it is working. > > I also suggest that unless there is significant objection, this is > > implemented already this week by adding something like > > "timeout=20050618" in the status whiteboard for the packages. I'm still foggy on the whiteboard thing. As far as I can tell, only people with sufficient karma or the bug-owner can update the whiteboard status? Is this correct? I know all my attempts to change a whiteboard have failed so far. -- Eric Rostetter From pekkas at netcore.fi Wed Jun 15 15:24:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Jun 2005 18:24:59 +0300 (EEST) Subject: proposed verify change In-Reply-To: <1118845716.887ac4fd1e27c@mail.ph.utexas.edu> References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> <42AE9052.7070201@netikka.fi> <1118845716.887ac4fd1e27c@mail.ph.utexas.edu> Message-ID: On Wed, 15 Jun 2005, Eric Rostetter wrote: >>> I also suggest that unless there is significant objection, this is >>> implemented already this week by adding something like >>> "timeout=20050618" in the status whiteboard for the packages. > > I'm still foggy on the whiteboard thing. As far as I can tell, only people > with sufficient karma or the bug-owner can update the whiteboard status? > Is this correct? I know all my attempts to change a whiteboard have > failed so far. Based on some experimental results, I think it is correct, though I'm not sure whether this could be easily changed or not (either for specific "watchers" persons or for everyone). I guess this is one more thing to investigate by the Fedora Legacy leadership. I personally have "special powers" due to having been in the Red Hat beta team. I do not know how many others in the FL project can edit whiteboards (and other things) in bugzilla at will, but I'd certainly hope all the "core" members (whoever those are) are able to do so... -- 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 mattdm at mattdm.org Wed Jun 15 17:42:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 15 Jun 2005 13:42:11 -0400 Subject: proposed verify change In-Reply-To: References: <1117737879.c852097912420@mail.ph.utexas.edu> <1117743857.17100.5.camel@mdlinux> <1118510207.15793.10.camel@localhost> <1118672973.d5d4d72c07fd6@mail.ph.utexas.edu> <42AE9052.7070201@netikka.fi> <1118845716.887ac4fd1e27c@mail.ph.utexas.edu> Message-ID: <20050615174211.GA16497@jadzia.bu.edu> On Wed, Jun 15, 2005 at 06:24:59PM +0300, Pekka Savola wrote: > >I'm still foggy on the whiteboard thing. As far as I can tell, only people > >with sufficient karma or the bug-owner can update the whiteboard status? > >Is this correct? I know all my attempts to change a whiteboard have > >failed so far. > Based on some experimental results, I think it is correct, though I'm > not sure whether this could be easily changed or not (either for > specific "watchers" persons or for everyone). I guess this is one > more thing to investigate by the Fedora Legacy leadership. Plus, it's really hard to remember what the various "magically meaningful" whiteboard strings are. We really need to get a proper bugzilla workflow set up. I'll see if I can hit up the RH bugzilla people again. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From cameron.kellough at sri.com Thu Jun 16 02:53:29 2005 From: cameron.kellough at sri.com (Cameron Kellough) Date: Wed, 15 Jun 2005 21:53:29 -0500 Subject: Using the Kernel Update rpm to 2.6.10 for Fedora Core 2 Message-ID: <42B0E9A9.2080508@sri.com> Hi, I wanted to note that upgrading the kernel to 2.6.10 with the rpm on fedora core 2 updates does not upgrade the wireless extensions package on the system. Because the new kernel uses a version of the wireless extensions protocol that is newer than version 26 of the Wireless Tools program supports, wireless networking may stop working with certain access points. The fix is to install version 27 of the Wireless Tools available from http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html Also, for laptop use with a laptop that uses apm, one must add acpi=off and apm=on kernel parameters for apm power management to work properly. Without doing this, acpi overrrides apm and you get no apm support. -- Cameron Kellough, Research Engineer ESD Intelligence & Information Systems SRI International, Huntsville Field Operations Tel 256-684-0417 Page 1-877-730-9920 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5221 bytes Desc: S/MIME Cryptographic Signature URL: From pekkas at netcore.fi Thu Jun 16 12:54:35 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Jun 2005 15:54:35 +0300 (EEST) Subject: issues list(s) Message-ID: Hi, I've gone through the packages waiting for VERIFY, and tagged them as appropriate. I've also augmented my script to show the timeouting (and not timeouting) packages separately: 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 ...... [the agreed changes, to be updated to wiki etc.] 1 verify vote (for any version) plus 4 weeks of no activity, or 2 verify votes (for any version) and 2 weeks of no activity after the first verify vote. I also suggest that unless there is significant objection, this is implemented already this week by adding something like "timeout=20050618" in the status whiteboard for the packages. From donjr at maner.org Thu Jun 16 18:31:56 2005 From: donjr at maner.org (Donald Maner) Date: Thu, 16 Jun 2005 13:31:56 -0500 Subject: Self Introduction: Donald Maner Message-ID: <58DCCC4F6A6E33438329DAD381B41E764FED@aruba.maner.org> Hello, everyone.? I've been a lurker on fedora-legacy for far too long, and it's time I get involved. ? 1. Name: Donald E. Maner, Jr. 2. Location: McKinney, Texas, USA 3. Profession: Systems Admin 4. Company: Personal work, not company sponsored 5. Goals: QA, QA, QA.? I plan to do all the QA that I can for the supported versions.? VMWare comes in handy. 6. Qualifications: RedHat Certified Engineer.? That's about it, this is my first real participation in any community project. 7. GPG KEYID and fingerprint: pub 1024D/AD1BB103 2005-06-16 Key fingerprint = 7205 ABCA 67B6 82A0 4FF0 D6BF 4E7C 0AEB AD1B B103 uid Donald Maner sub 2048g/FA0A8D6A 2005-06-16 From pekkas at netcore.fi Thu Jun 16 20:55:08 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Jun 2005 23:55:08 +0300 (EEST) Subject: issues list(s) In-Reply-To: References: Message-ID: On Thu, 16 Jun 2005, Pekka Savola wrote: > [the agreed changes, to be updated to wiki etc.] I've now also updated the Wiki. I also added a new page describing the status whiteboard tags. http://www.fedoralegacy.org/wiki/index.php/QaTesting http://www.fedoralegacy.org/wiki/index.php/StatusWhiteboard -- 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 Fri Jun 17 01:43:09 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 16 Jun 2005 21:43:09 -0400 Subject: Self Introduction: Donald Maner In-Reply-To: <58DCCC4F6A6E33438329DAD381B41E764FED@aruba.maner.org> References: <58DCCC4F6A6E33438329DAD381B41E764FED@aruba.maner.org> Message-ID: <1118972589.6458.19.camel@mdlinux> On Thu, 2005-06-16 at 13:31 -0500, Donald Maner wrote: > Hello, everyone. I've been a lurker on fedora-legacy for far too long, and it's time I get involved. > > 1. Name: Donald E. Maner, Jr. Welcome aboard Donald! 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 pekkas at netcore.fi Fri Jun 17 20:20:29 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Jun 2005 23:20:29 +0300 (EEST) Subject: QaTesting wiki page expanded In-Reply-To: References: Message-ID: On Thu, 16 Jun 2005, Pekka Savola wrote: > I've now also updated the Wiki. I also added a new page describing the > status whiteboard tags. > > http://www.fedoralegacy.org/wiki/index.php/QaTesting > http://www.fedoralegacy.org/wiki/index.php/StatusWhiteboard I've also split out the (rather long) QaTesting page to three new pages (so they can be expanded as needed): http://www.fedoralegacy.org/wiki/index.php/QaPublish http://www.fedoralegacy.org/wiki/index.php/QaVerify http://www.fedoralegacy.org/wiki/index.php/QaSubmit In particular, I expanded the QaPublish page, as I saw new folks doing +publish, I thought I should share the "process" I myself use for +publish. Using that, I can do +PUBLISH for all 4 OS versions for a package (if the update is straightforward) in about 10-15 minutes. -- 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 donjr at maner.org Sat Jun 18 03:22:01 2005 From: donjr at maner.org (Donald Maner) Date: Fri, 17 Jun 2005 22:22:01 -0500 Subject: QaTesting wiki page expanded Message-ID: <58DCCC4F6A6E33438329DAD381B41E764DED@aruba.maner.org> On Fri, 17 Jun 2005, Pekka Savola wrote: >I've also split out the (rather long) QaTesting page to three >new pages (so they can be expanded as needed): Thanks. I grabbed the rpm-build-compare script, and if someone else hasn't, I'll hit the FC1 RPMs that I missed. If you watch, I got closer and closer as I re-read the wiki on what the difference between publish and verify votes were :) From marcdeslauriers at videotron.ca Sun Jun 19 15:13:56 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 19 Jun 2005 11:13:56 -0400 Subject: Fedora Legacy Test Update Notification: krb5 Message-ID: <42B58BB4.9070102@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-154276 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154276 2005-06-19 --------------------------------------------------------------------- Name : krb5 Versions : rh7.3: krb5-1.2.4-16.1.legacy Versions : rh9: krb5-1.2.7-38.3.legacy Versions : fc1: krb5-1.3.4-5.3.legacy Summary : Kerberos 5 programs for use on workstations. Description : Kerberos is a network authentication system. The krb5-workstation package contains the basic Kerberos programs (kinit, klist, kdestroy, kpasswd) as well as kerberized versions of Telnet and FTP. If your network uses Kerberos, this package should be installed on every workstation. --------------------------------------------------------------------- Update Information: Updated Kerberos (krb5) packages that correct multiple security issues are now available. Kerberos is a networked authentication system that uses a trusted third party (a KDC) to authenticate clients and servers to each other. Note that some of these issues have already been fixed in Fedora Core 1. Please refer to previous advisories for details. Several buffer overflows were possible for all Kerberos versions up to and including 1.3.3 in the krb5_aname_to_localname library function. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0523 to this issue. Several double-free bugs were found in the Kerberos 5 KDC and libraries. A remote attacker could potentially exploit these flaws to execuate arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0642 and CAN-2004-0643 to these issues. A double-free bug was also found in the krb524 server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0772 to this issue. An infinite loop bug was found in the Kerberos 5 ASN.1 decoder library. A remote attacker may be able to trigger this flaw and cause a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0644 to this issue. A heap based buffer overflow bug was found in the administration library of Kerberos 1.3.5 and earlier. This bug could allow an authenticated remote attacker to execute arbitrary commands on a realm's master Kerberos KDC. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1189 to this issue. Additionally a temporary file bug was found in the Kerberos krb5-send-pr program. It is possible that an attacker could create a temporary file that would allow an arbitrary file to be overwritten which the victim has write access to. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0971 to this issue. The krb5-workstation package includes a Kerberos-aware telnet client. Two buffer overflow flaws were discovered in the way the telnet client handles messages from a server. An attacker may be able to execute arbitrary code on a victim's machine if the victim can be tricked into connecting to a malicious telnet server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-0468 and CAN-2005-0469 to these issues. All users of krb5 should upgrade to these updated packages, which contain backported security patches to resolve these issues. --------------------------------------------------------------------- Changelogs rh73: * Tue Jun 07 2005 Pekka Savola 1.2.4-16.1.legacy - Fix telnet client vulnerabilities from RHEL (#154276) * Sun Mar 06 2005 Marc Deslauriers 1.2.4-16.legacy - Added missing libtool BuildPrereq * Sat Feb 26 2005 Pekka Savola 1.2.4-15.legacy - apply ~all patches from RHEL21 between 1.2.2-24 to -32 (#2040) - don't apply DNS usage patch, as it would be a new feature rh9: * Tue Jun 07 2005 Pekka Savola 1.2.7-38.3.legacy - Fix telnet client vulnerabilities from RHEL (#154276) * Sun Mar 06 2005 Marc Deslauriers 1.2.7-38.2.legacy - Added missing libtool and autoconf213 to BuildPrereq * Sat Feb 26 2005 Pekka Savola 1.2.7-38.1.legacy - Rebuild for Fedora Legacy, to fix a number of bugs (#2040) * Wed Dec 22 2004 Nalin Dahyabhai 1.2.7-38 - add additional hunk to fix for #123031 for xdr encoding/decoding of gssapi buffers (part of #143127) fc1: * Tue Jun 07 2005 Pekka Savola 1.3.4-5.3.legacy - Fix telnet client vulnerabilities from Fedora FC2 CVS (#154276) * Sun Mar 06 2005 Marc Deslauriers 1.3.4-5.2.legacy - Added missing autoconf BuildPrereq * Wed Mar 02 2005 Marc Deslauriers 1.3.4-5.1.legacy - Added security patches for CAN-2004-0971 and CAN-2004-1189 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 4fcc561d7f179fb0672b0f273043c272b790f423 redhat/7.3/updates-testing/i386/krb5-devel-1.2.4-16.1.legacy.i386.rpm 07938a62bd7498733b3e535a381fe18223184eda redhat/7.3/updates-testing/i386/krb5-libs-1.2.4-16.1.legacy.i386.rpm c81a4385ede484d89187d5836d49cacbc5655ee1 redhat/7.3/updates-testing/i386/krb5-server-1.2.4-16.1.legacy.i386.rpm 568b4b641c2b9a54eafd14b4099bc72d49f02137 redhat/7.3/updates-testing/i386/krb5-workstation-1.2.4-16.1.legacy.i386.rpm 4ee83ff2a6f0bd9bdbf0726ba2fd4acf6c5f43cc redhat/7.3/updates-testing/SRPMS/krb5-1.2.4-16.1.legacy.src.rpm rh9: 0111aeb1c5946f18e8a48d1d27d8493c919ca936 redhat/9/updates-testing/i386/krb5-devel-1.2.7-38.3.legacy.i386.rpm 35141598dbb9c60e8cd0b3f06b23528ee526bb46 redhat/9/updates-testing/i386/krb5-libs-1.2.7-38.3.legacy.i386.rpm bcaf771e3de01b16e73327cc3643a2ebd4fda6dd redhat/9/updates-testing/i386/krb5-server-1.2.7-38.3.legacy.i386.rpm 4b4b056d4abc0d69c14e7df45fa3b02e76db48fb redhat/9/updates-testing/i386/krb5-workstation-1.2.7-38.3.legacy.i386.rpm ddc2bdafbecf5801a7238187936fee99966efc65 redhat/9/updates-testing/SRPMS/krb5-1.2.7-38.3.legacy.src.rpm fc1: 389b8b7b2b59b4363f941e22213be5794e3321a0 fedora/1/updates-testing/i386/krb5-devel-1.3.4-5.3.legacy.i386.rpm f0f7a0e7a002751d9ed19d2c573f9b332759ac00 fedora/1/updates-testing/i386/krb5-libs-1.3.4-5.3.legacy.i386.rpm 8d685627a81c1cc51545e8d43db8c3f2acc4a520 fedora/1/updates-testing/i386/krb5-server-1.3.4-5.3.legacy.i386.rpm 9aed15c515e7e319fe880b064ecc595565db6575 fedora/1/updates-testing/i386/krb5-workstation-1.3.4-5.3.legacy.i386.rpm d8f81d57720d1b4c4fc393778f82d7119aeb209c fedora/1/updates-testing/SRPMS/krb5-1.3.4-5.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 Sun Jun 19 15:14:36 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 19 Jun 2005 11:14:36 -0400 Subject: Fedora Legacy Test Update Notification: ImageMagick Message-ID: <42B58BDC.9090602@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-155508 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152777 2005-06-19 --------------------------------------------------------------------- Name : ImageMagick Versions : rh73: ImageMagick-5.4.3.11-11.7.x.legacy Versions : rh9: ImageMagick-5.4.7-17.legacy Versions : fc1: ImageMagick-5.5.6-12.legacy Versions : fc2: ImageMagick-6.2.0.7-2.fc2.3.legacy Summary : An X application for displaying and manipulating images. Description : ImageMagick(TM) is an image display and manipulation tool for the X Window System. ImageMagick can read and write JPEG, TIFF, PNM, GIF, and Photo CD image formats. It can resize, rotate, sharpen, color reduce, or add special effects to an image, and when finished you can either save the completed work in the original format or a different one. ImageMagick also includes command line programs for creating animated or transparent .gifs, creating composite images, creating thumbnail images, and more. --------------------------------------------------------------------- Update Information: Updated ImageMagick packages that fix multiple security vulnerabilities are now available. ImageMagick(TM) is an image display and manipulation tool for the X Window System. A temporary file handling bug has been found in ImageMagick's libmagick library. A local user could overwrite or create files as a different user if a program was linked with the vulnerable library. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0455 to this issue. A heap overflow flaw has been discovered in the ImageMagick image handler. An attacker could create a carefully crafted BMP file in such a way that it could cause ImageMagick to execute arbitrary code when processing the image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0827 to this issue. A buffer overflow flaw was discovered in the ImageMagick image handler. An attacker could create a carefully crafted image file with an improper EXIF information in such a way that it would cause ImageMagick to execute arbitrary code when processing the image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0981 to this issue. Andrei Nigmatulin discovered a heap based buffer overflow flaw in the ImageMagick image handler. An attacker could create a carefully crafted Photoshop Document (PSD) image in such a way that it would cause ImageMagick to execute arbitrary code when processing the image. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0005 to this issue. A format string bug was found in the way ImageMagick handles filenames. An attacker could execute arbitrary code on a victim's machine if they were able to trick the victim into opening a file with a specially crafted name. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0397 to this issue. A bug was found in the way ImageMagick handles TIFF tags. It is possible that a TIFF image file with an invalid tag could cause ImageMagick to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0759 to this issue. A bug was found in ImageMagick's TIFF decoder. It is possible that a specially crafted TIFF image file could cause ImageMagick to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0760 to this issue. A bug was found in the way ImageMagick parses PSD files. It is possible that a specially crafted PSD file could cause ImageMagick to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0761 to this issue. A heap overflow bug was found in ImageMagick's SGI parser. It is possible that an attacker could execute arbitrary code by tricking a user into opening a specially crafted SGI image file. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0762 to this issue. A heap based buffer overflow bug was found in the way ImageMagick parses PNM files. An attacker could execute arbitrary code on a victim's machine if they were able to trick the victim into opening a specially crafted PNM file. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1275 to this issue. A denial of service bug was found in the way ImageMagick parses XWD files. A user or program executing ImageMagick to process a malicious XWD file can cause ImageMagick to enter an infinite loop causing a denial of service condition. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1739 to this issue. Users of ImageMagick should upgrade to these updated packages, which contain backported patches, and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73: * Fri Jun 17 2005 Marc Deslauriers 5.4.3.11-11.7.x.legacy - Added missing libtool, libxml2-devel, XFree85-libs, ghostscript and XFree86-devel to BuildRequires * Thu Jun 09 2005 Marc Deslauriers 5.4.3.11-10.7.x.legacy - Added patch for CAN-2005-1739 * Fri May 06 2005 Marc Deslauriers 5.4.3.11-9.7.x.legacy - Added patches for CAN-2005-0759, CAN-2005-0760, CAN-2005-0761 and CAN-2005-0762 - Added patch to fix a PNM heap overflow (CAN-2005-1275) * Thu Mar 03 2005 Marc Deslauriers 5.4.3.11-8.7.x.legacy - Added better patch for CAN-2005-0005 * Tue Mar 01 2005 Marc Deslauriers 5.4.3.11-7.7.x.legacy - Added patches for CAN-2005-0005 and CAN-2005-0397 - Added htmlview to Requires * Wed Nov 24 2004 Marc Deslauriers 5.4.3.11-6.7.x.legacy - added better patch for CAN-2003-0455 (Michal Jaegermann) * Fri Nov 05 2004 Martin Siegert 5.4.3.11-5.7.x.legacy - set BrowseDelegate=htmlview * Thu Nov 04 2004 Martin Siegert 5.4.3.11-4.7.x.legacy - include patch for CAN-2003-0455 from RHEL ImageMagick-5.3.8-5 - include patch for CAN-2004-0827 - include patch for CAN-2004-0981 from Debian (bug #278401) rh9: * Fri Jun 17 2005 Marc Deslauriers 5.4.7-17.legacy - Added missing libtool, XFree86-devel, XFree86-libs, ghostscript and libxml2-devel BuildRequires * Thu Jun 09 2005 Marc Deslauriers 5.4.7-16.legacy - Added patch for CAN-2005-1739 * Sat May 07 2005 Marc Deslauriers 5.4.7-15.legacy - Added patches for CAN-2005-0759, CAN-2005-0760, CAN-2005-0761 and CAN-2005-0762 - Added patch to fix a PNM heap overflow (CAN-2005-1275) * Thu Mar 03 2005 Marc Deslauriers 5.4.7-14.legacy - Added a better patch for CAN-2005-0005 * Wed Mar 02 2005 Marc Deslauriers 5.4.7-13.legacy - Added patches for CAN-2005-0005 and CAN-2005-0397 * Wed Nov 24 2004 Marc Deslauriers 5.4.7-12.legacy - Added better security patch for CAN-2004-0827 (heap overflow in BMP, AVI, DIB) - Added security patch for CAN-2003-0455 (temporary file vulnerability) - Added security patch for CAN-2004-0981 (Remote EXIF parsing buffer overflow) * Sun Sep 12 2004 Marc Deslauriers 5.4.7-11.legacy - Added security patch for CAN-2004-0827 fc1: * Fri Jun 17 2005 Marc Deslauriers 5.5.6-12.legacy - Added missing libtool, libxml2-devel XFree86-devel and ghostscript to BuildRequires * Fri Jun 10 2005 Marc Deslauriers 5.5.6-11.legacy - Added patch for CAN-2005-1739 * Sat May 07 2005 Marc Deslauriers 5.5.6-10.legacy - Added patches for CAN-2005-0759, CAN-2005-0760, CAN-2005-0761 and CAN-2005-0762 - Added patch to fix a PNM heap overflow (CAN-2005-1275) * Thu Mar 03 2005 Marc Deslauriers 5.5.6-9.legacy - Added better patch for CAN-2005-0005 * Wed Mar 02 2005 Marc Deslauriers 5.5.6-8.legacy - Added patches for CAN-2005-0005 and CAN-2005-0397 * Sat Nov 13 2004 David Eisenstein 5.5.6-7-fc1 - add patch #8 for RedHat Bugzilla #112396, Postscript delegate - patch # 9, CAN-2004-0827 heap overflow in BMP, AVI, DIB decoders - patch #10, CAN-2004-0981 Remote EXIF parsing buffer overflow - Above two patches address Fedora Legacy Bugzilla # 2052 fc2: * Sat Jun 18 2005 Marc Deslauriers 6.2.0.7-2.fc2.3.legacy - Added missing XFree86-devel, libxml2-devel, ghostscript to BuildRequires * Fri Jun 10 2005 Marc Deslauriers 6.2.0.7-2.fc2.2.legacy - Added patch to fix CAN-2005-1739 * Sat May 07 2005 Marc Deslauriers 6.2.0.7-2.fc2.1.legacy - Added patch to fix a PNM heap overflow (CAN-2005-1275) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 89db27a192946e99358dfbd6a9c7f5f1a02495e5 redhat/7.3/updates-testing/i386/ImageMagick-5.4.3.11-11.7.x.legacy.i386.rpm 8ae53bd35eacf50404261b67875a7a35b8708a7d redhat/7.3/updates-testing/i386/ImageMagick-c++-5.4.3.11-11.7.x.legacy.i386.rpm 2f427f1ec11108fb2e1f681feeeb6cbbfa086f33 redhat/7.3/updates-testing/i386/ImageMagick-c++-devel-5.4.3.11-11.7.x.legacy.i386.rpm 2d729c5cb0ec04495f349d7a791ed90381411b17 redhat/7.3/updates-testing/i386/ImageMagick-devel-5.4.3.11-11.7.x.legacy.i386.rpm 5321c7e7a81f7b2d2957be4ddbbeafe96a844a18 redhat/7.3/updates-testing/i386/ImageMagick-perl-5.4.3.11-11.7.x.legacy.i386.rpm aed9756e160c904fcc34bc922203af2daffe59d9 redhat/7.3/updates-testing/SRPMS/ImageMagick-5.4.3.11-11.7.x.legacy.src.rpm rh9: 2dbcdde0aba102e145ef0bc534ca82858fd385a5 redhat/9/updates-testing/i386/ImageMagick-5.4.7-17.legacy.i386.rpm 39707ab761a50586c3e70c23013e83606eae100c redhat/9/updates-testing/i386/ImageMagick-c++-5.4.7-17.legacy.i386.rpm 1f65dade41a5c4974a98b09376ee4669a561bc33 redhat/9/updates-testing/i386/ImageMagick-c++-devel-5.4.7-17.legacy.i386.rpm 82648de206050daf7108b1db2400096b850ddbbc redhat/9/updates-testing/i386/ImageMagick-devel-5.4.7-17.legacy.i386.rpm ed97c25ba1a0bdcbb6d33f6ac4dbbb6ac08cf5cd redhat/9/updates-testing/i386/ImageMagick-perl-5.4.7-17.legacy.i386.rpm 91c016c906cb127cc8aa8836ee9ef22749e0e36b redhat/9/updates-testing/SRPMS/ImageMagick-5.4.7-17.legacy.src.rpm fc1: db1b096a652bd6c1bff52d42d3b9fbbe56a941e4 fedora/1/updates-testing/i386/ImageMagick-5.5.6-12.legacy.i386.rpm a1aa344bcaf5383da213d0cdc04f08d8b868fc32 fedora/1/updates-testing/i386/ImageMagick-c++-5.5.6-12.legacy.i386.rpm fd48f3d55b859262d1d1ce2b3d4c9fde41e4953e fedora/1/updates-testing/i386/ImageMagick-c++-devel-5.5.6-12.legacy.i386.rpm f16f14f29797a264367e55bf24a6ad2628807268 fedora/1/updates-testing/i386/ImageMagick-devel-5.5.6-12.legacy.i386.rpm 947cc0101713e70153cef50ac9d529fa0fa85a60 fedora/1/updates-testing/i386/ImageMagick-perl-5.5.6-12.legacy.i386.rpm 676ff69b50cea82e9590957bd8c1f29eb8dff0bd fedora/1/updates-testing/SRPMS/ImageMagick-5.5.6-12.legacy.src.rpm fc2: a5bd53fae18dcf640f5a46ff769dcee343a5384c fedora/2/updates-testing/i386/ImageMagick-6.2.0.7-2.fc2.3.legacy.i386.rpm 555af3dc174aebbd1c4c815714da55311420a75b fedora/2/updates-testing/i386/ImageMagick-c++-6.2.0.7-2.fc2.3.legacy.i386.rpm 91e23889a512f1c5bc43ee98a970ee68899adb61 fedora/2/updates-testing/i386/ImageMagick-c++-devel-6.2.0.7-2.fc2.3.legacy.i386.rpm e106461910145b26f81cb87dbe9ea25eb903e53f fedora/2/updates-testing/i386/ImageMagick-devel-6.2.0.7-2.fc2.3.legacy.i386.rpm 12e23587f36e5d639c8f24b18101a398d6a3a43e fedora/2/updates-testing/i386/ImageMagick-perl-6.2.0.7-2.fc2.3.legacy.i386.rpm 3ee8913d3ebbe1fc761c14fa74cd09579bc35c35 fedora/2/updates-testing/SRPMS/ImageMagick-6.2.0.7-2.fc2.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 Sun Jun 19 15:14:58 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 19 Jun 2005 11:14:58 -0400 Subject: Fedora Legacy Test Update Notification: xchat Message-ID: <42B58BF2.5010405@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-123013 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123013 2005-06-19 --------------------------------------------------------------------- Name : xchat Versions : fc1: xchat-2.0.7-1.FC1.1.legacy Versions : fc2: xchat-2.0.7-5.1.legacy Summary : A GTK+ IRC (chat) client. Description : X-Chat is an IRC client for the X Window System and GTK+. X-Chat is fairly easy to use and includes a nice interface. --------------------------------------------------------------------- Update Information: X-Chat is a graphical IRC chat client for the X Window System. A stack buffer overflow flaw was found in the X-Chat's Socks-5 proxy code. An attacker could create a malicious Socks-5 proxy server in such a way that X-Chat would execute arbitrary code if a victim configured X-Chat to use the proxy. Users of X-Chat should upgrade to this updated package which contains a backported security patch and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs fc1: * Sat Jun 11 2005 Marc Deslauriers 1:2.0.7-1.FC1.1.legacy - Added patch to fix CAN-2004-0409 fc2: * Mon May 02 2005 Marc Deslauriers 1:2.0.7-5.1.legacy - Added patch to fix CAN-2004-0409 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 949871bada73a7e47b412e04b296fb8e661a6889 fedora/1/updates-testing/i386/xchat-2.0.7-1.FC1.1.legacy.i386.rpm e9defab76a100c3c066b85a9fa83ebcd1527ce71 fedora/1/updates-testing/SRPMS/xchat-2.0.7-1.FC1.1.legacy.src.rpm fc2: 557e51ab8c91c4e824c132b4e58fc372ba6bf4c7 fedora/2/updates-testing/i386/xchat-2.0.7-5.1.legacy.i386.rpm 4e856255dd724c8364556e792c162b1f0fbc29ea fedora/2/updates-testing/SRPMS/xchat-2.0.7-5.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 jasdel49 at comcast.net Sun Jun 19 20:35:25 2005 From: jasdel49 at comcast.net (James R. DeLoach) Date: Sun, 19 Jun 2005 15:35:25 -0500 Subject: YUM Servers Message-ID: <6.2.1.2.2.20050619153345.025cc310@mail.comcast.net> Does anyone have a list of YUM servers that are working that they could post so I can update my yum.conf file? From skvidal at phy.duke.edu Mon Jun 20 03:55:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Jun 2005 23:55:43 -0400 Subject: [Fwd: Re: Summary of FC4 vulnerabilities] In-Reply-To: <1118682505.13606.19.camel@localhost.localdomain> References: <1118682505.13606.19.camel@localhost.localdomain> Message-ID: <1119239743.7160.159.camel@cutter> On Mon, 2005-06-13 at 10:08 -0700, Jesse Keating wrote: > Useful wiki page... > > I'm still working on arranging proper access to the Fedora Project wiki > system for legacy pages. Look for more news on this soon. > Jesse, From last week's talk during the fesco meeting - do you need anything else from me to make the Legacy SubPage hierarchy on the fedoraproject wiki? -sv From jkeating at j2solutions.net Mon Jun 20 06:19:38 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 19 Jun 2005 23:19:38 -0700 Subject: [Fwd: Re: Summary of FC4 vulnerabilities] In-Reply-To: <1119239743.7160.159.camel@cutter> References: <1118682505.13606.19.camel@localhost.localdomain> <1119239743.7160.159.camel@cutter> Message-ID: <1119248378.2778.2.camel@yoda.loki.me> On Sun, 2005-06-19 at 23:55 -0400, seth vidal wrote: > Jesse, > From last week's talk during the fesco meeting - do you need anything > else from me to make the Legacy SubPage hierarchy on the fedoraproject > wiki? No, I'm hoping to get things moving very soon now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From marcdeslauriers at videotron.ca Mon Jun 20 10:41:27 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Jun 2005 06:41:27 -0400 Subject: Fedora Legacy Test Update Notification: grip Message-ID: <42B69D57.4070104@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152919 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152919 2005-06-20 --------------------------------------------------------------------- Name : grip Versions : rh73: grip-2.96-2.2.legacy Versions : rh9: grip-3.0.4-5.2.legacy Versions : fc1: grip-3.0.7-3.2.legacy Summary : A front-end for CD rippers and Ogg Vorbis encoders. Description : Grip is a GTK+ based front-end for CD rippers (such as cdparanoia and cdda2wav) and Ogg Vorbis encoders. Grip allows you to rip entire tracks or just a section of a track. Grip supports the CDDB protocol for accessing track information on disc database servers. --------------------------------------------------------------------- Update Information: A new grip package is available that fixes a remote buffer overflow. Grip is a GTK+ based front-end for CD rippers (such as cdparanoia and cdda2wav) and Ogg Vorbis encoders. Dean Brettle discovered a buffer overflow bug in the way grip handles data returned by CDDB servers. It is possible that if a user connects to a malicious CDDB server, an attacker could execute arbitrary code on the victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0706 to this issue. Users of grip should upgrade to this updated package, which contains a backported patch, and is not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh73: * Sun Jun 19 2005 Marc Deslauriers 2.96-2.2.legacy - Added missing gtk+-devel BuildRequires * Sat Jun 11 2005 Marc Deslauriers 2.96-2.1.legacy - Added patch for CAN-2005-0706 rh9: * Sun Jun 19 2005 Marc Deslauriers 1:3.0.4-5.2.legacy - Added missing gnome-libs-devel, desktop-file-utils and cdparanoia-devel BuildPrereq * Sat Jun 11 2005 Marc Deslauriers 1:3.0.4-5.1.legacy - Added patch for CAN-2005-0706 fc1: * Sun Jun 19 2005 Marc Deslauriers 1:3.0.7-3.2.legacy - Added explicit autoconf213 BuildPrereq - Added missing gnome-libs-devel, desktop-file-utils and cdparanoia-devel to BuildPrereq * Sat Jun 11 2005 Marc Deslauriers 1:3.0.7-3.1.legacy - Added patch for CAN-2005-0706 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: d304e1b6737a081db63277d864729dc75064e8c5 redhat/7.3/updates-testing/i386/grip-2.96-2.2.legacy.i386.rpm e650eb59926bc2778f43f585f5753f9e534dbd39 redhat/7.3/updates-testing/SRPMS/grip-2.96-2.2.legacy.src.rpm rh9: 3d8746899f009548ad85b4ac1c433c2adb900ccb redhat/9/updates-testing/i386/grip-3.0.4-5.2.legacy.i386.rpm 4c7f62387193fd9611f1a18ca670733e5351cb38 redhat/9/updates-testing/SRPMS/grip-3.0.4-5.2.legacy.src.rpm fc1: fb4889f36ad3696857c815100e81fc23cc623479 fedora/1/updates-testing/i386/grip-3.0.7-3.2.legacy.i386.rpm fde89cd9de6717ccd7f42c8f54b33fb5f91d23ad fedora/1/updates-testing/SRPMS/grip-3.0.7-3.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 Mon Jun 20 10:41:56 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Jun 2005 06:41:56 -0400 Subject: Fedora Legacy Test Update Notification: curl Message-ID: <42B69D74.2010203@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152917 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152917 2005-06-20 --------------------------------------------------------------------- Name : curl Versions : rh73: curl-7.9.5-2.2.legacy Versions : rh9: curl-7.9.8-5.2.legacy Versions : fc1: curl-7.10.6-7.2.legacy Versions : fc2: curl-7.11.1-1.2.legacy Summary : A utility for getting files from remote servers Description : cURL is a tool for getting files from FTP, HTTP, Gopher, Telnet, and Dict servers, using any of the supported protocols. cURL is designed to work without user interaction or any kind of interactivity. cURL offers many useful capabilities, like proxy support, user authentication, FTP upload, HTTP post, and file transfer resume. --------------------------------------------------------------------- Update Information: Updated curl packages are now available. cURL is a tool for getting files from FTP, HTTP, Gopher, Telnet, and Dict servers, using any of the supported protocols. cURL is designed to work without user interaction or any kind of interactivity. Multiple buffer overflow bugs were found in the way curl processes base64 encoded replies. If a victim can be tricked into visiting a URL with curl, a malicious web server could execute arbitrary code on a victim's machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0490 to this issue. All users of curl are advised to upgrade to these updated packages, which contain backported fixes for these issues. --------------------------------------------------------------------- Changelogs rh73: * Sun Jun 19 2005 Marc Deslauriers 7.9.5-2.2.legacy - Added missing groff and bison BuildRequires * Sun Jun 12 2005 Marc Deslauriers 7.9.5-2.1.legacy - Added patch for CAN-2005-0490 Multiple stack based buffer overflows in curl rh9: * Sun Jun 19 2005 Marc Deslauriers 7.9.8-5.2.legacy - Added missing zlib-devel, groff and bison BuildRequires * Sun Jun 12 2005 Marc Deslauriers 7.9.8-5.1.legacy - Added patch for CAN-2005-0490 Multiple stack based buffer overflows in curl fc1: * Sun Jun 19 2005 Marc Deslauriers 7.10.6-7.2.legacy - Added missing zlib-devel, groff and bison BuildRequires * Sun Jun 12 2005 Marc Deslauriers 7.10.6-7.1.legacy - Added patch for CAN-2005-0490 Multiple stack based buffer overflows in curl fc2: * Sun Jun 19 2005 Marc Deslauriers 7.11.1-1.2.legacy - Added missing zlib-devel, groff, bison BuildRequires * Sun Jun 12 2005 Marc Deslauriers 7.11.1-1.1.legacy - Added patch for CAN-2005-0490 Multiple stack based buffer overflows in curl --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 8032bf94d434873de3f02100fd8eb36b206cba02 redhat/7.3/updates-testing/i386/curl-7.9.5-2.2.legacy.i386.rpm 2d95c39024f58f3a7897e58da3da39dd297c8109 redhat/7.3/updates-testing/i386/curl-devel-7.9.5-2.2.legacy.i386.rpm 559d63a957091747972eb963a29642ef7c3835d7 redhat/7.3/updates-testing/SRPMS/curl-7.9.5-2.2.legacy.src.rpm rh9: ca02f070ca45c96cfb93157e88b81f96c4646051 redhat/9/updates-testing/i386/curl-7.9.8-5.2.legacy.i386.rpm 57329416fa302765f25ba963bf9a6d334a225e72 redhat/9/updates-testing/i386/curl-devel-7.9.8-5.2.legacy.i386.rpm e793df5a65927b98203c0308972389cc80896749 redhat/9/updates-testing/SRPMS/curl-7.9.8-5.2.legacy.src.rpm fc1: c083d601e3b6f1c54dede72bb635e0215bb6230b fedora/1/updates-testing/i386/curl-7.10.6-7.2.legacy.i386.rpm 835a427b82413d4ccc83a17dbc0ea0204dfd1e4a fedora/1/updates-testing/i386/curl-devel-7.10.6-7.2.legacy.i386.rpm cb59fc5fd7f74e1e5d407fe6fdd4d086e7f93bac fedora/1/updates-testing/SRPMS/curl-7.10.6-7.2.legacy.src.rpm fc2: c8c23e7748058bd6965efb188fc02fc27bc1f1c1 fedora/2/updates-testing/i386/curl-7.11.1-1.2.legacy.i386.rpm 401b44aeb653730fb6dcc7b83ecb88f9600f64cc fedora/2/updates-testing/i386/curl-devel-7.11.1-1.2.legacy.i386.rpm d0fbc3ee3137034a02cdc136959f7e119daae817 fedora/2/updates-testing/SRPMS/curl-7.11.1-1.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 Mon Jun 20 10:42:19 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Mon, 20 Jun 2005 06:42:19 -0400 Subject: Fedora Legacy Test Update Notification: cpio Message-ID: <42B69D8B.3020501@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152891 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152891 2005-06-20 --------------------------------------------------------------------- Name : cpio Versions : rh9: cpio-2.5-3.2.legacy Versions : fc1: cpio-2.5-5.2.legacy Summary : A GNU archiving program. Description : GNU cpio copies files into or out of a cpio or tar archive. Archives are files which contain a collection of other files plus information about them, such as their file name, owner, timestamps, and access permissions. The archive can be another file on the disk, a magnetic tape, or a pipe. GNU cpio supports the following archive formats: binary, old ASCII, new ASCII, crc, HPUX binary, HPUX old ASCII, old tar, and POSIX.1 tar. --------------------------------------------------------------------- Update Information: An updated cpio package that fixes a umask bug and supports large files (>2GB) is now available. GNU cpio copies files into or out of a cpio or tar archive. It was discovered that cpio uses a 0 umask when creating files using the -O (archive) option. This creates output files with mode 0666 (all can read and write) regardless of the user's umask setting. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-1999-1572 to this issue. All users of cpio should upgrade to this updated package, which resolves this issue, and adds support for large files (> 2GB). --------------------------------------------------------------------- Changelogs rh9: * Sun Jun 19 2005 Marc Deslauriers 2.5-3.2.legacy - Added missing texinfo BuildRequires * Fri Feb 18 2005 Pekka Savola 2.5-3.1.legacy - fix CAN-1999-1572 and add >2GB file support, from RHEL (#2408) fc1: * Sun Jun 19 2005 Marc Deslauriers 2.5-5.2.legacy - Added missing texinfo BuildRequires * Fri Feb 18 2005 Pekka Savola 2.5-5.1.legacy - fix CAN-1999-1572 and add >2GB file support, from RHEL (#2408) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 9f7b398cf0b0259eb983fa3f77aaae4558aa3f81 redhat/9/updates-testing/i386/cpio-2.5-3.2.legacy.i386.rpm afb4f3892398e6a08bb9f8f3016ffe4a33302fdc redhat/9/updates-testing/SRPMS/cpio-2.5-3.2.legacy.src.rpm fc1: 757cee489c9ceb9aa0d8c775a035cfbe5f1f93fe fedora/1/updates-testing/i386/cpio-2.5-5.2.legacy.i386.rpm d78fe3e156c510479e55b52ec284b0ba04704909 fedora/1/updates-testing/SRPMS/cpio-2.5-5.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 akopps at LS.Berkeley.EDU Mon Jun 20 17:01:44 2005 From: akopps at LS.Berkeley.EDU (Akop Pogosian) Date: Mon, 20 Jun 2005 10:01:44 -0700 Subject: mozilla-chat installation error In-Reply-To: <1118175825.6743.5.camel@mdlinux> References: <20050606181528.GA32549@ls.berkeley.edu> <1118090449.24957.5.camel@mdlinux> <20050607163050.GA3702@ls.berkeley.edu> <1118175825.6743.5.camel@mdlinux> Message-ID: <20050620170144.GA17050@ls.berkeley.edu> On Tue, Jun 07, 2005 at 04:23:45PM -0400, Marc Deslauriers wrote: > > > Name : mozilla-chat Relocations: /usr > > Version : 1.7.7 Vendor: (none) > > Release : 1.1.2.legacy Build Date: Tue 31 May 2005 11:28:15 PM PDT > > Install Date: (not installed) Build Host: XXX > > Group : Applications/Internet Source RPM: mozilla-1.7.7-1.1.2.legacy.src.rpm > > Size : 756761 License: MPL/NPL/GPL/LGPL > > Signature : DSA/SHA1, Fri 03 Jun 2005 06:34:43 PM PDT, Key ID 6245d51354a940b0Summary : IRC client integrated with Mozilla. > > Description : > > IRC client that is integrated with the Mozilla Web browser. > > > > Note that I have rebuilt it on an RHEL 3.0 box. The only thing I > > changed in the spec file was the Epoch. Could that somehow cause this > > warning message? > > > > You are installing a mozilla package rebuilt on RHEL3 on FC1? > > I really don't see where the update-desktop-database is coming from as > it is not in the original FC1 package. > > Why don't you just install the legacy built package without rebuilding > it? > > Marc. I wasn't installing it on FC1. I was installing it on RHEL 3 (but it was rebuilt from fedora legacy FC1 mozilla srpm package) -akop From debbiet at arlut.utexas.edu Mon Jun 20 18:06:59 2005 From: debbiet at arlut.utexas.edu (Debbie Tropiano) Date: Mon, 20 Jun 2005 13:06:59 -0500 Subject: Kernel BUG -- FC2 2.6.6 kernel Message-ID: <20050620180659.GA17305@arlut.utexas.edu> Hello - I posted this on the Fedora Forum and someone suggest that I post here. We recently had a Kernel BUG on one of our systems running Fedora Core 2 with the 2.6.6 kernel (since we need to run SNARE we've been staying at that rev). >From looking at the source, it appears that the patch from http://www.ussg.iu.edu/hypermail/linux/kernel/0408.0/0652.html is installed. I've not been able to find anything definitive from a web search, but am wondering what might have caused it and if there is a fix (short of upgrading our kernel). Any ideas? Jun 15 22:58:47 argonaut kernel: ----------- [cut here ] --------- [please bite here ] --------- Jun 15 22:58:47 argonaut kernel: Kernel BUG at balloc:942 Jun 15 22:58:47 argonaut kernel: invalid operand: 0000 [1] SMP Jun 15 22:58:47 argonaut kernel: CPU 1 Jun 15 22:58:47 argonaut kernel: Modules linked in: nls_utf8 udf ppdev 3w_9xxx nfs snd_pcm_oss snd_pcm snd_page_alloc snd_timer snd_mixer_oss snd soundcore nfsd exportfs lockd ipv6 parport_pc lp parport autofs4 ds yenta_socket pcmcia_core sunrpc e100 mii iptable_filter ip_tables tg3 floppy sg joydev dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sata_sil libata sd_mod scsi_mod .... (the rest is in the attachment). Any help would be appreciated. Debbie -- | Debbie Tropiano | debbiet at arlut.utexas.edu | | Environmental Sciences Laboratory | +1 512 835 3367 w | | Applied Research Laboratories of UT Austin | +1 512 835 3544 fax | | P.O. Box 8029, Austin, TX 78713-8029 | home email: debbie at icus.com | -------------- next part -------------- Jun 15 22:58:47 argonaut kernel: ----------- [cut here ] --------- [please bite here ] --------- Jun 15 22:58:47 argonaut kernel: Kernel BUG at balloc:942 Jun 15 22:58:47 argonaut kernel: invalid operand: 0000 [1] SMP Jun 15 22:58:47 argonaut kernel: CPU 1 Jun 15 22:58:47 argonaut kernel: Modules linked in: nls_utf8 udf ppdev 3w_9xxx nfs snd_pcm_oss snd_pcm snd_page_alloc snd_timer snd_mixer_oss snd soundcore nfsd exportfs lockd ipv6 parport_pc lp parport autofs4 ds yenta_socket pcmcia_core sunrpc e100 mii iptable_filter ip_tables tg3 floppy sg joydev dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sata_sil libata sd_mod scsi_mod Jun 15 22:58:47 argonaut kernel: Pid: 2274, comm: nfsd Not tainted 2.6.6-1.435.2.3SNARE096bsmp Jun 15 22:58:48 argonaut kernel: RIP: 0010:[] {:ext3:ext3_try_to_allocate_with_rsv+319} Jun 15 22:58:48 argonaut kernel: RSP: 0018:00000100f3c9f5c8 EFLAGS: 00010287 Jun 15 22:58:48 argonaut kernel: RAX: 0000000000000000 RBX: 0000000000a68000 RCX: 0000000000008000 Jun 15 22:58:48 argonaut kernel: RDX: 0000000000a70000 RSI: 0000000000a68a6e RDI: 00000100f1385520 Jun 15 22:58:48 argonaut kernel: RBP: 00000100f1385520 R08: 0000000000000a76 R09: 00000100f1385520 Jun 15 22:58:48 argonaut kernel: R10: 00000100e702b9a0 R11: 00000100e702b9a0 R12: 0000000000000000 Jun 15 22:58:48 argonaut kernel: R13: 0000000000000a76 R14: 00000100faf9a800 R15: 00000100d4201380 Jun 15 22:58:48 argonaut kernel: FS: 0000002a958624c0(0000) GS:ffffffff8049bb80(0000) knlGS:00000000556dd300 Jun 15 22:58:48 argonaut kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 15 22:58:48 argonaut kernel: CR2: 0000002a9595ecc8 CR3: 000000017ffb2000 CR4: 00000000000006e0 Jun 15 22:58:48 argonaut kernel: Process nfsd (pid: 2274, threadinfo 00000100f3c9e000, task 00000100f3df94d0) Jun 15 22:58:48 argonaut kernel: Stack: 0000000000001000 000001017d815100 0000014de702b9a0 0000010130ed98b0 Jun 15 22:58:48 argonaut kernel: 0000000000000000 0000000000000a76 00000100f3c9f7c0 00000100faf9a800 Jun 15 22:58:48 argonaut kernel: 000000000000014d 0000000000a68a76 Jun 15 22:58:48 argonaut kernel: Call Trace:{:ext3:ext3_new_block+501} {:ext3:ext3_alloc_block+7} Jun 15 22:58:48 argonaut kernel: {:ext3:ext3_alloc_branch+85} {:ext3:ext3_get_block_handle+520} Jun 15 22:58:48 argonaut kernel: {__block_prepare_write+332} {:ext3:ext3_get_block+0} Jun 15 22:58:48 argonaut kernel: {block_prepare_write+26} {:ext3:ext3_prepare_write+95} Jun 15 22:58:48 argonaut kernel: {generic_file_aio_write_nolock+1307} Jun 15 22:58:48 argonaut kernel: {:sunrpc:svc_tcp_data_ready+61} {tcp_rcv_established+1160} Jun 15 22:58:48 argonaut kernel: {tcp_v4_do_rcv+37} {generic_file_write_nolock+87} Jun 15 22:58:48 argonaut kernel: {tcp_recvmsg+1780} {inet_recvmsg+48} Jun 15 22:58:48 argonaut kernel: {dst_output+22} {sock_recvmsg+171} Jun 15 22:58:48 argonaut kernel: {:nfsd:exp_find_key+118} {generic_file_writev+51} Jun 15 22:58:48 argonaut kernel: {generic_file_writev+0} {do_readv_writev+388} Jun 15 22:58:48 argonaut kernel: {do_sync_write+0} {:nfsd:fh_verify+1324} Jun 15 22:58:48 argonaut kernel: {open_private_file+181} {:nfsd:nfsd_open+268} Jun 15 22:58:48 argonaut kernel: {:nfsd:nfsd_write+297} {:sunrpc:svc_sock_enqueue+570} Jun 15 22:58:48 argonaut kernel: {:sunrpc:svc_tcp_recvfrom+942} {:sunrpc:svcauth_unix_accept+558} Jun 15 22:58:48 argonaut kernel: {:nfsd:nfsd3_proc_write+231} {:nfsd:nfsd_dispatch+226} Jun 15 22:58:48 argonaut kernel: {:sunrpc:svc_process+931} {:nfsd:nfsd+0} Jun 15 22:58:48 argonaut kernel: {:nfsd:nfsd+561} {schedule_tail+12} Jun 15 22:58:48 argonaut kernel: {child_rip+8} {:nfsd:nfsd+0} Jun 15 22:58:48 argonaut kernel: {:nfsd:nfsd+0} {child_rip+0} Jun 15 22:58:48 argonaut kernel: Jun 15 22:58:48 argonaut kernel: Jun 15 22:58:48 argonaut kernel: Code: 0f 0b de 91 05 a0 ff ff ff ff ae 03 8b 54 24 14 48 8b 74 24 Jun 15 22:58:48 argonaut kernel: RIP {:ext3:ext3_try_to_allocate_with_rsv+319} RSP <00000100f3c9f5c8> From rob.myers at gtri.gatech.edu Mon Jun 20 20:24:07 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Mon, 20 Jun 2005 16:24:07 -0400 Subject: Kernel BUG -- FC2 2.6.6 kernel In-Reply-To: <20050620180659.GA17305@arlut.utexas.edu> References: <20050620180659.GA17305@arlut.utexas.edu> Message-ID: <1119299047.9842.84.camel@rXm-581b.stl.gtri.gatech.edu> On Mon, 2005-06-20 at 13:06 -0500, Debbie Tropiano wrote: > Hello - > > I posted this on the Fedora Forum and someone suggest that I post here. > > We recently had a Kernel BUG on one of our systems running Fedora Core 2 with > the 2.6.6 kernel (since we need to run SNARE we've been staying at that rev). sounds painful. it is possible that FC4 may incorporate auditing functionality similar to that of SNARE once the auditing subsystem is accepted upstream and all the bugs are shaken out of it. i know that does not help you now, but it may be worth keeping an eye on FC4 just in case... best of luck rob. > >From looking at the source, it appears that the patch from > http://www.ussg.iu.edu/hypermail/linux/kernel/0408.0/0652.html > is installed. I've not been able to find anything definitive from a web search, > but am wondering what might have caused it and if there is a fix (short of > upgrading our kernel). Any ideas? > > Jun 15 22:58:47 argonaut kernel: ----------- [cut here ] --------- [please bite here ] --------- > Jun 15 22:58:47 argonaut kernel: Kernel BUG at balloc:942 > Jun 15 22:58:47 argonaut kernel: invalid operand: 0000 [1] SMP > Jun 15 22:58:47 argonaut kernel: CPU 1 > Jun 15 22:58:47 argonaut kernel: Modules linked in: nls_utf8 udf ppdev 3w_9xxx nfs snd_pcm_oss snd_pcm snd_page_alloc snd_timer snd_mixer_oss snd soundcore nfsd exportfs lockd ipv6 parport_pc lp parport autofs4 ds yenta_socket pcmcia_core sunrpc e100 mii iptable_filter ip_tables tg3 floppy sg joydev dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sata_sil libata sd_mod scsi_mod > .... > > (the rest is in the attachment). > > Any help would be appreciated. > > Debbie > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From gene.heskett at verizon.net Wed Jun 22 11:22:00 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 22 Jun 2005 07:22:00 -0400 Subject: Yum did it again Message-ID: <200506220722.00263.gene.heskett@verizon.net> Greetings; I just followed the instructions on the legacy web page on howto setup yum to use the legacy repos. I have some stuff built from tarballs, like bleeding edge kernels cups, gimp etc, so those got added to the exclude line. Unforch, I forgot about the libxml2 stuffs. So, after yum had updated several dozen packages including libxlm2, I'm back to square one with this error: root at coyote dlds-rpms]# yum check-update Traceback (most recent call last): File "/usr/bin/yum", line 22, in ? import yummain File "/usr/share/yum/yummain.py", line 31, in ? import yumcomps File "/usr/share/yum/yumcomps.py", line 4, in ? import comps File "/usr/share/yum/comps.py", line 5, in ? import libxml2 File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in ? import libxml2mod ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: undefined symbol: xmlNewDocPI Obviously I'm missing a point here because historically I have had to forceably reinstall the older versions of libxml2 here several times before to get yum to work again. So what is this point I'm missing? I really would like to be able to use yum, but the constant libxml2 problems are making it impossible to use without an exclude line that includes libxml2*. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 skvidal at phy.duke.edu Wed Jun 22 12:16:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Jun 2005 08:16:22 -0400 Subject: Yum did it again In-Reply-To: <200506220722.00263.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> Message-ID: <1119442582.3031.64.camel@cutter> On Wed, 2005-06-22 at 07:22 -0400, Gene Heskett wrote: > Greetings; > > I just followed the instructions on the legacy web page on howto setup yum to use the legacy repos. > > I have some stuff built from tarballs, like bleeding edge kernels cups, gimp etc, so those got added to the exclude line. > > Unforch, I forgot about the libxml2 stuffs. So, after yum had updated > several dozen packages including libxlm2, I'm back to square one with > this error: > root at coyote dlds-rpms]# yum check-update > Traceback (most recent call last): > File "/usr/bin/yum", line 22, in ? > import yummain > File "/usr/share/yum/yummain.py", line 31, in ? > import yumcomps > File "/usr/share/yum/yumcomps.py", line 4, in ? > import comps > File "/usr/share/yum/comps.py", line 5, in ? > import libxml2 > File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in ? > import libxml2mod > ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: undefined symbol: xmlNewDocPI > > Obviously I'm missing a point here because historically I have had to > forceably reinstall the older versions of libxml2 here several times > before to get yum to work again. > > So what is this point I'm missing? > > I really would like to be able to use yum, but the constant libxml2 > problems are making it impossible to use without an exclude line > that includes libxml2*. what version of fedora? what version of yum? what version of libxml2 and libxml2-python are installed? -sv From gene.heskett at verizon.net Wed Jun 22 12:37:30 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 22 Jun 2005 08:37:30 -0400 Subject: Yum did it again In-Reply-To: <1119442582.3031.64.camel@cutter> References: <200506220722.00263.gene.heskett@verizon.net> <1119442582.3031.64.camel@cutter> Message-ID: <200506220837.30177.gene.heskett@verizon.net> On Wednesday 22 June 2005 08:16, seth vidal wrote: >On Wed, 2005-06-22 at 07:22 -0400, Gene Heskett wrote: >> Greetings; >> >> I just followed the instructions on the legacy web page on howto >> setup yum to use the legacy repos. >> >> I have some stuff built from tarballs, like bleeding edge kernels >> cups, gimp etc, so those got added to the exclude line. >> >> Unforch, I forgot about the libxml2 stuffs. So, after yum had >> updated several dozen packages including libxlm2, I'm back to >> square one with this error: >> root at coyote dlds-rpms]# yum check-update >> Traceback (most recent call last): >> File "/usr/bin/yum", line 22, in ? >> import yummain >> File "/usr/share/yum/yummain.py", line 31, in ? >> import yumcomps >> File "/usr/share/yum/yumcomps.py", line 4, in ? >> import comps >> File "/usr/share/yum/comps.py", line 5, in ? >> import libxml2 >> File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in ? >> import libxml2mod >> ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: >> undefined symbol: xmlNewDocPI >> >> Obviously I'm missing a po/usr/dlds-rpms/libxml2-python-2.6.10-1.1.fc2.nr.i386.rpmint here because historically I have had >> to forceably reinstall the older versions of libxml2 here several >> times before to get yum to work again. >> >> So what is this point I'm missing? >> >> I really would like to be able to use yum, but the constant >> libxml2 problems are making it impossible to use without an >> exclude line that includes libxml2*. > >what version of fedora? FC2 with lots of updates via tarball builds, but that should not be related, I've (up till now) been carefull not to touch the yum/python/libxml2 stuffs after getting burnt previously. >what version of yum? yum-2.0.7-1.1 >what version of libxml2 and libxml2-python are installed? libxml2-python-2.6.16-2 libxml2-devel-2.6.10-1.1.fc2.nr libxml2-2.6.16-2 I've since tried to re-install the 2.6.10-1.1 stuffs but apparently failed. It was yum that upgraded it all to 2.6.16-2 this morning. There are pieces of python-1.5, 2.2, and 2.3 installed here. Its been that way since I upgraded RH7.3 to FC2. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 Jun 22 17:09:01 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 22 Jun 2005 13:09:01 -0400 Subject: Yum did it again In-Reply-To: <200506220837.30177.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <1119442582.3031.64.camel@cutter> <200506220837.30177.gene.heskett@verizon.net> Message-ID: <200506221309.01683.gene.heskett@verizon.net> On Wednesday 22 June 2005 08:37, Gene Heskett wrote: >On Wednesday 22 June 2005 08:16, seth vidal wrote: >>On Wed, 2005-06-22 at 07:22 -0400, Gene Heskett wrote: >>> Greetings; >>> >>> I just followed the instructions on the legacy web page on howto >>> setup yum to use the legacy repos. >>> >>> I have some stuff built from tarballs, like bleeding edge kernels >>> cups, gimp etc, so those got added to the exclude line. >>> >>> Unforch, I forgot about the libxml2 stuffs. So, after yum had >>> updated several dozen packages including libxlm2, I'm back to >>> square one with this error: >>> root at coyote dlds-rpms]# yum check-update >>> Traceback (most recent call last): >>> File "/usr/bin/yum", line 22, in ? >>> import yummain >>> File "/usr/share/yum/yummain.py", line 31, in ? >>> import yumcomps >>> File "/usr/share/yum/yumcomps.py", line 4, in ? >>> import comps >>> File "/usr/share/yum/comps.py", line 5, in ? >>> import libxml2 >>> File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in >>> ? import libxml2mod >>> ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: >>> undefined symbol: xmlNewDocPI >>> >>> Obviously I'm missing a point here because historically I have had >>> to forceably reinstall the older versions of libxml2 here several >>> times before to get yum to work again. Fixed the above paragraph to match what I thought I typed. Does it now make sense? >>> So what is this point I'm missing? >>> >>> I really would like to be able to use yum, but the constant >>> libxml2 problems are making it impossible to use without an >>> exclude line that includes libxml2*. >> >>what version of fedora? > >FC2 with lots of updates via tarball builds, but that should not be >related, I've (up till now) been carefull not to touch the >yum/python/libxml2 stuffs after getting burnt previously. > >>what version of yum? > >yum-2.0.7-1.1 > >>what version of libxml2 and libxml2-python are installed? > >libxml2-python-2.6.16-2 >libxml2-devel-2.6.10-1.1.fc2.nr >libxml2-2.6.16-2 > >I've since tried to re-install the 2.6.10-1.1 stuffs but apparently >failed. It was yum that upgraded it all to 2.6.16-2 this morning. > >There are pieces of python-1.5, 2.2, and 2.3 installed here. Its > been that way since I upgraded RH7.3 to FC2. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 skvidal at phy.duke.edu Thu Jun 23 04:31:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 23 Jun 2005 00:31:33 -0400 Subject: Yum did it again In-Reply-To: <200506220837.30177.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <1119442582.3031.64.camel@cutter> <200506220837.30177.gene.heskett@verizon.net> Message-ID: <1119501094.12146.16.camel@cutter> > >> Obviously I'm missing a > po/usr/dlds-rpms/libxml2-python-2.6.10-1.1.fc2.nr.i386.rpmint here > because historically I have had > >> to forceably reinstall the older versions of libxml2 here several > >> times before to get yum to work again. > >> where did you get this package from? > FC2 with lots of updates via tarball builds, but that should not be > related, I've (up till now) been carefull not to touch the > yum/python/libxml2 stuffs after getting burnt previously. updates via tarballs is a really bad idea. > >what version of yum? > > yum-2.0.7-1.1 > > >what version of libxml2 and libxml2-python are installed? > > libxml2-python-2.6.16-2 > libxml2-devel-2.6.10-1.1.fc2.nr > libxml2-2.6.16-2 does it strike you as alarming that those 3 don't all match? > I've since tried to re-install the 2.6.10-1.1 stuffs but apparently > failed. It was yum that upgraded it all to 2.6.16-2 this morning. so then yum is working? > There are pieces of python-1.5, 2.2, and 2.3 installed here. Its been > that way since I upgraded RH7.3 to FC2. I'd like to show you to: http://torrent.fedoraproject.org go download an install disk and fix your system. -sv From gene.heskett at verizon.net Thu Jun 23 09:31:40 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 05:31:40 -0400 Subject: Yum did it again In-Reply-To: <1119501094.12146.16.camel@cutter> References: <200506220722.00263.gene.heskett@verizon.net> <200506220837.30177.gene.heskett@verizon.net> <1119501094.12146.16.camel@cutter> Message-ID: <200506230531.40327.gene.heskett@verizon.net> On Thursday 23 June 2005 00:31, seth vidal wrote: >> >> Obviously I'm missing a >> >> point here >> because historically I have had >> >> >> to forceably reinstall the older versions of libxml2 here >> >> several times before to get yum to work again. > >where did you get this package from? Usually by going back to the FC2 install disks and forceably overwriting the so-called updated version that broke everything. Yum is not the only casualty, lots of other stuff that uses libxml2 is now similarly broken. But I binned the FC2 disks to make room for the FC4's in my traveling cdrom kit last week when FC4 came out. >> FC2 with lots of updates via tarball builds, but that should not >> be related, I've (up till now) been carefull not to touch the >> yum/python/libxml2 stuffs after getting burnt previously. > >updates via tarballs is a really bad idea. That depends on whether or not you want a working system. I did, I built this box to use it. FC2 shipped with a broken version of cups that crashed and killed most of kde on any attempt to print from a kde app, including so innocent an act as just hovering the mouse pointer over the kde print manager line in the K-Menu popup. I squawked a couple of times at the time and then started building newer versions of kde with konstruct, currently at 3.3.0, which did not fix it, finally discovering a line that was a clue in the cups logs 6 months later. So I ripped out the cups rpms and started building cups, gimp, and gimp-print (now gutenprint) from tarballs. It all worked, no more crashes. But because I like kde and not gnome, fixing that problem resulted in my not being able to use my printer from anything but the gimp for several months. Fixing a problem perceived as a kde problem simply wasn't a very high priority to the RH/Fedora people. I've no idea if a cups update from fedora has ever addressed that "kde" problem. I put cups* in my exclude line to join several others I didn't want touched, but when I copy/pasted the new yum.conf, I forgot to grab that line from the older one. My bad, and now I'm broken. >> >what version of yum? >> >> yum-2.0.7-1.1 >> >> >what version of libxml2 and libxml2-python are installed? >> >> libxml2-python-2.6.16-2 >> libxml2-devel-2.6.10-1.1.fc2.nr >> libxml2-2.6.16-2 > >does it strike you as alarming that those 3 don't all match? No, the miss-match is in the devel file and shouldn't bother yum/python unless I start compileing them from scratch. >> I've since tried to re-install the 2.6.10-1.1 stuffs but >> apparently failed. It was yum that upgraded it all to 2.6.16-2 >> this morning. > >so then yum is working? > No yum is not working, the updateing of the libxml2 stuffs from the 2.6.10's that I did have installed, to the 2.6.16 stuffs, done by yum as part of a roughly 50 package update day before yesterday, killed yum. The next time it was invoked, this is what falls out: ----------- [root at coyote BOINC]# yum check-updates Traceback (most recent call last): File "/usr/bin/yum", line 22, in ? import yummain File "/usr/share/yum/yummain.py", line 31, in ? import yumcomps File "/usr/share/yum/yumcomps.py", line 4, in ? import comps File "/usr/share/yum/comps.py", line 5, in ? import libxml2 File "/usr/lib/python2.3/site-packages/libxml2.py", line 1, in ? import libxml2mod ImportError: /usr/lib/python2.3/site-packages/libxml2mod.so: undefined symbol: xmlNewDocPI ------------- For some reason, I'm having a hard time expressing that running yum broke yum. But this is now the 4th time this has happened since I upgraded to FC2. I just checked, I still have the FC2 iso's so I could burn another set and use those to recover to the FC2 release level of yum/python/libxml2. Humm, they can be mounted but I don't recall the syntax. It involves using the loop device I think... >> There are pieces of python-1.5, 2.2, and 2.3 installed here. Its >> been that way since I upgraded RH7.3 to FC2. > >I'd like to show you to: >http://torrent.fedoraproject.org > >go download an install disk and fix your system. > >-sv I have not been able to get a torrent to work thru my home network Seth, which is locked down by iptables running between 2 nics in my firewall box. And questions about how to cut holes in the iptable rules to allow a torrent, which needs 2 way comm, thru it have gone unanswered on several lists. I think I do have suitable rules setup in my router, a Linksys BEFSR41 & all I have to do there is enable them. Unforch a tracker has never been able to connect. I'm beginning to think I'd have to setup a third nic in the firewall box, and setup a DMZ in the router, and run the torrent in a sandbox on the firewall, but I do not have the networking expertise to set that up safely. Also, the router does NAT, so everything on this side of the router has a 192.168.x.x address. Its pretty tight, portsentry and iptables between them have logged 3 attempts to access my setup in a bit over 2 years, with 2 of those attacks coming from a compromised verizon dns, and I'm on verizon adsl. I send verizon a nastygram, clean out my hosts.deny file and I have working dns again. Till they shut it down the next day for several hours to re-image their server. In the meantime I do know how to run mozilla, wget, gftp & the rest of the file fetching utilities. So what rpms do I now need to either update the python stuffs to be compatible with this new libxml2 stuff, or to downgrade the libxml2 stuffs to regain python compatibility? I do have FC4 final downloaded and on cd's & ready to go, but after the debacle in getting FC2 to actually do work here, my first install of FC4 is going to be an upgrade on a sacrificial FC3T4 box, not on this, my 99% working box. Or are the rpms on the FC4 disks compatible with my version of rpm? Historically not... Another odd thing, when it did the update of about 50 packages from the legacy repo's, it did NOT store the downloaded rpms in /var/cache/yum, the new directories it made are empty so I cannot even reinstall the newer stuff. That also seems strange. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 stickster at gmail.com Thu Jun 23 12:09:29 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 23 Jun 2005 08:09:29 -0400 Subject: Yum did it again In-Reply-To: <200506230531.40327.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506220837.30177.gene.heskett@verizon.net> <1119501094.12146.16.camel@cutter> <200506230531.40327.gene.heskett@verizon.net> Message-ID: <1119528569.2878.28.camel@localhost.localdomain> On Thu, 2005-06-23 at 05:31 -0400, Gene Heskett wrote: [...snip...] > >> >what version of yum? > >> > >> yum-2.0.7-1.1 > >> > >> >what version of libxml2 and libxml2-python are installed? > >> > >> libxml2-python-2.6.16-2 > >> libxml2-devel-2.6.10-1.1.fc2.nr > >> libxml2-2.6.16-2 > > > >does it strike you as alarming that those 3 don't all match? > > No, the miss-match is in the devel file and shouldn't bother > yum/python unless I start compileing them from scratch. I think what Seth may have been alluding to, although I certainly don't mean to put words in his mouth, is that if these don't match, it's an indicator that you may be using some incorrect methodologies while doing all this rpm mixing and matching. IIRC, most people agree that "--force" is bad, unless you *absolutely* know what you're doing. I don't see how you could have ended up with such a mismatch, without using either "--force," or a really poorly spec'd RPM from a non-authoritative source. It would be pointless for me to continue (thus betraying more ignorance on my part) given that Seth is already on the thread. :-) Moving on... [...snip...] > I just checked, I still have the FC2 iso's so I could burn another set > and use those to recover to the FC2 release level of > yum/python/libxml2. Humm, they can be mounted but I don't recall the > syntax. It involves using the loop device I think... You're still thinking about this the wrong way. Rather than try and haphazardly rescue a borked system which is preventing you from doing meaningful troubleshooting, why not take this chance to install (*NOT* upgrade to) FC4 instead? Given the pace of Fedora, you're more likely to get help with any residual yum problems -- if indeed you have any after installation, which I haven't -- if you're using the stuff that's not a year old. :-) > >> There are pieces of python-1.5, 2.2, and 2.3 installed here. Its > >> been that way since I upgraded RH7.3 to FC2. > > > >I'd like to show you to: > >http://torrent.fedoraproject.org > > > >go download an install disk and fix your system. Disco! > So what rpms do I now need to either update the python stuffs to be > compatible with this new libxml2 stuff, or to downgrade the libxml2 > stuffs to regain python compatibility? > > I do have FC4 final downloaded and on cd's & ready to go, but after > the debacle in getting FC2 to actually do work here, my first install > of FC4 is going to be an upgrade on a sacrificial FC3T4 box, not on > this, my 99% working box. Or are the rpms on the FC4 disks > compatible with my version of rpm? Historically not... Argh! It seems you don't understand that upgrading any "test" version to a final version is *NEVER* a recommended option. If it's a sacrificial box, as you say, then do an installation *from scratch*, not an upgrade. Once you have that done, and you see the results and like them -- which I bet you will, since I'm using FC4 myself -- take Seth's advice and *install* FC4 onto your "real" system. Not an upgrade, not a mix-and-match of RPMs (especially since "--force" is not your friend), but an actual installation. If, by some chance, you need help or advice on that process, consult fedora-list since the developers on this list are focused on discussing what's broken, working, or coming up next for the latest and greatest Fedora stuff. Hopefully I haven't annoyed any of said developers by pitching in on this thread; I just thought it would save them some time and energy they could devote to cool Fedora bits. Not to sound sycophantic, but in case any of them are still reading, FC4 rocks hard. And Seth, I used to be an up2date die-hard, but I'm now a yum convert. The yum-utils are superb; I can't wait for pup. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 stickster at gmail.com Thu Jun 23 12:13:13 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 23 Jun 2005 08:13:13 -0400 Subject: Yum did it again In-Reply-To: <1119528569.2878.28.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <200506220837.30177.gene.heskett@verizon.net> <1119501094.12146.16.camel@cutter> <200506230531.40327.gene.heskett@verizon.net> <1119528569.2878.28.camel@localhost.localdomain> Message-ID: <1119528793.2878.32.camel@localhost.localdomain> On Thu, 2005-06-23 at 08:09 -0400, Paul W. Frields wrote: > On Thu, 2005-06-23 at 05:31 -0400, Gene Heskett wrote: > [...snip...] > > >> >what version of yum? > > >> > > >> yum-2.0.7-1.1 > > >> > > >> >what version of libxml2 and libxml2-python are installed? > > >> > > >> libxml2-python-2.6.16-2 > > >> libxml2-devel-2.6.10-1.1.fc2.nr > > >> libxml2-2.6.16-2 > > > > > >does it strike you as alarming that those 3 don't all match? > > > > No, the miss-match is in the devel file and shouldn't bother > > yum/python unless I start compileing them from scratch. > > I think what Seth may have been alluding to, although I certainly don't > mean to put words in his mouth, is that if these don't match, it's an > indicator that you may be using some incorrect methodologies while doing > all this rpm mixing and matching. IIRC, most people agree that > "--force" is bad, unless you *absolutely* know what you're doing. I > don't see how you could have ended up with such a mismatch, without > using either "--force," or a really poorly spec'd RPM from a > non-authoritative source. It would be pointless for me to continue > (thus betraying more ignorance on my part) given that Seth is already on > the thread. :-) Moving on... > > [...snip...] > > I just checked, I still have the FC2 iso's so I could burn another set > > and use those to recover to the FC2 release level of > > yum/python/libxml2. Humm, they can be mounted but I don't recall the > > syntax. It involves using the loop device I think... > > You're still thinking about this the wrong way. Rather than try and > haphazardly rescue a borked system which is preventing you from doing > meaningful troubleshooting, why not take this chance to install (*NOT* > upgrade to) FC4 instead? Given the pace of Fedora, you're more likely > to get help with any residual yum problems -- if indeed you have any > after installation, which I haven't -- if you're using the stuff that's > not a year old. :-) > > > >> There are pieces of python-1.5, 2.2, and 2.3 installed here. Its > > >> been that way since I upgraded RH7.3 to FC2. > > > > > >I'd like to show you to: > > >http://torrent.fedoraproject.org > > > > > >go download an install disk and fix your system. > > Disco! > > > So what rpms do I now need to either update the python stuffs to be > > compatible with this new libxml2 stuff, or to downgrade the libxml2 > > stuffs to regain python compatibility? > > > > I do have FC4 final downloaded and on cd's & ready to go, but after > > the debacle in getting FC2 to actually do work here, my first install > > of FC4 is going to be an upgrade on a sacrificial FC3T4 box, not on > > this, my 99% working box. Or are the rpms on the FC4 disks > > compatible with my version of rpm? Historically not... > > Argh! It seems you don't understand that upgrading any "test" version > to a final version is *NEVER* a recommended option. If it's a > sacrificial box, as you say, then do an installation *from scratch*, not > an upgrade. Once you have that done, and you see the results and like > them -- which I bet you will, since I'm using FC4 myself -- take Seth's > advice and *install* FC4 onto your "real" system. Not an upgrade, not a > mix-and-match of RPMs (especially since "--force" is not your friend), > but an actual installation. If, by some chance, you need help or advice > on that process, consult fedora-list since the developers on this list > are focused on discussing what's broken, working, or coming up next for > the latest and greatest Fedora stuff. > > Hopefully I haven't annoyed any of said developers by pitching in on > this thread; I just thought it would save them some time and energy they > could devote to cool Fedora bits. Not to sound sycophantic, but in case > any of them are still reading, FC4 rocks hard. And Seth, I used to be > an up2date die-hard, but I'm now a yum convert. The yum-utils are > superb; I can't wait for pup. ;-) Whoops, I hate to reply to myself, but I realized after replying that this was on fedora-legacy-list and not fedora-devel-list. (See earlier comment re: my ignorance, QED.) Bend the foregoing comments into shape appropriately. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Thu Jun 23 13:16:58 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 09:16:58 -0400 Subject: Yum did it again In-Reply-To: <1119528569.2878.28.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <200506230531.40327.gene.heskett@verizon.net> <1119528569.2878.28.camel@localhost.localdomain> Message-ID: <200506230916.58219.gene.heskett@verizon.net> On Thursday 23 June 2005 08:09, Paul W. Frields wrote: >On Thu, 2005-06-23 at 05:31 -0400, Gene Heskett wrote: >[...snip...] > >> >> >what version of yum? >> >> >> >> yum-2.0.7-1.1 >> >> >> >> >what version of libxml2 and libxml2-python are installed? >> >> >> >> libxml2-python-2.6.16-2 >> >> libxml2-devel-2.6.10-1.1.fc2.nr >> >> libxml2-2.6.16-2 >> > >> >does it strike you as alarming that those 3 don't all match? >> >> No, the miss-match is in the devel file and shouldn't bother >> yum/python unless I start compileing them from scratch. > >I think what Seth may have been alluding to, although I certainly > don't mean to put words in his mouth, is that if these don't match, > it's an indicator that you may be using some incorrect > methodologies while doing all this rpm mixing and matching. IIRC, > most people agree that "--force" is bad, unless you *absolutely* > know what you're doing. I don't see how you could have ended up > with such a mismatch, without using either "--force," or a really > poorly spec'd RPM from a non-authoritative source. It would be > pointless for me to continue (thus betraying more ignorance on my > part) given that Seth is already on the thread. :-) Moving on... Yup --force --nodeps >[...snip...] > >> I just checked, I still have the FC2 iso's so I could burn another >> set and use those to recover to the FC2 release level of >> yum/python/libxml2. Humm, they can be mounted but I don't recall >> the syntax. It involves using the loop device I think... > >You're still thinking about this the wrong way. Rather than try and >haphazardly rescue a borked system which is preventing you from > doing meaningful troubleshooting, why not take this chance to > install (*NOT* upgrade to) FC4 instead? Given the pace of Fedora, > you're more likely to get help with any residual yum problems -- if > indeed you have any after installation, which I haven't -- if > you're using the stuff that's not a year old. :-) > >> >> There are pieces of python-1.5, 2.2, and 2.3 installed here. >> >> Its been that way since I upgraded RH7.3 to FC2. >> > >> >I'd like to show you to: >> >http://torrent.fedoraproject.org >> > >> >go download an install disk and fix your system. > >Disco! > >> So what rpms do I now need to either update the python stuffs to >> be compatible with this new libxml2 stuff, or to downgrade the >> libxml2 stuffs to regain python compatibility? >> >> I do have FC4 final downloaded and on cd's & ready to go, but >> after the debacle in getting FC2 to actually do work here, my >> first install of FC4 is going to be an upgrade on a sacrificial >> FC3T4 box, not on this, my 99% working box. Or are the rpms on >> the FC4 disks compatible with my version of rpm? Historically >> not... > >Argh! It seems you don't understand that upgrading any "test" > version to a final version is *NEVER* a recommended option. If > it's a sacrificial box, as you say, then do an installation *from > scratch*, not an upgrade. It also has an install of bdi-emc on it (two drives) I'd druther not have to redo. I use one partition from the others hard drive for the /var. And thats something that the brain dead disk tool (or anaconda?) won't allow. It makes perfect sense, but that disk tool won't do it. > Once you have that done, and you see the > results and like them -- which I bet you will, since I'm using FC4 > myself -- take Seth's advice and *install* FC4 onto your "real" > system. Not an upgrade, not a mix-and-match of RPMs (especially > since "--force" is not your friend), but an actual installation. > If, by some chance, you need help or advice on that process, > consult fedora-list since the developers on this list are focused > on discussing what's broken, working, or coming up next for the > latest and greatest Fedora stuff. Did they get rid of whatever simple minded disk tool they were using?, or was it worked on enough that it did what you told it to? Whatever that was they used in FC3 is never, ever getting a chance to infect my system again. Gimme fdisk, which does exactly what you tell it to, nothing more, nothing less. I started 2 major list wars over that busted disk tool at the time and its not going to bite me again. >Hopefully I haven't annoyed any of said developers by pitching in on >this thread; I just thought it would save them some time and energy > they could devote to cool Fedora bits. Not to sound sycophantic, > but in case any of them are still reading, FC4 rocks hard. And > Seth, I used to be an up2date die-hard, but I'm now a yum convert. > The yum-utils are superb; I can't wait for pup. ;-) I agree, Yum is great, when it works. But its favorite pastime is upgrading something that destroys it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 Thu Jun 23 13:18:45 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 09:18:45 -0400 Subject: Yum did it again In-Reply-To: <1119528793.2878.32.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <1119528569.2878.28.camel@localhost.localdomain> <1119528793.2878.32.camel@localhost.localdomain> Message-ID: <200506230918.45359.gene.heskett@verizon.net> On Thursday 23 June 2005 08:13, Paul W. Frields wrote:> >Whoops, I hate to reply to myself, but I realized after replying > that this was on fedora-legacy-list and not fedora-devel-list. > (See earlier comment re: my ignorance, QED.) Bend the foregoing > comments into shape appropriately. NP Paul, have a nice day. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 skvidal at phy.duke.edu Thu Jun 23 13:48:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 23 Jun 2005 09:48:49 -0400 Subject: Yum did it again In-Reply-To: <200506230916.58219.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506230531.40327.gene.heskett@verizon.net> <1119528569.2878.28.camel@localhost.localdomain> <200506230916.58219.gene.heskett@verizon.net> Message-ID: <1119534529.27523.2.camel@opus.phy.duke.edu> > I agree, Yum is great, when it works. But its favorite pastime is > upgrading something that destroys it. So here's my confusion - this is the first bug report about yum doing this on FC1 or FC2 that I've even heard of let alone seen in bugzilla. I can't help but think that a lot of this is b/c of the mutant form of your franken-distro. Try running: rpm -Va --nofiles --nomd5 and see how many things get reported. -sv From gene.heskett at verizon.net Thu Jun 23 14:11:11 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 10:11:11 -0400 Subject: Yum did it again In-Reply-To: <1119534529.27523.2.camel@opus.phy.duke.edu> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <1119534529.27523.2.camel@opus.phy.duke.edu> Message-ID: <200506231011.11685.gene.heskett@verizon.net> On Thursday 23 June 2005 09:48, seth vidal wrote: >rpm -Va --nofiles --nomd5 A rather lengthy list, >75% of which is kernel >=2.2 dependencies. but uname -r returns 2.6.12-rc6-RT-V0.7.48-36, I'd just tried 50-17 but it locked up at the bogomips calc during the very early boot. Yeah, I bleed around the edges occasionally. :) The rest are leftovers from upgraded stuff, like gimp-print-4.2.6 and gimp-print-4.2.7. Gutenprint-5.0beta2 built from the tarball is doing those duties rather nicely. Strangely, no reports for any python or libxml2 stuff are in that list. libxml2-devel of course but nothing else even remotely related. Side comment here, regarding a utility called checkinstall. It would be very nice if some official help could be had in keeping it up to the changes in rpm, as that would allow us to make it look like an rpm had been installed & thereby satisfy all the rpm dependencies that are false negatives when we put in a tarball to scratch an itch in a broken distro. Like the cups in FC2 was a fscking disaster. And it had 2 security related updates that didn't fix the kde crash, I tried them both. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 jkeating at j2solutions.net Thu Jun 23 15:29:08 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 23 Jun 2005 08:29:08 -0700 Subject: Yum did it again In-Reply-To: <200506231011.11685.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <1119534529.27523.2.camel@opus.phy.duke.edu> <200506231011.11685.gene.heskett@verizon.net> Message-ID: <1119540548.2778.37.camel@yoda.loki.me> On Thu, 2005-06-23 at 10:11 -0400, Gene Heskett wrote: > rpm had been installed & thereby satisfy all the rpm dependencies > that are false negatives when we put in a tarball to scratch an itch > in a broken distro. Like the cups in FC2 was a fscking disaster. > And it had 2 security related updates that didn't fix the kde crash, > I tried them both. > Where are the bug reports about CUPS killing KDE? We used FC2 throughout its life time with cups and some users on KDE. Lots and lots of printing every single day, no problems. I seriously wonder if your KDE print issues weren't due to other franken-distro fun. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From gene.heskett at verizon.net Thu Jun 23 15:29:12 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 11:29:12 -0400 Subject: Yum did it again In-Reply-To: <1119534529.27523.2.camel@opus.phy.duke.edu> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <1119534529.27523.2.camel@opus.phy.duke.edu> Message-ID: <200506231129.12689.gene.heskett@verizon.net> On Thursday 23 June 2005 09:48, seth vidal wrote: No, I wrote this. >> I agree, Yum is great, when it works. But its favorite pastime is >> upgrading something that destroys it. > You (Seth Vidal) wrote this. >So here's my confusion - this is the first bug report about yum > doing this on FC1 or FC2 that I've even heard of let alone seen in > bugzilla. It was asked about, several times, on the fedora list Seth, & you even replied a couple of times asking for clarification. And when I did clarify that running 'yum update' had updated libxml2 stuff and that had then broken yum, no further replies were forthcoming. As far as fileing bugzilla reports, I long ago got tired of that P.O.C. looping forever thru its database search and not letting me into the editor to actually file a blow by blow. Let me know when bugzilla will let one enter a report, and then search its database to see if what I'm entering is a duplicate of 'this report', answer yes or no. To attempt to navigate thru bugzilla's version of pidgeon english looking for dups before it will let you at the editor to file a report is very very frustrating. Like you at times, I have far better things to do with the remaining time I'm allowed on this planet. At 70, I've used up a good share of that time already and bugzilla is a frustration I can do without very easily... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 Thu Jun 23 15:50:49 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 11:50:49 -0400 Subject: Yum did it again In-Reply-To: <1119540548.2778.37.camel@yoda.loki.me> References: <200506220722.00263.gene.heskett@verizon.net> <200506231011.11685.gene.heskett@verizon.net> <1119540548.2778.37.camel@yoda.loki.me> Message-ID: <200506231150.49309.gene.heskett@verizon.net> On Thursday 23 June 2005 11:29, Jesse Keating wrote: >On Thu, 2005-06-23 at 10:11 -0400, Gene Heskett wrote: >> rpm had been installed & thereby satisfy all the rpm dependencies >> that are false negatives when we put in a tarball to scratch an >> itch in a broken distro. Like the cups in FC2 was a fscking >> disaster. And it had 2 security related updates that didn't fix >> the kde crash, I tried them both. > >Where are the bug reports about CUPS killing KDE? We used FC2 >throughout its life time with cups and some users on KDE. Lots and > lots of printing every single day, no problems. I seriously wonder > if your KDE print issues weren't due to other franken-distro fun. They are not in bugzilla if thats what you are asking, see my previous msg about bugzilla and the advil sized headache I get everytime I try to enter a bug report. But there was certainly a lot of noise about it on the fedora-list at the time indicating I wasn't alone. And it _was_ a known problem on the cups mailing list. Updateing cups-1.1.17 via a tarball build to 1.1.19 fixed it right up, currently runing 1.1.23 via tarball build here now. kde is also at 3.3.0, built with konstruct and installed in root since I'm the only user of this machine. Odd maybe, but it works very well indeed. I'm on the kde mailing lists and I don't have 99% of the troubles I see being reported on those lists. Call it a franken-distro if you like, but AFAIAC I'm just fixing things that were broken from the gitgo with FC2, like printing. Stuff that should have Just Worked(TM). The fact that it never made bugzilla, and even worked in some cases is 2 seperate items. See my last msg for my feelings re bugzilla. The fact that it worked for some might be because they installed from scratch. I didn't, and don't, want to lose my archives, 3 GB of music I'd have to rerip, and 20GB of photos I'll have to suck back out of amanda to recover. Those are pretty good reasons to just update. And the FC4 install just lied to me. On that 'sacrificial box' it said I could fine tune its automatic disk config, but it went right ahead and formatted the drive and FC4 is about half installed without ever showing me what it did to /dev/hdb's 46GB. Where is /swap for instance, which I don't want on the same spindle as the rest of the system just to keep from thrashing the seeks. Apparently I won't know till I reboot and do a df. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 jkeating at j2solutions.net Thu Jun 23 16:20:30 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 23 Jun 2005 09:20:30 -0700 Subject: Yum did it again In-Reply-To: <200506231150.49309.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506231011.11685.gene.heskett@verizon.net> <1119540548.2778.37.camel@yoda.loki.me> <200506231150.49309.gene.heskett@verizon.net> Message-ID: <1119543630.3974.68.camel@localhost.localdomain> On Thu, 2005-06-23 at 11:50 -0400, Gene Heskett wrote: > They are not in bugzilla if thats what you are asking, see my > previous > msg about bugzilla and the advil sized headache I get everytime I try > to enter a bug report. I'm sorry you have a problem with our defined method of bug reporting and tracking. Tonnes of users seem to not have difficulties in filing bugs, some too many bugs. Regardless this is beyond the scope of Fedora Legacy. This is a project for security backports to end of lifed Red Hat and Fedora releases. Your problems do not seem to fit into this scope. Since your time is so precious, a good wipe and re-install would be quicker than trying to sort out your mess of an install. Thats just my opinion, take it for what you will. End of Topic. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 23 17:22:47 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 23 Jun 2005 13:22:47 -0400 Subject: Yum did it again In-Reply-To: <200506231150.49309.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506231011.11685.gene.heskett@verizon.net> <1119540548.2778.37.camel@yoda.loki.me> <200506231150.49309.gene.heskett@verizon.net> Message-ID: <1119547367.2878.53.camel@localhost.localdomain> Sorry to extend the thread once again, just passing on some rudimentary tips and a bit of FDP info. On Thu, 2005-06-23 at 11:50 -0400, Gene Heskett wrote: > On Thursday 23 June 2005 11:29, Jesse Keating wrote: > >On Thu, 2005-06-23 at 10:11 -0400, Gene Heskett wrote: [...snip...] > The fact that it never made bugzilla, and even worked in some cases is > 2 seperate items. See my last msg for my feelings re bugzilla. The > fact that it worked for some might be because they installed from > scratch. I didn't, and don't, want to lose my archives, 3 GB of > music I'd have to rerip, and 20GB of photos I'll have to suck back > out of amanda to recover. Those are pretty good reasons to just > update. A good partitioning setup would fix this problem. For instance, if you keep your archives somewhere in /home/$USER, just make your /home a separate partition or LVM volume. Now you can install without fear, just use the installation option for "Leave file system unchanged" for that partition/volume. I do this all the time, with 10 GB of materials that have survived reinstallations for RHL 8.0 and 9, FC1, 2, and 3 thus far. Many people with production servers have similar experiences, whether running enterprise products like RHEL or Fedora. > And the FC4 install just lied to me. On that 'sacrificial box' it > said I could fine tune its automatic disk config, but it went right > ahead and formatted the drive and FC4 is about half installed without > ever showing me what it did to /dev/hdb's 46GB. Where is /swap for > instance, which I don't want on the same spindle as the rest of the > system just to keep from thrashing the seeks. Apparently I won't > know till I reboot and do a df. Hmm, I hate to cast the problem on the "Big OE," as we say in my office, but I haven't observed this behavior while using the installer. Once again, if you can reproduce behavior, use Bugzilla to file it. (I know that you complained about Bugzilla being hard to use, and while I don't agree, as a Fedora Documentation Project writer/editor, I can tell you authoritatively that we are planning a Bugzilla tutorial document that will help novices use it. Many people don't need that help, but for others in the same boat as you, it may be indispensable, especially since your problems can't be worked on effectively without BZ bug entries. I'm telling you this because I would like to invite you to join the fedora-docs-list and volunteer to test the Bugzilla tutorial from an end-user point of view when it's ready.) If you really need to do the formatting yourself from scratch, you should be able to use the "manual" option, and if Disk Druid doesn't suffice, you can use fdisk from the virtual tty2 (hit Ctrl+Alt+F2) and then see if Disk Druid will cope with your assignments. It's quite a decent system now, and again, for specific problems, you can file a bug against "anaconda" with details if it doesn't work right for you. Once again, sorry to extend the thread. If you'd like to discuss further let's take it offlist where it belongs. To the extent I can help you via email, I'd be happy to do so. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Thu Jun 23 18:59:44 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 14:59:44 -0400 Subject: Yum did it again In-Reply-To: <1119543630.3974.68.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <200506231150.49309.gene.heskett@verizon.net> <1119543630.3974.68.camel@localhost.localdomain> Message-ID: <200506231459.44542.gene.heskett@verizon.net> On Thursday 23 June 2005 12:20, Jesse Keating wrote: >On Thu, 2005-06-23 at 11:50 -0400, Gene Heskett wrote: >> They are not in bugzilla if thats what you are asking, see my >> previous >> msg about bugzilla and the advil sized headache I get everytime I >> try to enter a bug report. > >I'm sorry you have a problem with our defined method of bug > reporting and tracking. Tonnes of users seem to not have > difficulties in filing bugs, some too many bugs. > >Regardless this is beyond the scope of Fedora Legacy. This is a > project for security backports to end of lifed Red Hat and Fedora > releases. Your problems do not seem to fit into this scope. > >Since your time is so precious, a good wipe and re-install would be >quicker than trying to sort out your mess of an install. Thats just > my opinion, take it for what you will. > >End of Topic. Well, FC4 seems to be doing moderately well on that sacrificial box, its now installing the last 135 updates for FC4 since the release. Veddy veddy slow progrss though... If it doesn't give me any more static I can't handle, I guess it goes on this machine about Sunday. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 skvidal at phy.duke.edu Thu Jun 23 18:59:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 23 Jun 2005 14:59:59 -0400 Subject: Yum did it again In-Reply-To: <200506231129.12689.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <1119534529.27523.2.camel@opus.phy.duke.edu> <200506231129.12689.gene.heskett@verizon.net> Message-ID: <1119553199.32522.39.camel@opus.phy.duke.edu> > It was asked about, several times, on the fedora list Seth, & you even > replied a couple of times asking for clarification. And when I did > clarify that running 'yum update' had updated libxml2 stuff and that > had then broken yum, no further replies were forthcoming. on fedora-list? I'm not on fedora-list. It's been many many months since I've been on fedora-list. > As far as fileing bugzilla reports, I long ago got tired of that > P.O.C. looping forever thru its database search and not letting me > into the editor to actually file a blow by blow. Let me know when > bugzilla will let one enter a report, and then search its database to > see if what I'm entering is a duplicate of 'this report', answer yes > or no. To attempt to navigate thru bugzilla's version of pidgeon > english looking for dups before it will let you at the editor to file > a report is very very frustrating. Like you at times, I have far > better things to do with the remaining time I'm allowed on this > planet. At 70, I've used up a good share of that time already and > bugzilla is a frustration I can do without very easily... Well, I'm sorry you feel that way. Good luck. -sv From gene.heskett at verizon.net Thu Jun 23 19:21:23 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 15:21:23 -0400 Subject: Yum did it again In-Reply-To: <1119547367.2878.53.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <200506231150.49309.gene.heskett@verizon.net> <1119547367.2878.53.camel@localhost.localdomain> Message-ID: <200506231521.23755.gene.heskett@verizon.net> On Thursday 23 June 2005 13:22, Paul W. Frields wrote: >> I didn't, and don't, want to lose my >> archives, 3 GB of music I'd have to rerip, and 20GB of photos I'll >> have to suck back out of amanda to recover. Those are pretty good >> reasons to just update. OTOH, with my amanda wrappers scripts save it all, I can extract a fully functional /home, and all the amanda records from the hd archive I have setup here in less than an hour, so restoreing a working amanda (cd /home/amanda/last_version, make install, ldconfig) is no real problem. >A good partitioning setup would fix this problem. For instance, if > you keep your archives somewhere in /home/$USER, just make your > /home a separate partition or LVM volume. Now you can install > without fear, just use the installation option for "Leave file > system unchanged" for that partition/volume. I do this all the > time, with 10 GB of materials that have survived reinstallations > for RHL 8.0 and 9, FC1, 2, and 3 thus far. Many people with > production servers have similar experiences, whether running > enterprise products like RHEL or Fedora. > >> And the FC4 install just lied to me. On that 'sacrificial box' it >> said I could fine tune its automatic disk config, but it went >> right ahead and formatted the drive and FC4 is about half >> installed without ever showing me what it did to /dev/hdb's 46GB. >> Where is /swap for instance, which I don't want on the same >> spindle as the rest of the system just to keep from thrashing the >> seeks. Apparently I won't know till I reboot and do a df. And no /swap is showing in /etc/mtab. Here is fstab from that box: [root at shop ~]# cat /etc/fstab # This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot1 /boot ext3 defaults 1 2 /dev/devpts /dev/pts devpts gid=5,mode=620 0 0 /dev/shm /dev/shm tmpfs defaults 0 0 /dev/proc /proc proc defaults 0 0 /dev/sys /sys sysfs defaults 0 0 /dev/hda3 swap swap defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 /dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0 /dev/hdd /media/cdrom auto pamconsole,exec,noauto,managed 0 0 So, which swap is it useing? Call me puzzled. >Hmm, I hate to cast the problem on the "Big OE," as we say in my > office, but I haven't observed this behavior while using the > installer. Once again, if you can reproduce behavior, use Bugzilla > to file it. > >(I know that you complained about Bugzilla being hard to use, and > while I don't agree, as a Fedora Documentation Project > writer/editor, I can tell you authoritatively that we are planning > a Bugzilla tutorial document that will help novices use it. Many > people don't need that help, but for others in the same boat as > you, it may be indispensable, especially since your problems can't > be worked on effectively without BZ bug entries. I'm telling you > this because I would like to invite you to join the > fedora-docs-list and volunteer to test the Bugzilla tutorial from > an end-user point of view when it's ready.) send a request to "fedora-docs-list-request at redhat.com"? >If you really need to do the formatting yourself from scratch, you >should be able to use the "manual" option, and if Disk Druid doesn't >suffice, Disk Druid, while seemingly giving you the options to do what you want, will then proceed to re-arrange the partition orders & types so that /dev/hda2=100 megs for /dos in fat32, gets to be /var. And you cannot even install, let alone boot with only a 100 meg /var. Rescue disk to the handy once you get it figure out what the hell happened. Difficult without better clues, lots better clues. >you can use fdisk from the virtual tty2 (hit Ctrl+Alt+F2) > and then see if Disk Druid will cope with your assignments. It's > quite a decent system now, and again, for specific problems, you > can file a bug against "anaconda" with details if it doesn't work > right for you. > >Once again, sorry to extend the thread. If you'd like to discuss >further let's take it offlist where it belongs. To the extent I can >help you via email, I'd be happy to do so. Ok, hit me off-list then. In the meantime I need to hit the showers as my tv station where I've been the Chief for the last 21 years is celebrating its 45th birthday & I intend to sample the fine, locally made Lambert Winery's product which will be available in quantities, along with some decent food suitable for a diabetic. :-) Back late tonight or tomorrow. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 cra at WPI.EDU Fri Jun 24 01:24:12 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 23 Jun 2005 21:24:12 -0400 Subject: Yum did it again In-Reply-To: <200506230916.58219.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506230531.40327.gene.heskett@verizon.net> <1119528569.2878.28.camel@localhost.localdomain> <200506230916.58219.gene.heskett@verizon.net> Message-ID: <20050624012412.GD26987@angus.ind.WPI.EDU> On Thu, Jun 23, 2005 at 09:16:58AM -0400, Gene Heskett wrote: > Did they get rid of whatever simple minded disk tool they were using?, > or was it worked on enough that it did what you told it to? Whatever > that was they used in FC3 is never, ever getting a chance to infect > my system again. Gimme fdisk, which does exactly what you tell it > to, nothing more, nothing less. I started 2 major list wars over > that busted disk tool at the time and its not going to bite me again. Try this: Ctrl-Alt-F2 fdisk I've done this myself several times to get exactly what I wanted, such as LVM with multiple PV partitions on a single device. From cra at WPI.EDU Fri Jun 24 01:32:43 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 23 Jun 2005 21:32:43 -0400 Subject: Yum did it again In-Reply-To: <200506231521.23755.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506231150.49309.gene.heskett@verizon.net> <1119547367.2878.53.camel@localhost.localdomain> <200506231521.23755.gene.heskett@verizon.net> Message-ID: <20050624013243.GE26987@angus.ind.WPI.EDU> On Thu, Jun 23, 2005 at 03:21:23PM -0400, Gene Heskett wrote: > And no /swap is showing in /etc/mtab. Here is fstab from that box: swap doesn't get mounted anywhere under / or otherwise. > /dev/hda3 swap swap defaults > 0 0 > /dev/VolGroup00/LogVol01 swap swap defaults > 0 0 > So, which swap is it useing? Call me puzzled. Both. See /proc/swaps. > Disk Druid, while seemingly giving you the options to do what you > want, will then proceed to re-arrange the partition orders & types so > that /dev/hda2=100 megs for /dos in fat32, gets to be /var. And you > cannot even install, let alone boot with only a 100 meg /var. Rescue > disk to the handy once you get it figure out what the hell happened. > Difficult without better clues, lots better clues. You can use the fdisk trick in Ctrl-Alt-F2, but then you still have to tell Disk Druid on Ctrl-Alt-F7 which of the fdisk-created partitions get assigned to which filesystems, / /var etc.. It will respect your choices. I have done this many times without problems. From cra at WPI.EDU Fri Jun 24 01:37:03 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 23 Jun 2005 21:37:03 -0400 Subject: Yum did it again In-Reply-To: <20050624013243.GE26987@angus.ind.WPI.EDU> References: <200506220722.00263.gene.heskett@verizon.net> <200506231150.49309.gene.heskett@verizon.net> <1119547367.2878.53.camel@localhost.localdomain> <200506231521.23755.gene.heskett@verizon.net> <20050624013243.GE26987@angus.ind.WPI.EDU> Message-ID: <20050624013703.GF26987@angus.ind.WPI.EDU> On Thu, Jun 23, 2005 at 09:32:43PM -0400, Chuck Anderson wrote: > You can use the fdisk trick in Ctrl-Alt-F2, but then you still have to > tell Disk Druid on Ctrl-Alt-F7 which of the fdisk-created partitions > get assigned to which filesystems, / /var etc.. It will respect your > choices. I have done this many times without problems. I should clarify this. You will probably need to reboot the installer for Anaconda/Disk Druid to actually see the changes you wrote out with fdisk. So, do a quick boot into the installer just far enough until Ctrl-Alt-F2 shows a working shell, fdisk, write changes, Ctrl-Alt-Delete, and restart the install for real. Choose "Manual" for partitioning, then assign your partitions to Swap, /, /var, /home, etc. From gene.heskett at verizon.net Fri Jun 24 03:16:48 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 23:16:48 -0400 Subject: Yum did it again In-Reply-To: <1119553199.32522.39.camel@opus.phy.duke.edu> References: <200506220722.00263.gene.heskett@verizon.net> <200506231129.12689.gene.heskett@verizon.net> <1119553199.32522.39.camel@opus.phy.duke.edu> Message-ID: <200506232316.48374.gene.heskett@verizon.net> On Thursday 23 June 2005 14:59, seth vidal wrote: >> It was asked about, several times, on the fedora list Seth, & you >> even replied a couple of times asking for clarification. And when >> I did clarify that running 'yum update' had updated libxml2 stuff >> and that had then broken yum, no further replies were forthcoming. > >on fedora-list? I'm not on fedora-list. It's been many many months > since I've been on fedora-list. This (the first time it happened) was maybe 2 months after FC2 final came out, so its quite a ways back up the log and timed out & deleted now. You were around the list & moderately active on it then. >> As far as fileing bugzilla reports, I long ago got tired of that >> P.O.C. looping forever thru its database search and not letting me >> into the editor to actually file a blow by blow. Let me know when >> bugzilla will let one enter a report, and then search its database >> to see if what I'm entering is a duplicate of 'this report', >> answer yes or no. To attempt to navigate thru bugzilla's version >> of pidgeon english looking for dups before it will let you at the >> editor to file a report is very very frustrating. Like you at >> times, I have far better things to do with the remaining time I'm >> allowed on this planet. At 70, I've used up a good share of that >> time already and bugzilla is a frustration I can do without very >> easily... > >Well, I'm sorry you feel that way. I should take another look I suppose, its been at least a year since I last attacked that beast. Maybe its been tamed a bit since? > >Good luck. Thanks. > >-sv -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 Fri Jun 24 03:19:26 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 23 Jun 2005 23:19:26 -0400 Subject: Yum did it again In-Reply-To: <20050624012412.GD26987@angus.ind.WPI.EDU> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <20050624012412.GD26987@angus.ind.WPI.EDU> Message-ID: <200506232319.26555.gene.heskett@verizon.net> On Thursday 23 June 2005 21:24, Chuck Anderson wrote: >On Thu, Jun 23, 2005 at 09:16:58AM -0400, Gene Heskett wrote: >> Did they get rid of whatever simple minded disk tool they were >> using?, or was it worked on enough that it did what you told it >> to? Whatever that was they used in FC3 is never, ever getting a >> chance to infect my system again. Gimme fdisk, which does exactly >> what you tell it to, nothing more, nothing less. I started 2 >> major list wars over that busted disk tool at the time and its not >> going to bite me again. > >Try this: > >Ctrl-Alt-F2 >fdisk > I'll try to remember that when I do this box. >I've done this myself several times to get exactly what I wanted, > such as LVM with multiple PV partitions on a single device. Is there a tutorial on LVM someplace? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 Fri Jun 24 11:04:25 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Jun 2005 07:04:25 -0400 Subject: RH7.3 box, any updates for it since up2date stopped? Message-ID: <200506240704.25681.gene.heskett@verizon.net> See subject. Specifically, iptables >1.26 won't install, but kernel is 2.4.29 now. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 mattdm at mattdm.org Fri Jun 24 12:36:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 24 Jun 2005 08:36:26 -0400 Subject: Yum did it again In-Reply-To: <200506232319.26555.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506230916.58219.gene.heskett@verizon.net> <20050624012412.GD26987@angus.ind.WPI.EDU> <200506232319.26555.gene.heskett@verizon.net> Message-ID: <20050624123626.GA6175@jadzia.bu.edu> On Thu, Jun 23, 2005 at 11:19:26PM -0400, Gene Heskett wrote: > Is there a tutorial on LVM someplace? The LVM HOWTO is a good start. . -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From gene.heskett at verizon.net Fri Jun 24 16:09:05 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Jun 2005 12:09:05 -0400 Subject: Yum did it again In-Reply-To: <20050624123626.GA6175@jadzia.bu.edu> References: <200506220722.00263.gene.heskett@verizon.net> <200506232319.26555.gene.heskett@verizon.net> <20050624123626.GA6175@jadzia.bu.edu> Message-ID: <200506241209.05650.gene.heskett@verizon.net> On Friday 24 June 2005 08:36, Matthew Miller wrote: >On Thu, Jun 23, 2005 at 11:19:26PM -0400, Gene Heskett wrote: >> Is there a tutorial on LVM someplace? > >The LVM HOWTO is a good start. > . What I'm reading there so far (up to section 4) brings up questions about its ability to work as a regular filesystem as far as tar & amanda are concerned. But I probably haven't read far enough yet, thats a regular 200+ page book that Tim should be printing! Obviously its now bookmarked. Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 jkeating at j2solutions.net Fri Jun 24 16:22:49 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Jun 2005 09:22:49 -0700 Subject: Yum did it again In-Reply-To: <200506241209.05650.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506232319.26555.gene.heskett@verizon.net> <20050624123626.GA6175@jadzia.bu.edu> <200506241209.05650.gene.heskett@verizon.net> Message-ID: <1119630169.21621.14.camel@localhost.localdomain> On Fri, 2005-06-24 at 12:09 -0400, Gene Heskett wrote: > > What I'm reading there so far (up to section 4) brings up questions > about its ability to work as a regular filesystem as far as tar & > amanda are concerned. But I probably haven't read far enough yet, > thats a regular 200+ page book that Tim should be printing! > > Obviously its now bookmarked. Thanks. LVM is a logical volume layer on top of which file systems get applied. LVM is not the file system, just a way of making the block layer a bit more logical and manageable. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Fri Jun 24 18:47:29 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 24 Jun 2005 14:47:29 -0400 Subject: Fedora Legacy Test Update Notification: gdk-pixbuf Message-ID: <42BC5541.8030902@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-154272 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154272 2005-06-24 --------------------------------------------------------------------- Name : gdk-pixbuf Versions : rh73: gdk-pixbuf-0.22.0-7.73.3.legacy Versions : rh9: gdk-pixbuf-0.22.0-7.90.3.legacy Versions : fc1: gdk-pixbuf-0.22.0-11.3.4.1.legacy Summary : An image loading library used with GNOME. Description : The gdk-pixbuf package contains an image loading library used with the GNOME desktop environment. The GdkPixBuf library provides image loading facilities, the rendering of a GdkPixBuf into various formats (drawables or GdkRGB buffers), and a cache interface. --------------------------------------------------------------------- Update Information: Updated gdk-pixbuf packages that fix a double free vulnerability are now available. The gdk-pixbuf package contains an image loading library used with the GNOME GUI desktop environment. A bug was found in the way gdk-pixbuf processes BMP images. It is possible that a specially crafted BMP image could cause a denial of service attack on applications linked against gdk-pixbuf. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0891 to this issue. Users of gdk-pixbuf are advised to upgrade to these packages, which contain a backported patch and are not vulnerable to this issue. --------------------------------------------------------------------- Changelogs rh73: * Wed May 11 2005 Pekka Savola 1:0.22.0-7.73.3.legacy - Add BMP loader double free crash from RHEL3 (CAN-2005-0891), #154272 rh9: * Wed May 11 2005 Pekka Savola 1:0.22.0-7.90.3.legacy - Add BMP loader double free crash from RHEL3 (CAN-2005-0891), #154272 fc1: * Wed May 11 2005 Pekka Savola 1:0.22.0-11.3.4.1.legacy - Add BMP loader double free crash from RHEL3 (CAN-2005-0891), #154272 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 603ade3d2671dc2486de4e88e5753c390cfbe25c redhat/7.3/updates-testing/i386/gdk-pixbuf-0.22.0-7.73.3.legacy.i386.rpm 9af2cd78533f6aa3edf18e418f22972e96dd68b8 redhat/7.3/updates-testing/i386/gdk-pixbuf-devel-0.22.0-7.73.3.legacy.i386.rpm c23e9bfe47fa3e23d05da3d336f151f15f260467 redhat/7.3/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-7.73.3.legacy.i386.rpm 9b4c5298bcaff267cb7ffa0bbfe90e64f6f2d925 redhat/7.3/updates-testing/SRPMS/gdk-pixbuf-0.22.0-7.73.3.legacy.src.rpm rh9: 34c176e0ff80d5cf680edd35aac08541a13cd4e6 redhat/9/updates-testing/i386/gdk-pixbuf-0.22.0-7.90.3.legacy.i386.rpm 8dcb027f064d3a378f44354fbc8fbfdf54402113 redhat/9/updates-testing/i386/gdk-pixbuf-devel-0.22.0-7.90.3.legacy.i386.rpm 53d96ae1336f7d4a442f239db2afc24ac91e27d5 redhat/9/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-7.90.3.legacy.i386.rpm 9fb12eae733ceca5606814fe6d46b9d2c2c63bd5 redhat/9/updates-testing/SRPMS/gdk-pixbuf-0.22.0-7.90.3.legacy.src.rpm fc1: 26ad2e60b327e7f5d4d0a5056be6cd42b0bff150 fedora/1/updates-testing/i386/gdk-pixbuf-0.22.0-11.3.4.1.legacy.i386.rpm 66885c30f770531c0dc53cc3715aa56633780613 fedora/1/updates-testing/i386/gdk-pixbuf-devel-0.22.0-11.3.4.1.legacy.i386.rpm f70ac09e0a5d768da740c37f1d5115589c6515e4 fedora/1/updates-testing/i386/gdk-pixbuf-gnome-0.22.0-11.3.4.1.legacy.i386.rpm 2f70a1f23a819f242d916529e7b531d494ef45eb fedora/1/updates-testing/SRPMS/gdk-pixbuf-0.22.0-11.3.4.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 Fri Jun 24 18:47:51 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 24 Jun 2005 14:47:51 -0400 Subject: Fedora Legacy Test Update Notification: telnet Message-ID: <42BC5557.40807@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152583 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152583 2005-06-24 --------------------------------------------------------------------- Name : telnet Versions : rh73: telnet-0.17-20.1.legacy Versions : rh9: telnet-0.17-25.1.legacy Versions : fc1: telnet-0.17-26.2.1.legacy Summary : The client program for the telnet remote login protocol. Description : Telnet is a popular protocol for logging into remote systems over the Internet. The telnet package provides a command line telnet client. --------------------------------------------------------------------- Update Information: Updated telnet packages that fix two buffer overflow vulnerabilities are now available. The telnet package provides a command line telnet client. The telnet- server package includes a telnet daemon, telnetd, that supports remote login to the host machine. Two buffer overflow flaws were discovered in the way the telnet client handles messages from a server. An attacker may be able to execute arbitrary code on a victim's machine if the victim can be tricked into connecting to a malicious telnet server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-0468 and CAN-2005-0469 to these issues. Users of telnet should upgrade to this updated package, which contains backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Wed May 11 2005 Pekka Savola 1:0.17-20.1.legacy - Apply RHEL patch to fix CAN-2005-0469 and CAN-2005-0468 (#152583) rh9: * Wed May 11 2005 Pekka Savola 1:0.17-25.1.legacy - Apply RHEL patch to fix CAN-2005-0469 and CAN-2005-0468 (#152583) fc1: * Wed May 11 2005 Pekka Savola 1:0.17-26.2.1.legacy - Apply RHEL patch to fix CAN-2005-0469 and CAN-2005-0468 (#152583) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: eb72994dc7fa63672d461f1b80189e450b7dc7ab redhat/7.3/updates-testing/i386/telnet-0.17-20.1.legacy.i386.rpm ae27914b4039594609d14d209c466f78b09649d4 redhat/7.3/updates-testing/i386/telnet-server-0.17-20.1.legacy.i386.rpm 3e426f9573240179fb31d5407ef9a25b82b836ec redhat/7.3/updates-testing/SRPMS/telnet-0.17-20.1.legacy.src.rpm rh9: 114ead8f946fd9f50f88ed017f03a2302647ebd1 redhat/9/updates-testing/i386/telnet-0.17-25.1.legacy.i386.rpm e5c31fdc2b08cd4a5614101be249a4888d87ded0 redhat/9/updates-testing/i386/telnet-server-0.17-25.1.legacy.i386.rpm acf5dc1ab3bbe1d704963eefe79fb66521a012da redhat/9/updates-testing/SRPMS/telnet-0.17-25.1.legacy.src.rpm fc1: 3298baa93d57f2caa2110bc83ae45731fc8c41e7 fedora/1/updates-testing/i386/telnet-0.17-26.2.1.legacy.i386.rpm 208769de63330b46785dbe0b23502c37307dfa65 fedora/1/updates-testing/i386/telnet-server-0.17-26.2.1.legacy.i386.rpm 58836e7c8741f08c5da712f6dc7cbd3d7a5581e8 fedora/1/updates-testing/SRPMS/telnet-0.17-26.2.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 Fri Jun 24 18:48:10 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 24 Jun 2005 14:48:10 -0400 Subject: Fedora Legacy Test Update Notification: openssh Message-ID: <42BC556A.4050906@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-123014 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123014 2005-06-24 --------------------------------------------------------------------- Name : openssh Versions : rh73: openssh-3.1p1-14.2.legacy Versions : rh9: openssh-3.5p1-11.2.legacy Versions : fc1: openssh-3.6.1p2-19.2.legacy Versions : fc2: openssh-3.6.1p2-34.2.legacy Summary : The OpenSSH implementation of SSH protocol. Description : OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. Public key authentication may be used for "passwordless" access to servers. --------------------------------------------------------------------- Update Information: Updated openssh packages that fix a potential security vulnerability are now available. OpenSSH is OpenBSD's SSH (Secure SHell) protocol implementation. SSH replaces rlogin and rsh, and provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over a secure channel. Public key authentication can be used for "passwordless" access to servers. The scp protocol allows a server to instruct a client to write to arbitrary files outside of the current directory. This could potentially cause a security issue if a user uses scp to copy files from a malicious server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0175 to this issue. These updated packages also correct the following bug: On systems where direct ssh access for the root user was disabled by configuration (setting "PermitRootLogin no"), attempts to guess the root password could be judged as sucessful or unsucessful by observing a delay. Users of openssh should upgrade to these updated packages, which contain backported patches to resolve these issues. --------------------------------------------------------------------- Changelogs rh73: * Thu Jun 23 2005 Marc Deslauriers 3.1p1-14.2.legacy - Added missing pam-devel and groff to BuildPrereq * Fri Jun 10 2005 Marc Deslauriers 3.1p1-14.1.legacy - CAN-2004-0175 don't allow scp to overwrite files in other directories - don't leak whether root password is right if root isn't allowed rh9: * Fri Jun 24 2005 Marc Deslauriers 3.5p1-11.2.legacy - Added missing pam-devel, groff and gtk2-devel BuildPrereq * Fri Jun 10 2005 Marc Deslauriers 3.5p1-11.1.legacy - CAN-2004-0175 don't allow scp to overwrite files in other directories - don't leak whether root password is right if root isn't allowed fc1: * Fri Jun 24 2005 Marc Deslauriers 3.6.1p1-19.2.legacy - Added missing pam-devel and groff to BuildPrereq * Fri Jun 10 2005 Marc Deslauriers 3.6.1p1-19.1.legacy - CAN-2004-0175 don't allow scp to overwrite files in other directories - don't leak whether root password is right if root isn't allowed fc2: * Fri Jun 24 2005 Marc Deslauriers 3.6.1p2-34.2.legacy - Added missing pam-devel and groff BuildPrereq * Fri Jun 10 2005 Marc Deslauriers 3.6.1p2-34.1.legacy - CAN-2004-0175 don't allow scp to overwrite files in other directories - don't leak whether root password is right if root isn't allowed --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 8bd4e4daf209249160c1d7f170c63b0d0f43bb54 redhat/7.3/updates-testing/i386/openssh-3.1p1-14.2.legacy.i386.rpm d24556ae238b448fe37d0ce1afa032a743b7339b redhat/7.3/updates-testing/i386/openssh-askpass-3.1p1-14.2.legacy.i386.rpm d7034dde021d188bbfff57b9287ea0f8dea162b0 redhat/7.3/updates-testing/i386/openssh-askpass-gnome-3.1p1-14.2.legacy.i386.rpm b24fa1844c81632719b0ee10c5aba27e72b1ef11 redhat/7.3/updates-testing/i386/openssh-clients-3.1p1-14.2.legacy.i386.rpm 7567b5a4c4f49ee9d247b30ae35741d3e0885f59 redhat/7.3/updates-testing/i386/openssh-server-3.1p1-14.2.legacy.i386.rpm 93591a2b6fd1d4be2796be09e108ff301bab9baf redhat/7.3/updates-testing/SRPMS/openssh-3.1p1-14.2.legacy.src.rpm rh9: 35820cc8261fffa5e1bbce4b22abb6075966418a redhat/9/updates-testing/i386/openssh-3.5p1-11.2.legacy.i386.rpm b006d5c937b482b30835d4a5283683f039d2c963 redhat/9/updates-testing/i386/openssh-askpass-3.5p1-11.2.legacy.i386.rpm 75f2303826649634880245fa13935c74bf76b8df redhat/9/updates-testing/i386/openssh-askpass-gnome-3.5p1-11.2.legacy.i386.rpm 598d2940ce65b82de88a7e563b0450752d679d50 redhat/9/updates-testing/i386/openssh-clients-3.5p1-11.2.legacy.i386.rpm d23f5da5bae703ee28a1de84999ce8fb4945ba20 redhat/9/updates-testing/i386/openssh-server-3.5p1-11.2.legacy.i386.rpm 67ac403b9057d01c5bbfc0ac0d7334955086f080 redhat/9/updates-testing/SRPMS/openssh-3.5p1-11.2.legacy.src.rpm fc1: 09ba397b8a3cdee453ab44af50470f392b1a1d9a fedora/1/updates-testing/i386/openssh-3.6.1p2-19.2.legacy.i386.rpm a59fbcbe89778e212b4ccaa397f298ad35291020 fedora/1/updates-testing/i386/openssh-askpass-3.6.1p2-19.2.legacy.i386.rpm d026e18b3d16d4b05d204de3aa1de9cf5e9ae756 fedora/1/updates-testing/i386/openssh-askpass-gnome-3.6.1p2-19.2.legacy.i386.rpm 70ebb446b1cc50bb2e242af4ec04cee53aa71713 fedora/1/updates-testing/i386/openssh-clients-3.6.1p2-19.2.legacy.i386.rpm 1af3ab8e0b843f6bf72c9061f3399ce09f674c98 fedora/1/updates-testing/i386/openssh-server-3.6.1p2-19.2.legacy.i386.rpm cee2cbca4b9fde1534bf76c9cb46d1ddd7a30fc7 fedora/1/updates-testing/SRPMS/openssh-3.6.1p2-19.2.legacy.src.rpm fc2: 42a086b1508853dd44be7d88e562613764c359cb fedora/2/updates-testing/i386/openssh-3.6.1p2-34.2.legacy.i386.rpm f39c8fc529c50d0a67eedb89abb04015970a5ec2 fedora/2/updates-testing/i386/openssh-askpass-3.6.1p2-34.2.legacy.i386.rpm 30c087e45ae7a3c6abcff83d8608d1c8d881458c fedora/2/updates-testing/i386/openssh-askpass-gnome-3.6.1p2-34.2.legacy.i386.rpm 53851fd533168707f6f250d66506dc51769c9348 fedora/2/updates-testing/i386/openssh-clients-3.6.1p2-34.2.legacy.i386.rpm 833ce8cf4f100a2b5b48aa77cb9d67fecba93366 fedora/2/updates-testing/i386/openssh-server-3.6.1p2-34.2.legacy.i386.rpm c7584c616f01c21264e912e77892ebc8bbd8be29 fedora/2/updates-testing/SRPMS/openssh-3.6.1p2-34.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 stickster at gmail.com Fri Jun 24 20:04:52 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 24 Jun 2005 16:04:52 -0400 Subject: Yum did it again In-Reply-To: <200506241209.05650.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506232319.26555.gene.heskett@verizon.net> <20050624123626.GA6175@jadzia.bu.edu> <200506241209.05650.gene.heskett@verizon.net> Message-ID: <1119643492.3120.27.camel@localhost.localdomain> On Fri, 2005-06-24 at 12:09 -0400, Gene Heskett wrote: > On Friday 24 June 2005 08:36, Matthew Miller wrote: > >On Thu, Jun 23, 2005 at 11:19:26PM -0400, Gene Heskett wrote: > >> Is there a tutorial on LVM someplace? > > > >The LVM HOWTO is a good start. > > . > > What I'm reading there so far (up to section 4) brings up questions > about its ability to work as a regular filesystem as far as tar & > amanda are concerned. But I probably haven't read far enough yet, > thats a regular 200+ page book that Tim should be printing! > > Obviously its now bookmarked. Thanks. LVM shouldn't cause any problems with those things. Think of it like this, although this is not a really rigorous diagram of the driver path (warning: bad ASCII art ahead): .-----------. .----------------------. | VFS layer |<===>| tar or other utility | |-----------| '----------------------' | ext3 | |-----------| | LVM | |-----------| | kernel | '-----------' Plainly put, LVM is an enabling technology that underlies your actual file system choices. You still choose ext3 "partitions," but now each of those partitions, instead of being defined on the disk itself in the partition tables, is sliced out of the total space in a LVM VG. Although your fstab will look different, to everything in user space, like tar, ls, etc., /home/me/myfile is accessed the same way. Clear as mud? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Fri Jun 24 22:32:16 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 24 Jun 2005 18:32:16 -0400 Subject: Yum did it again In-Reply-To: <1119643492.3120.27.camel@localhost.localdomain> References: <200506220722.00263.gene.heskett@verizon.net> <200506241209.05650.gene.heskett@verizon.net> <1119643492.3120.27.camel@localhost.localdomain> Message-ID: <200506241832.16156.gene.heskett@verizon.net> On Friday 24 June 2005 16:04, Paul W. Frields wrote: >On Fri, 2005-06-24 at 12:09 -0400, Gene Heskett wrote: >> On Friday 24 June 2005 08:36, Matthew Miller wrote: [...] >Plainly put, LVM is an enabling technology that underlies your > actual file system choices. You still choose ext3 "partitions," > but now each of those partitions, instead of being defined on the > disk itself in the partition tables, is sliced out of the total > space in a LVM VG. Although your fstab will look different, to > everything in user space, like tar, ls, etc., /home/me/myfile is > accessed the same way. Clear as mud? Approximately :-) What you are saying is that tar isn't going to care and it will work 'as usual', right? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly 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 stickster at gmail.com Sat Jun 25 00:03:30 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 24 Jun 2005 20:03:30 -0400 Subject: Yum did it again In-Reply-To: <200506241832.16156.gene.heskett@verizon.net> References: <200506220722.00263.gene.heskett@verizon.net> <200506241209.05650.gene.heskett@verizon.net> <1119643492.3120.27.camel@localhost.localdomain> <200506241832.16156.gene.heskett@verizon.net> Message-ID: <1119657811.5477.10.camel@localhost.localdomain> On Fri, 2005-06-24 at 18:32 -0400, Gene Heskett wrote: > On Friday 24 June 2005 16:04, Paul W. Frields wrote: > >On Fri, 2005-06-24 at 12:09 -0400, Gene Heskett wrote: > >> On Friday 24 June 2005 08:36, Matthew Miller wrote: > [...] > >Plainly put, LVM is an enabling technology that underlies your > > actual file system choices. You still choose ext3 "partitions," > > but now each of those partitions, instead of being defined on the > > disk itself in the partition tables, is sliced out of the total > > space in a LVM VG. Although your fstab will look different, to > > everything in user space, like tar, ls, etc., /home/me/myfile is > > accessed the same way. Clear as mud? > > Approximately :-) What you are saying is that tar isn't going to care > and it will work 'as usual', right? Correct. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 timtak at nihonbunka.com Sat Jun 25 23:14:09 2005 From: timtak at nihonbunka.com (Takemoto) Date: Sun, 26 Jun 2005 08:14:09 +0900 Subject: RH7.3 box, any updates for it since up2date stopped? References: <200506240704.25681.gene.heskett@verizon.net> Message-ID: <016d01c579db$9777b290$030ba8c0@exusasus> This is not in response to your question but...an ignoramous reports... I have RH9 and I thought htat after the endo of life up2date would not work but at the command line level it worked fine and I updated my kernel and other stuff a few weeks ago. Up2date seems to be keeping my system up to date. Tim From pekkas at netcore.fi Wed Jun 29 13:08:10 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 29 Jun 2005 16:08:10 +0300 (EEST) Subject: issues list(s) In-Reply-To: References: 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.fedoralegacy.org/wiki/index.php/QaTesting In particular, IMHO the biggest need right now is having people take a look at "All packages lacking VERIFY" category, secondarily "All packages lacking PUBLISH". There is also a large number of packages which still lack verify votes, but will be released anyway after a timeout. 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 jimpop at yahoo.com Wed Jun 29 14:53:48 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 29 Jun 2005 10:53:48 -0400 Subject: issues list(s) In-Reply-To: References: Message-ID: <1120056828.26727.10.camel@localhost> On Wed, 2005-06-29 at 16:08 +0300, 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.fedoralegacy.org/wiki/index.php/QaTesting > > In particular, IMHO the biggest need right now is having people take a > look at "All packages lacking VERIFY" category, secondarily "All > packages lacking PUBLISH". There is also a large number of packages > which still lack verify votes, but will be released anyway after a > timeout. > > http://www.netcore.fi/pekkas/buglist.html (all) > http://www.netcore.fi/pekkas/buglist-rhl73.html What is the status of the RH73 Mailman package? updates-testing still only has Mailman v2.0.13-7, is there even a RH73 update for v2.1.x and if not why is it listed on the rhl73 buglist? -Jim P. > http://www.netcore.fi/pekkas/buglist-rhl9.html > http://www.netcore.fi/pekkas/buglist-core1.html > http://www.netcore.fi/pekkas/buglist-fc2.html > From pekkas at netcore.fi Wed Jun 29 14:58:39 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 29 Jun 2005 17:58:39 +0300 (EEST) Subject: issues list(s) In-Reply-To: <1120056828.26727.10.camel@localhost> References: <1120056828.26727.10.camel@localhost> Message-ID: On Wed, 29 Jun 2005, Jim Popovitch wrote: >> http://www.netcore.fi/pekkas/buglist-rhl73.html > > What is the status of the RH73 Mailman package? updates-testing still > only has Mailman v2.0.13-7, is there even a RH73 update for v2.1.x and > if not why is it listed on the rhl73 buglist? 2.0.13-7.legacy is the latest mailman for RHL73. According to the bug number, sheltren at cs.ucsb.edu made somekind of a backport for 2.0.x. It's listed under "All -rhl73 packages lacking VERIFY, but will be released anyway unless issues are found" because there hasn't been a VERIFY for RHL73, but it will be released in two days in any case unless there are issues found. -- 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 jimpop at yahoo.com Wed Jun 29 15:01:34 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 29 Jun 2005 11:01:34 -0400 Subject: issues list(s) In-Reply-To: References: <1120056828.26727.10.camel@localhost> Message-ID: <1120057294.26727.13.camel@localhost> On Wed, 2005-06-29 at 17:58 +0300, Pekka Savola wrote: > On Wed, 29 Jun 2005, Jim Popovitch wrote: > >> http://www.netcore.fi/pekkas/buglist-rhl73.html > > > > What is the status of the RH73 Mailman package? updates-testing still > > only has Mailman v2.0.13-7, is there even a RH73 update for v2.1.x and > > if not why is it listed on the rhl73 buglist? > > 2.0.13-7.legacy is the latest mailman for RHL73. According to the bug > number, sheltren at cs.ucsb.edu made somekind of a backport for 2.0.x. > > It's listed under "All -rhl73 packages lacking VERIFY, but will be > released anyway unless issues are found" because there hasn't been a > VERIFY for RHL73, but it will be released in two days in any case > unless there are issues found. I see. Reading bugzilla left me with the impression that there would be a v2.1.x release for RH73. Thanks, -Jim P. From sopwith at redhat.com Mon Jun 27 20:52:47 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 27 Jun 2005 16:52:47 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-extras-list - For users and developers of Fedora Extras fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-tools-list - For discussions about the toolchain (gcc, gdb, etc...) within Fedora fedora-devel-java-list - For discussions about Java-related Fedora development fedora-patches-list - For submitting patches to Fedora maintainers, and used in line with BugWeek fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-marketing-list - For discussions about marketing and expanding the Fedora user base fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw