From jpdalbec at ysu.edu Thu Sep 1 17:23:32 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 01 Sep 2005 13:23:32 -0400 Subject: repomd.xml for FC2 at least? In-Reply-To: <20050901160019.2596273E28@hormel.redhat.com> References: <20050901160019.2596273E28@hormel.redhat.com> Message-ID: <43173914.7030706@ysu.edu> I'm trying to build FC2 RPMs under mach. I tried using an FC2 host system, but the version of yum in FC2 doesn't pass the --installroot information on to RPM so I get errors about packages already being installed because they're installed on the host system. I'm now trying to use an FC3 host system, but the FC2 repository has no repomd.xml file. Would it be possible to set one up? It'll be good practice for FC3. :) Thanks, John From sheltren at cs.ucsb.edu Fri Sep 2 13:05:59 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 2 Sep 2005 06:05:59 -0700 (PDT) Subject: repomd.xml for FC2 at least? In-Reply-To: <43173914.7030706@ysu.edu> References: <20050901160019.2596273E28@hormel.redhat.com> <43173914.7030706@ysu.edu> Message-ID: <49494.66.205.47.24.1125666359.squirrel@letters.cs.ucsb.edu> Hi John, I can't say about the metadata on the legacy repos, but I can recommend that you use a local mirror (either local to your build machine or local on your LAN) for building with mock or mach. Going remotely for all the needed packages is quite slow and will also be using a large amount of bandwidth for both you and the repo you are downloading from. Plus, if you have your own local mirror, you can add all the metadata you want :) -Jeff > I'm trying to build FC2 RPMs under mach. I tried using an FC2 host > system, but > the version of yum in FC2 doesn't pass the --installroot information on to > RPM > so I get errors about packages already being installed because they're > installed > on the host system. > > I'm now trying to use an FC3 host system, but the FC2 repository has no > repomd.xml file. Would it be possible to set one up? It'll be good > practice > for FC3. :) > > Thanks, > John From lists at benjamindsmith.com Sat Sep 3 01:06:03 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Fri, 2 Sep 2005 18:06:03 -0700 Subject: Fedora Legacy Test Update Notification: rp-pppoe In-Reply-To: References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> Message-ID: <200509021806.03183.lists@benjamindsmith.com> I'm inclined to go with option #3, but I'd want at least ONE verify. I don't know how many VERIFY marks are needed, but I'd suggest something like this: If 10 verify marks are needed currently, then drop that requirement by one per week, so that at 10 weeks, only 1 verify would be needed. That way, anything people think is important can go out fairly quickly, while still giving ample time to those who care to try it out first. I think 6 weeks is a tad short, I'd go more like 2-2.5 months, but 6 weeks would work. -Ben On Friday 26 August 2005 22:49, Pekka Savola wrote: > 3) just releasing them with lower amount of QA or no QA at all after > some timeout (e.g., 6 weeks) and revising if someone complains it > doesn't work right. -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From pekkas at netcore.fi Mon Sep 5 05:10:55 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 5 Sep 2005 08:10:55 +0300 (EEST) Subject: Fedora Legacy Test Update Notification: rp-pppoe In-Reply-To: <200509021806.03183.lists@benjamindsmith.com> References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> <200509021806.03183.lists@benjamindsmith.com> Message-ID: On Fri, 2 Sep 2005, Benjamin Smith wrote: > I'm inclined to go with option #3, but I'd want at least ONE verify. > > I don't know how many VERIFY marks are needed, but I'd suggest something like > this: If 10 verify marks are needed currently, then drop that requirement by > one per week, so that at 10 weeks, only 1 verify would be needed. > > That way, anything people think is important can go out fairly quickly, while > still giving ample time to those who care to try it out first. > > I think 6 weeks is a tad short, I'd go more like 2-2.5 months, but 6 weeks > would work. See the current procedure under "Publish Criteria for updates (VERIFY)": http://www.fedoraproject.org/wiki/Legacy/QATesting In short, currently if we get just a single VERIFY vote, the update will be released after 4 weeks of timeout. This proposal was addressing the case where we don't get even one vote. -- 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 Sep 5 08:03:33 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 5 Sep 2005 11:03:33 +0300 (EEST) Subject: remove/disable old wiki? Message-ID: Hi, I just noticed that the old wiki is still accessible if you know/are referred to the old url (http://www.fedoralegacy.org/wiki/). Would is make sense to disable access or remove the old wiki, so if folks are following older pointers they would not get obsolete information/obsolete web pages? -- 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 sebenste at weather.admin.niu.edu Tue Sep 6 04:07:13 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Mon, 5 Sep 2005 23:07:13 -0500 (CDT) Subject: OpenSSH vulnerabilities? Message-ID: Hey all, Does the second one or any at the bottom of this page affect FC1: http://secunia.com/advisories/16686/ Gilbert ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From jkeating at j2solutions.net Tue Sep 6 15:47:02 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 06 Sep 2005 08:47:02 -0700 Subject: remove/disable old wiki? In-Reply-To: References: Message-ID: <1126021622.19639.28.camel@prometheus.gamehouse.com> On Mon, 2005-09-05 at 11:03 +0300, Pekka Savola wrote: > Hi, > > I just noticed that the old wiki is still accessible if you know/are > referred to the old url (http://www.fedoralegacy.org/wiki/). > > Would is make sense to disable access or remove the old wiki, so if > folks are following older pointers they would not get obsolete > information/obsolete web pages? > Yes, I suppose that could be done. I'll add that to my to-do list. -- 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 From deisenst at gtw.net Wed Sep 7 06:31:52 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 7 Sep 2005 01:31:52 -0500 (CDT) Subject: Anybody use bzip2? Message-ID: Folks, Just in case you do use bzip2, there are bzip2 .src.rpm packages for RH73, RH9, FC1 and FC2 needing Publish (source-level) QA at: . In case any of you now reading this are new to this list and to Fedora Legacy, the QA process for "Publish QA" is documented here: If you find any of this confusing or don't understand something, please don't be shy: Ask. We don't bite. Usually. :-) Thank you. -David --- --- --- Here is a list of the vulnerabilties this bzip2 update is patching (from Red Hat Security Advisory RHSA-2005:474-01, at ): "A bug was found in the way bzgrep processes file names. If a user can be tricked into running bzgrep on a file with a carefully crafted file name, arbitrary commands could be executed as the user running bzgrep. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0758 to this issue. "A bug was found in the way bzip2 modifies file permissions during decompression. If an attacker has write access to the directory into which bzip2 is decompressing files, it is possible for them to modify permissions on files owned by the user running bzip2 (CAN-2005-0953). "A bug was found in the way bzip2 decompresses files. It is possible for an attacker to create a specially crafted bzip2 file which will cause bzip2 to cause a denial of service (by filling disk space) if decompressed by a victim (CAN-2005-1260)." From mike.mccarty at sbcglobal.net Wed Sep 7 21:26:39 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Wed, 07 Sep 2005 16:26:39 -0500 Subject: Subscribed properly? Message-ID: <431F5B0F.4030703@sbcglobal.net> I wonder whether I am properly subscribed. This is what I observe: # yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - Base Server: Fedora Legacy utilities for Fedora Core 2 Server: Fedora Core 2 updates Finding updated packages Downloading needed headers No Packages Available for Update No actions to take # I wonder whether I need to subscribe to another server name. I haven't pulled even one update since about two months. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From nils at lemonbit.nl Wed Sep 7 21:47:34 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 7 Sep 2005 23:47:34 +0200 Subject: Subscribed properly? In-Reply-To: <431F5B0F.4030703@sbcglobal.net> References: <431F5B0F.4030703@sbcglobal.net> Message-ID: <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> Mike wrote: > I wonder whether I am properly subscribed. This is what > I observe: > > # yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 2 - Base > Server: Fedora Legacy utilities for Fedora Core 2 > Server: Fedora Core 2 updates > Finding updated packages > Downloading needed headers > No Packages Available for Update > No actions to take > # > > I wonder whether I need to subscribe to another server name. > I haven't pulled even one update since about two months. It looks like you didn't add the legacy updates, but only the legacy utilities repository. What are the exact repository entries in your yum.conf? Nils Breunese Lemonbit Internet From jkosin at beta.intcomgrp.com Wed Sep 7 22:44:22 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 07 Sep 2005 18:44:22 -0400 Subject: [FC1] James' Updates Message-ID: <431F6D46.8070901@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, REMEMBER: ~ (1) My updates are not supported by anyone other than me or the original group that is currently developing the software. ~ (2) Fedora-Legacy, Fedora and other groups are not supporting these updates. Don't complain to them about my updates!!! They usually won't know what you are talking about. ~ (3) If I tell of a kernel update! DO NOT GET RID OF YOUR OLD KERNEL. Keeping an old kernel that works installed is kinda like having a bootable floppy that works, if something breaks you still have a good system. ~ (4) Please let me know if you would like to see any other updates. Right now, I can't do a lot of updates but, I'm willing to add as long as everyone knows I'm only one person. ~ (5) MY UPDATES HAVE ONLY BEEN TESTED WITH FC1 !!! If you want to try them on FC2, RedHat 7.3 etc you are welcome to try, but I can't help with any problems... I just don't have the time. ============================================== SAMBA 3.0.20 - ------------ I applied the latest patch to fix the RPC fault with XP clients and the patch for fixing users with permission to modify domain and group attributes. You can get more information at http://samba.org/samba/patches/ . I am also having to limit the patches to the samba releases I post to once a week. For a while I was changing on almost an every other day event. SOURCES - ------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/samba-3.0.20-5.fc1.src.rpm BINARIES - -------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-3.0.20-5.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-client-3.0.20-5.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-common-3.0.20-5.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-swat-3.0.20-5.fc1.i386.rpm ============================================== SpamAssassin 3.0.4 - ------------------ I've managed to download and get the sources to compile for FC1 for the latest release of SpamAssassin. I don't personally use SpamAssassin; so, please let me know if there are any issues. Only one document for README.spamd did not make it to the release. Mostly because they renamed the document to README in the sources and this conflicts with the README in the top level directory. I will try to get a fix for this later, if needed. SOURCES - ------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/spamassassin-3.0.4-0.fc1.src.rpm BINARIES - -------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/spamassassin-3.0.4-0.fc1.i386.rpm ===================================================================== All of my binary packages are signed..... http://support.intcomgrp.com/mirror/fedora-core/beta/RPM-GPG-KEY-JAMES The SHA1 Sums for the binaries are here: http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sha1sum.txt The SHA1 Sums for the source files are here: http://support.intcomgrp.com/mirror/fedora-core/beta/src/sha1sum.txt I run a YUM server for FC1.... you can also point your updates to http://support.intcomgrp.com/mirror/fedora-core/beta/i386 BUT ONLY IF YOU WANT! ====================================================================== Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDH21GkNLDmnu1kSkRA31YAJ9iP+GIBqFEAZsxjsSuqFp53VXyDACfXsp0 0rzqKM2sBpoRm8k8UdYYR6w= =9VYo -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mike.mccarty at sbcglobal.net Thu Sep 8 17:41:57 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 08 Sep 2005 12:41:57 -0500 Subject: Subscribed properly? In-Reply-To: <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> References: <431F5B0F.4030703@sbcglobal.net> <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> Message-ID: <432077E5.4000601@sbcglobal.net> Nils Breunese (Lemonbit Internet) wrote: > Mike wrote: > >> I wonder whether I am properly subscribed. This is what >> I observe: >> >> # yum update >> Gathering header information file(s) from server(s) >> Server: Fedora Core 2 - Base >> Server: Fedora Legacy utilities for Fedora Core 2 >> Server: Fedora Core 2 updates >> Finding updated packages >> Downloading needed headers >> No Packages Available for Update >> No actions to take >> # >> >> I wonder whether I need to subscribe to another server name. >> I haven't pulled even one update since about two months. > > > It looks like you didn't add the legacy updates, but only the legacy > utilities repository. What are the exact repository entries in your > yum.conf? I thought something like that might be the case. Here's a copy of my /etc/conf... $ cat /etc/yum.conf # See the yum.conf(5) man page for information the syntax of this file, # including failover setup. [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 exclude=kernel* [base] gpgcheck=1 name=Fedora Core $releasever - Base baseurl=http://download.fedoralegacy.org/fedora/$releasever/os/$basearch [updates] gpgcheck=1 name=Fedora Core $releasever updates baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch [legacy-utils] gpgcheck=1 name=Fedora Legacy utilities for Fedora Core $releasever baseurl=http://download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch ========================================== I'm thinking I left out one of the necessary entries. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From nils at lemonbit.nl Thu Sep 8 20:10:18 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Thu, 8 Sep 2005 22:10:18 +0200 Subject: Subscribed properly? In-Reply-To: <432077E5.4000601@sbcglobal.net> References: <431F5B0F.4030703@sbcglobal.net> <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> <432077E5.4000601@sbcglobal.net> Message-ID: Mike wrote: > [base] > gpgcheck=1 > name=Fedora Core $releasever - Base > baseurl=http://download.fedoralegacy.org/fedora/$releasever/os/ > $basearch > > [updates] > gpgcheck=1 > name=Fedora Core $releasever updates > baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/ > $basearch > > [legacy-utils] > gpgcheck=1 > name=Fedora Legacy utilities for Fedora Core $releasever > baseurl=http://download.fedoralegacy.org/fedora/$releasever/legacy- > utils/$basearch Hm, well, that looks just fine actually. You might want to name the [updates] channel Fedora Core $releasever Legacy updates to be clear, but other than that nothing is wrong. Apparently there are no updates for the packages you have installed. You can a manual check by going to the url mentioned under [updates] (replacing $releasever with the version of your Fedora install (e.g. '2') and $basearch with i386 (or whatever architecture you're running)) and see if there are any packages there that you have installed but are newer than your installed versions. Nils. From mike.mccarty at sbcglobal.net Thu Sep 8 21:35:44 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 08 Sep 2005 16:35:44 -0500 Subject: Subscribed properly? In-Reply-To: References: <431F5B0F.4030703@sbcglobal.net> <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> <432077E5.4000601@sbcglobal.net> Message-ID: <4320AEB0.2060203@sbcglobal.net> Nils Breunese (Lemonbit Internet) wrote: > Mike wrote: > [snip /etc/yum.conf contents] > Hm, well, that looks just fine actually. You might want to name the > [updates] channel Fedora Core $releasever Legacy updates to be clear, > but other than that nothing is wrong. Apparently there are no updates [snip] Thanks! -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From hajo at hajo.net Fri Sep 9 13:52:45 2005 From: hajo at hajo.net (HaJo Schatz) Date: Fri, 09 Sep 2005 21:52:45 +0800 Subject: [FC1] James' Updates In-Reply-To: <431F6D46.8070901@beta.intcomgrp.com> References: <431F6D46.8070901@beta.intcomgrp.com> Message-ID: <432193AD.4040706@hajo.net> James, I truly appreciate your efforts to get latest versions of critical packages out. However, [...] > SpamAssassin 3.0.4 > ------------------ [...] I'd suggest you have a look at Axel Thimm's atrpms archive. He has quite a few packages up-to-date for legacy RH/Fedora releases. Among them, he has released SA 3.0.4 quite a long time ago. Might save you some time for other packages ;-) -- HaJo Schatz http://www.HaJo.Net PGP-Key: http://www.hajo.net/hajonet/keys/pgpkey_hajo.txt From sebenste at weather.admin.niu.edu Fri Sep 9 15:35:58 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Fri, 9 Sep 2005 10:35:58 -0500 (CDT) Subject: [FC1] James' Updates In-Reply-To: <432193AD.4040706@hajo.net> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> Message-ID: On Fri, 9 Sep 2005, HaJo Schatz wrote: > James, I truly appreciate your efforts to get latest versions of critical > packages out. > > However, > [...] >> SpamAssassin 3.0.4 >> ------------------ > [...] > > I'd suggest you have a look at Axel Thimm's atrpms archive. He has quite a > few packages up-to-date for legacy RH/Fedora releases. Among them, he has > released SA 3.0.4 quite a long time ago. Might save you some time for other > packages ;-) That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch of incompatibility errors. However... James, when I restart spamassassin in /etc/rc.d/init.d, I get: Starting spamd: The -a option has been removed. Please look at the use_auto_whitelist config option instead. [ FAILED] I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. Any ideas? ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From sebenste at weather.admin.niu.edu Fri Sep 9 15:41:07 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Fri, 9 Sep 2005 10:41:07 -0500 (CDT) Subject: [FC1] James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> Message-ID: On Fri, 9 Sep 2005, Gilbert Sebenste wrote: > That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch of > incompatibility errors. However... > > James, when I restart spamassassin in /etc/rc.d/init.d, I get: > > Starting spamd: The -a option has been removed. Please look at the > use_auto_whitelist config option instead. [ FAILED] > > I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. > Any ideas? Sorry, this got left out. this is my Spamassassin file, very close to the default values: #!/bin/sh # # spamassassin This script starts and stops the spamd daemon # # chkconfig: - 80 30 # processname: spamd # description: spamd is a daemon process which uses SpamAssassin to check \ # email messages for SPAM. It is normally called by spamc \ # from a MDA. # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 # Set default spamd configuration. SPAMDOPTIONS="-d -c -m5 -H" # Source spamd configuration. if [ -f /etc/sysconfig/spamassassin ] ; then . /etc/sysconfig/spamassassin fi [ -f /usr/bin/spamd -o -f /usr/local/bin/spamd ] || exit 0 PATH=$PATH:/usr/bin:/usr/local/bin # By default it's all good RETVAL=0 # See how we were called. case "$1" in start) # Start daemon. echo -n "Starting spamd: " daemon $NICELEVEL spamd $SPAMDOPTIONS RETVAL=$? echo [ $RETVAL = 0 ] && touch /var/lock/subsys/spamassassin ;; stop) # Stop daemons. echo -n "Shutting down spamd: " killproc spamd RETVAL=$? echo [ $RETVAL = 0 ] && rm -f /var/lock/subsys/spamassassin ;; restart) $0 stop $0 start ;; condrestart) [ -e /var/lock/subsys/spamassassin ] && $0 restart ;; status) status spamd RETVAL=$? ;; *) echo "Usage: $0 {start|stop|restart|status|condrestart}" RETVAL=1 ;; esac exit $RETVAL From Axel.Thimm at ATrpms.net Fri Sep 9 16:00:20 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Sep 2005 18:00:20 +0200 Subject: James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> Message-ID: <20050909160020.GC18541@neu.nirvana> On Fri, Sep 09, 2005 at 10:35:58AM -0500, Gilbert Sebenste wrote: > On Fri, 9 Sep 2005, HaJo Schatz wrote: > > >James, I truly appreciate your efforts to get latest versions of critical > >packages out. > > > >However, > >[...] > >>SpamAssassin 3.0.4 > >[...] > > > >I'd suggest you have a look at Axel Thimm's atrpms archive. He has quite a > >few packages up-to-date for legacy RH/Fedora releases. Among them, he has > >released SA 3.0.4 quite a long time ago. Might save you some time for > >other packages ;-) > > That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch of > incompatibility errors. However... What errors? I know that spamassassin 3.0.4 at ATrpms is used on systems as old as RH7.3. Could you please file a report at bugzilla.atrpms.net or send me the errors (if there are any) in PM? -- 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 Axel.Thimm at ATrpms.net Fri Sep 9 16:02:26 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Sep 2005 18:02:26 +0200 Subject: James' Updates In-Reply-To: <431F6D46.8070901@beta.intcomgrp.com> References: <431F6D46.8070901@beta.intcomgrp.com> Message-ID: <20050909160226.GD18541@neu.nirvana> On Wed, Sep 07, 2005 at 06:44:22PM -0400, James Kosin wrote: > SAMBA 3.0.20 > I applied the latest patch to fix the RPC fault with XP clients and > the patch for fixing users with permission to modify domain and group > attributes. That's cool, thanks! > I am also having to limit the patches to the samba releases I post to > once a week. For a while I was changing on almost an every other day > event. :) -- 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 sebenste at weather.admin.niu.edu Fri Sep 9 16:05:20 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Fri, 9 Sep 2005 11:05:20 -0500 (CDT) Subject: James' Updates In-Reply-To: <20050909160020.GC18541@neu.nirvana> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> Message-ID: On Fri, 9 Sep 2005, Axel Thimm wrote: >> That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch of >> incompatibility errors. However... > > What errors? I know that spamassassin 3.0.4 at ATrpms is used on > systems as old as RH7.3. I get the following: # rpm -Fvh spam*.4-1*.rpm warning: spamassassin-3.0.4-1_26.rhfc1.at.i386.rpm: V3 DSA signature: NOKEY, key ID 66534c2b error: Failed dependencies: /usr/bin/dccproc is needed by spamassassin-3.0.4-1_26.rhfc1.at /usr/bin/pyzor is needed by spamassassin-3.0.4-1_26.rhfc1.at atrpms-perl-module-helper is needed by spamassassin-3.0.4-1_26.rhfc1.at perl(IO::Socket::SSL) is needed by spamassassin-3.0.4-1_26.rhfc1.at perl(Net::DNS) >= 0.34 is needed by spamassassin-3.0.4-1_26.rhfc1.at perl(Razor2::Client::Version) is needed by spamassassin-3.0.4-1_26.rhfc1.at # which pyzor /usr/bin/which: no pyzor in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/games:/usr/lib/mh:/usr/bin/mh:/home/ldm/bin:/home/ldm/wxpscripts:/home/ldm/decoders:/home/ldm/decoders/bin:/home/ldm/wxpscripts:/sbin:/usr/sbin:/usr/bin/X11:.) ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From Axel.Thimm at ATrpms.net Fri Sep 9 16:16:49 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Sep 2005 18:16:49 +0200 Subject: James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> Message-ID: <20050909161649.GE18541@neu.nirvana> On Fri, Sep 09, 2005 at 11:05:20AM -0500, Gilbert Sebenste wrote: > On Fri, 9 Sep 2005, Axel Thimm wrote: > > >>That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch of > >>incompatibility errors. However... > > > >What errors? I know that spamassassin 3.0.4 at ATrpms is used on > >systems as old as RH7.3. > > I get the following: But all of this *is* in ATrpms :) You need a depsolver (apt/yum/smart/up2date) and point it to the stable repo at ATrpms for FC1. Then simply issue something like smart update && smart install spamassassin Or you can get the packages manually of course. DCC, pyzor, razor-agents, perl-- etc. All these further packages enhance spamassassin in one way or another, especially by allowing it to effectively compare the mail to be examined against network databases of known spam and thus getting a more precise spam scoring. > # rpm -Fvh spam*.4-1*.rpm > > warning: spamassassin-3.0.4-1_26.rhfc1.at.i386.rpm: V3 DSA signature: > NOKEY, key ID 66534c2b > > error: Failed dependencies: > /usr/bin/dccproc is needed by spamassassin-3.0.4-1_26.rhfc1.at > /usr/bin/pyzor is needed by spamassassin-3.0.4-1_26.rhfc1.at > atrpms-perl-module-helper is needed by > spamassassin-3.0.4-1_26.rhfc1.at > perl(IO::Socket::SSL) is needed by > spamassassin-3.0.4-1_26.rhfc1.at > perl(Net::DNS) >= 0.34 is needed by > spamassassin-3.0.4-1_26.rhfc1.at > perl(Razor2::Client::Version) is needed by > spamassassin-3.0.4-1_26.rhfc1.at > # which pyzor > /usr/bin/which: no pyzor in > (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/games:/usr/lib/mh:/usr/bin/mh:/home/ldm/bin:/home/ldm/wxpscripts:/home/ldm/decoders:/home/ldm/decoders/bin:/home/ldm/wxpscripts:/sbin:/usr/sbin:/usr/bin/X11:.) > > ******************************************************************************* > Gilbert Sebenste > ******** > (My opinions only!) ****** > Staff Meteorologist, Northern Illinois University **** > E-mail: sebenste at weather.admin.niu.edu *** > web: http://weather.admin.niu.edu ** > ******************************************************************************* > -- 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 sebenste at weather.admin.niu.edu Fri Sep 9 16:20:18 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Fri, 9 Sep 2005 11:20:18 -0500 (CDT) Subject: James' Updates In-Reply-To: <20050909161649.GE18541@neu.nirvana> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> Message-ID: Hi Axel, > But all of this *is* in ATrpms :) > > You need a depsolver (apt/yum/smart/up2date) and point it to the > stable repo at ATrpms for FC1. Then simply issue something like Can you help me here? What can I put into my yum.conf file to point to it? > smart update && smart install spamassassin So if I type "yum update spamassassin", it should grab all the others, correct? > All these further packages enhance spamassassin in one way or another, > especially by allowing it to effectively compare the mail to be > examined against network databases of known spam and thus getting a > more precise spam scoring. Ahhh, I like that. OK, I'm game to try. Can you help me a bit here with the above questions? ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From jkosin at beta.intcomgrp.com Fri Sep 9 16:22:06 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 09 Sep 2005 12:22:06 -0400 Subject: [FC1] James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> Message-ID: <4321B6AE.9070708@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Gilbert Sebenste wrote: | On Fri, 9 Sep 2005, HaJo Schatz wrote: | |> James, I truly appreciate your efforts to get latest versions of |> critical packages out. |> |> However, |> [...] |> |>> SpamAssassin 3.0.4 |>> ------------------ |> |> [...] |> |> I'd suggest you have a look at Axel Thimm's atrpms archive. He has |> quite a few packages up-to-date for legacy RH/Fedora releases. |> Among them, he has released SA 3.0.4 quite a long time ago. Might |> save you some time for other packages ;-) | | | That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch | of incompatibility errors. However... | | James, when I restart spamassassin in /etc/rc.d/init.d, I get: | | Starting spamd: The -a option has been removed. Please look at the | use_auto_whitelist config option instead. [ FAILED] | | I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. | Any ideas? | | ******************************************************************************* | | Gilbert Sebenste | ******** | (My opinions only!) | ****** | Staff Meteorologist, Northern Illinois | University **** | E-mail: | sebenste at weather.admin.niu.edu *** | web: | http://weather.admin.niu.edu ** | ******************************************************************************* | | | -- | fedora-legacy-list mailing list | fedora-legacy-list at redhat.com | http://www.redhat.com/mailman/listinfo/fedora-legacy-list I'll look into in when I get back! Got school now and lunch. James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIbaukNLDmnu1kSkRAxrLAJ9/qYSfTm2F4/Dor7X6TDTWj62dHgCbBPJ7 2dqrYzoGhedD40jWMmcCMRU= =daBN -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From hajo at hajo.net Fri Sep 9 16:46:08 2005 From: hajo at hajo.net (HaJo Schatz) Date: Sat, 10 Sep 2005 00:46:08 +0800 Subject: [FC1] James' Updates In-Reply-To: <4321B6AE.9070708@beta.intcomgrp.com> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <4321B6AE.9070708@beta.intcomgrp.com> Message-ID: <4321BC50.1050903@hajo.net> James Kosin wrote: > | Starting spamd: The -a option has been removed. Please look at the > | use_auto_whitelist config option instead. [ FAILED] > | > | I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. > | Any ideas? Had the same, but can't remember how I resolved it. This was documented somewhere, I assume on spamassassin.apache.org. For a start, have you looked into ~/.spamassassin/user_prefs as well? Or, into /etc/init.d/spamassassin and /etc/sysconfig/spamassassin? -- HaJo Schatz http://www.HaJo.Net PGP-Key: http://www.hajo.net/hajonet/keys/pgpkey_hajo.txt From jpdalbec at ysu.edu Fri Sep 9 16:57:32 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 09 Sep 2005 12:57:32 -0400 Subject: [FC1] James' Updates Message-ID: <4321BEFC.2070400@ysu.edu> > I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. Try /etc/sysconfig/spamassassin. John From sebenste at weather.admin.niu.edu Fri Sep 9 17:09:46 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Fri, 9 Sep 2005 12:09:46 -0500 (CDT) Subject: [FC1] James' Updates In-Reply-To: <4321BEFC.2070400@ysu.edu> References: <4321BEFC.2070400@ysu.edu> Message-ID: On Fri, 9 Sep 2005, John Dalbec wrote: >> I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. > > Try /etc/sysconfig/spamassassin. > John Hi John, Way to go. There it was. Ahhh! Too many config file locations. Thanks for the help! ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From Axel.Thimm at ATrpms.net Fri Sep 9 17:36:13 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Sep 2005 19:36:13 +0200 Subject: James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> Message-ID: <20050909173613.GA28024@neu.nirvana> Hi, On Fri, Sep 09, 2005 at 11:20:18AM -0500, Gilbert Sebenste wrote: > >But all of this *is* in ATrpms :) > > > >You need a depsolver (apt/yum/smart/up2date) and point it to the > >stable repo at ATrpms for FC1. Then simply issue something like > > Can you help me here? What can I put into my yum.conf file to > point to it? Something like [atrpms] name=Fedora Core 1 - i386 - ATrpms baseurl=http://dl.atrpms.net/fc1-i386/atrpms/stable > >smart update && smart install spamassassin > > So if I type "yum update spamassassin", it should grab all the others, > correct? Or yum install spamassassin. I'm not sure, but depending on your yum version yum update xxx could mean to update everything (check the man page). > >All these further packages enhance spamassassin in one way or another, > >especially by allowing it to effectively compare the mail to be > >examined against network databases of known spam and thus getting a > >more precise spam scoring. > > Ahhh, I like that. OK, I'm game to try. Can you help me a bit here with > the above questions? -- 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 mike.mccarty at sbcglobal.net Fri Sep 9 19:11:14 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 09 Sep 2005 14:11:14 -0500 Subject: Subscribed properly? In-Reply-To: References: <431F5B0F.4030703@sbcglobal.net> <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> <432077E5.4000601@sbcglobal.net> Message-ID: <4321DE52.40808@sbcglobal.net> Nils Breunese (Lemonbit Internet) wrote: > Mike wrote: > [snip yum.conf] > > > Hm, well, that looks just fine actually. You might want to name the Erm, did you notice I exclude kernel* ? [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkosin at beta.intcomgrp.com Fri Sep 9 20:53:36 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 09 Sep 2005 16:53:36 -0400 Subject: [FC1] James' Updates In-Reply-To: <4321B6AE.9070708@beta.intcomgrp.com> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <4321B6AE.9070708@beta.intcomgrp.com> Message-ID: <4321F650.7070202@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 James Kosin wrote: | Gilbert Sebenste wrote: | | | On Fri, 9 Sep 2005, HaJo Schatz wrote: | | | |> James, I truly appreciate your efforts to get latest versions of | |> critical packages out. | |> | |> However, | |> [...] | |> | |>> SpamAssassin 3.0.4 | |>> ------------------ | |> | |> [...] | |> | |> I'd suggest you have a look at Axel Thimm's atrpms archive. He has | |> quite a few packages up-to-date for legacy RH/Fedora releases. | |> Among them, he has released SA 3.0.4 quite a long time ago. Might | |> save you some time for other packages ;-) | | | | | | That Spamassassin doesn't work on FC1. Tried it, bombed with a bunch | | of incompatibility errors. However... | | | | James, when I restart spamassassin in /etc/rc.d/init.d, I get: | | | | Starting spamd: The -a option has been removed. Please look at the | | use_auto_whitelist config option instead. [ FAILED] | | | | I don't see a "-a" option in my /etc/rc.d/init.d/spamassassin file. | | Any ideas? | | | | | ******************************************************************************* | | | | | Gilbert | Sebenste | ******** | | (My opinions | only!) | ****** | | Staff Meteorologist, Northern Illinois | | University **** | | E-mail: | | sebenste at weather.admin.niu.edu *** | | web: | | http://weather.admin.niu.edu ** | | | ******************************************************************************* | | | | | | | -- | | fedora-legacy-list mailing list | | fedora-legacy-list at redhat.com | | http://www.redhat.com/mailman/listinfo/fedora-legacy-list | | I'll look into in when I get back! | Got school now and lunch. | | James I've got a version now with the document fixes. I took the '-a' option out of the /etc/sysconfig/spamassassin file; although, it is a noreplace file in the install script meaning any settings will not be touched when upgrading. http://support.intcomgrp.com/mirror/fedora-core/beta/i386/spamassassin-3.0.4-1.fc1.i386.rpm Let me know if the '-a' problem was the only one. Or if you go with ATrpms version.... kindly post any problems to them. They have a good bugzilla page. I may be asking Axel later for submitting some of my packages to him.... Like gcc / etc for use. I haven't had time to install / configure bugzilla for FC1 as of yet. Thanks, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIfZPkNLDmnu1kSkRA9UbAJwNdWDCjXmK3CAtLGp37iRz9xAlsQCeM8Rg pfCc/H/y1ZpZGLv7frR2kDs= =GpRX -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From nils at lemonbit.nl Sat Sep 10 11:46:35 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sat, 10 Sep 2005 13:46:35 +0200 Subject: Subscribed properly? In-Reply-To: <4321DE52.40808@sbcglobal.net> References: <431F5B0F.4030703@sbcglobal.net> <9C40C29D-DBA8-4218-A653-BDFC4BD6E2DA@lemonbit.nl> <432077E5.4000601@sbcglobal.net> <4321DE52.40808@sbcglobal.net> Message-ID: <97AC0A9C-144D-4AAD-86E5-62612A645896@lemonbit.nl> Mike wrote: >> Hm, well, that looks just fine actually. You might want to name the > > Erm, did you notice I exclude kernel* ? Yes, there can be good reasons for that and shouldn't keep you from getting updates (except kernel updates of course) Nils. From sebenste at weather.admin.niu.edu Tue Sep 13 15:38:34 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Tue, 13 Sep 2005 10:38:34 -0500 (CDT) Subject: James' Updates In-Reply-To: <20050909173613.GA28024@neu.nirvana> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> <20050909173613.GA28024@neu.nirvana> Message-ID: On Fri, 9 Sep 2005, Axel Thimm wrote: >> Can you help me here? What can I put into my yum.conf file to >> point to it? > > Something like > > [atrpms] > name=Fedora Core 1 - i386 - ATrpms > baseurl=http://dl.atrpms.net/fc1-i386/atrpms/stable When I do this, is says dependencies are needed and won't update anything. conflict between fontconfig and fonts-hebrew: Package tix needs libitcl3.2.so, this is not available. Package tix needs libitk3.2.so, this is not available. Package tix needs itcl.so, this is not available. ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From Axel.Thimm at ATrpms.net Tue Sep 13 22:48:20 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Sep 2005 00:48:20 +0200 Subject: James' Updates In-Reply-To: References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> <20050909173613.GA28024@neu.nirvana> Message-ID: <20050913224820.GA3438@neu.nirvana> On Tue, Sep 13, 2005 at 10:38:34AM -0500, Gilbert Sebenste wrote: > On Fri, 9 Sep 2005, Axel Thimm wrote: > > >>Can you help me here? What can I put into my yum.conf file to > >>point to it? > > > >Something like > > > >[atrpms] > >name=Fedora Core 1 - i386 - ATrpms > >baseurl=http://dl.atrpms.net/fc1-i386/atrpms/stable > > When I do this, is says dependencies are needed and won't update anything. > > conflict between fontconfig and fonts-hebrew: > > Package tix needs libitcl3.2.so, this is not available. > Package tix needs libitk3.2.so, this is not available. > Package tix needs itcl.so, this is not available. you probably need to update yum first. Early yum versions would easily mask existing packages under certain circumstances. The dependencies are part of itcl, which is part of the stable repo: apt-get install libitcl3.2.so Reading Package Lists... Done Building Dependency Tree... Done Selecting itcl for 'libitcl3.2.so' The following extra packages will be installed: XFree86-Mesa-libGL XFree86-libs XFree86-libs-data freetype itcl libfontconfig1 libfreetype6 libttf2 tcl83 tk83 The following NEW packages will be installed: XFree86-Mesa-libGL XFree86-libs XFree86-libs-data freetype itcl libfontconfig1 libfreetype6 libttf2 tcl83 tk83 0 upgraded, 10 newly installed, 0 removed and 0 not upgraded. Need to get 0B/6943kB of archives. After unpacking 18.5MB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. -- 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 sebenste at weather.admin.niu.edu Tue Sep 13 23:29:11 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Tue, 13 Sep 2005 18:29:11 -0500 (CDT) Subject: James' Updates In-Reply-To: <20050913224820.GA3438@neu.nirvana> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> <20050909173613.GA28024@neu.nirvana> <20050913224820.GA3438@neu.nirvana> Message-ID: On Wed, 14 Sep 2005, Axel Thimm wrote: > you probably need to update yum first. Early yum versions would easily > mask existing packages under certain circumstances. > I have the FC1 version. Where can I get the latest version for that? Do you have it? ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From micoots at yahoo.com Wed Sep 14 00:31:19 2005 From: micoots at yahoo.com (Michael Mansour) Date: Wed, 14 Sep 2005 10:31:19 +1000 (EST) Subject: James' Updates In-Reply-To: Message-ID: <20050914003119.69800.qmail@web30208.mail.mud.yahoo.com> Hi Gilbert, --- Gilbert Sebenste wrote: > On Wed, 14 Sep 2005, Axel Thimm wrote: > > > you probably need to update yum first. Early yum > versions would easily > > mask existing packages under certain > circumstances. > > > I have the FC1 version. Where can I get the latest > version for that? > Do you have it? I've recently gone through and upgraded a series of FC1 servers to the latest yum version supplied by atrpms: yum-2.3.4-62.rhfc1.at and apart from modifying the cachedir line in the yum.conf file, and adding the dag.repo file in the yum.repos.d directory, that was all that was involved. Michael. Send instant messages to your online friends http://au.messenger.yahoo.com From marcdeslauriers at videotron.ca Thu Sep 15 02:00:25 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 14 Sep 2005 22:00:25 -0400 Subject: Fedora Legacy Test Update Notification: glibc Message-ID: <4328D5B9.9010608@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152848 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152848 2005-09-14 --------------------------------------------------------------------- Name : glibc Versions : rh73: glibc-2.2.5-44.legacy.6 Versions : rh9: glibc-2.3.2-27.9.7.2.legacy Versions : fc1: glibc-2.3.2-101.4.2.legacy Versions : fc2: glibc-2.3.3-27.1.1.legacy Summary : The GNU libc libraries. Description : The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code is kept in one place and shared between programs. This particular package contains the most important sets of shared libraries: the standard C library and the standard math library. Without these two libraries, a Linux system will not function. --------------------------------------------------------------------- Update Information: Updated glibc packages that address several bugs are now available. The GNU libc packages (known as glibc) contain the standard C libraries used by applications. Flaws in the catchsegv and glibcbug scripts were discovered. A local user could utilize these flaws to overwrite files via a symlink attack on temporary files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0968 and CAN-2004-1382 to these issues. It was discovered that the use of LD_DEBUG and LD_SHOW_AUXV were not restricted for a setuid program. A local user could utilize this flaw to gain information, such as the list of symbols used by the program. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1453 to this issue. Users of glibc are advised to upgrade to these erratum packages that remove the unecessary glibcbug script and contain backported patches to correct these other issues. --------------------------------------------------------------------- Changelogs rh73: * Mon Aug 15 2005 Pekka Savola 2.2.4-44.legacy.6 - fix i686 build issue (a couple of misplaced extra %patch lines) * Sun May 01 2005 Pekka Savola 2.2.4-44.legacy.5 - add glibc-2.2.4-nscd-hstcache.patch to fix gethostbyaddr/gethostbyname caching issues, #156048. Patch from RHEL21. * Sat Apr 30 2005 Pekka Savola 2.2.4-44.legacy.4 - fix CAN-2004-0968, CAN-2004-1382, and CAN-2004-1453 (#152848) rh9: * Sat Apr 30 2005 Pekka Savola 2.3.2-27.9.7.1.legacy - fix CAN-2004-0968, CAN-2004-1382, and CAN-2004-1453 (#152848) - Unbreak IPv6 reverse lookups, broken by errata 2.3.2-27.9.2 fc1: * Sat Apr 30 2005 Pekka Savola 2.3.2-101.4.1.legacy - fix CAN-2004-0968, CAN-2004-1382, and CAN-2004-1453 (#152848) - Unbreak IPv6 reverse lookups, broken by errata 2.3.2-27.9.2 fc2: * Wed Jul 20 2005 Pekka Savola 2.3.3-27.1.1.legacy - Fix LD_DEBUG leak (CAN-2004-1453), #152848 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 76bcec5fdd862df2fffaeeaeacbfcd8c53dd6a28 redhat/7.3/updates-testing/i386/glibc-2.2.5-44.legacy.6.i386.rpm 79dd43763e464959889867bb5f28c0935d31e401 redhat/7.3/updates-testing/i386/glibc-2.2.5-44.legacy.6.i686.rpm f83509fe544e517cfa5f40829b2921155eed6930 redhat/7.3/updates-testing/i386/glibc-common-2.2.5-44.legacy.6.i386.rpm a4065db0ddfcec1a95dade4756b7af76da487059 redhat/7.3/updates-testing/i386/glibc-debug-2.2.5-44.legacy.6.i386.rpm a88e249e0747927d7b0607f24202f4772c2f5f51 redhat/7.3/updates-testing/i386/glibc-debug-2.2.5-44.legacy.6.i686.rpm bbd6858e1409960769b945af03f13e0732b35ec2 redhat/7.3/updates-testing/i386/glibc-debug-static-2.2.5-44.legacy.6.i386.rpm 4f76f3f2267edb91ac130ad18942b34741314914 redhat/7.3/updates-testing/i386/glibc-devel-2.2.5-44.legacy.6.i386.rpm 3996fc2d6e306a127d03d468bde83e821b6ca2f9 redhat/7.3/updates-testing/i386/glibc-profile-2.2.5-44.legacy.6.i386.rpm 2916fbe09c40b3961add814aaebda7e651799342 redhat/7.3/updates-testing/i386/glibc-utils-2.2.5-44.legacy.6.i386.rpm 2250cf7ccb19268cc5b103d17512f877a1e9756d redhat/7.3/updates-testing/i386/nscd-2.2.5-44.legacy.6.i386.rpm d3178ba384c31d0e4b53b7c79f8c1f3d4f2e63c2 redhat/7.3/updates-testing/SRPMS/glibc-2.2.5-44.legacy.6.src.rpm rh9: 6b01d43cc41177a83c765862be0e3802df307c61 redhat/9/updates-testing/i386/glibc-2.3.2-27.9.7.2.legacy.i386.rpm b4c28abc5d318f53f22772bc069665adc4f9d5f3 redhat/9/updates-testing/i386/glibc-2.3.2-27.9.7.2.legacy.i686.rpm 8ea462b77d16513f0623409219cb297fa95fe6ba redhat/9/updates-testing/i386/glibc-common-2.3.2-27.9.7.2.legacy.i386.rpm 94c1f526eed545959a9b60ac79deef88c0c5c9a0 redhat/9/updates-testing/i386/glibc-debug-2.3.2-27.9.7.2.legacy.i386.rpm b8fe3480b249761c468d4019c3b9ac0358068475 redhat/9/updates-testing/i386/glibc-devel-2.3.2-27.9.7.2.legacy.i386.rpm a01030615e5b874b4225e9cad4e1c9ccc2f4bb33 redhat/9/updates-testing/i386/glibc-profile-2.3.2-27.9.7.2.legacy.i386.rpm d20ce4f39ed7ffc6c8cb81c8a84b229a2158d81e redhat/9/updates-testing/i386/glibc-utils-2.3.2-27.9.7.2.legacy.i386.rpm e20b1e22cfbc1c0eed675b6b6d99ca8d0213f725 redhat/9/updates-testing/i386/nptl-devel-2.3.2-27.9.7.2.legacy.i686.rpm 8684b6e78d7230f8708e5e2a016264baf6ab7ac7 redhat/9/updates-testing/i386/nscd-2.3.2-27.9.7.2.legacy.i386.rpm 5afb7ec9ec9f9b3bb36d372104ec647d7c6d9ebb redhat/9/updates-testing/SRPMS/glibc-2.3.2-27.9.7.2.legacy.src.rpm fc1: ef743504f28c797cd9a807dd8a769a837eda8525 fedora/1/updates-testing/i386/glibc-2.3.2-101.4.2.legacy.i386.rpm c3dd3abcc811671d63f6033e3ed3ee9806ad0f93 fedora/1/updates-testing/i386/glibc-2.3.2-101.4.2.legacy.i686.rpm cf814c1e573db45e76b63bce49b40876fdd42e28 fedora/1/updates-testing/i386/glibc-common-2.3.2-101.4.2.legacy.i386.rpm 4af7cb248abe614adace704520ab969717d8056b fedora/1/updates-testing/i386/glibc-debug-2.3.2-101.4.2.legacy.i386.rpm 00809ff8abcf096091592e065dbc859a1fc413bd fedora/1/updates-testing/i386/glibc-devel-2.3.2-101.4.2.legacy.i386.rpm 8417a8697d7929e866cd48be44bcd4e9b29ef8a2 fedora/1/updates-testing/i386/glibc-headers-2.3.2-101.4.2.legacy.i386.rpm 309bb357b23d00d858b73a132af556862ce735fc fedora/1/updates-testing/i386/glibc-profile-2.3.2-101.4.2.legacy.i386.rpm c7add2f20742acab29c47ec7f42bc789d6111aec fedora/1/updates-testing/i386/glibc-utils-2.3.2-101.4.2.legacy.i386.rpm 5108e73e4fce7fda4c383a5f4a360a2ec3632a4e fedora/1/updates-testing/i386/nptl-devel-2.3.2-101.4.2.legacy.i686.rpm ca70e82a96ad014145357feb9b8b3222314afd7e fedora/1/updates-testing/i386/nscd-2.3.2-101.4.2.legacy.i386.rpm 30cec9b26bb5341afbb6b7698b3c092e395acb65 fedora/1/updates-testing/SRPMS/glibc-2.3.2-101.4.2.legacy.src.rpm fc2: 9ea2cf3d307635ed6be265077ec9594d73030c71 fedora/2/updates-testing/i386/glibc-2.3.3-27.1.1.legacy.i386.rpm 120833cba0615427157a51f69a6e73403f788667 fedora/2/updates-testing/i386/glibc-2.3.3-27.1.1.legacy.i686.rpm d3c27007cab83e778ba7ba5c752077b865c7d618 fedora/2/updates-testing/i386/glibc-common-2.3.3-27.1.1.legacy.i386.rpm ccc5d22e66a7c435b0e1008704ee16856e4717ec fedora/2/updates-testing/i386/glibc-devel-2.3.3-27.1.1.legacy.i386.rpm b11bd48eee48b1b2fd6cc9d52bbbc01247533bb0 fedora/2/updates-testing/i386/glibc-headers-2.3.3-27.1.1.legacy.i386.rpm 2a3c79e2f428742dfef1f15a1bbc64a80c48491e fedora/2/updates-testing/i386/glibc-profile-2.3.3-27.1.1.legacy.i386.rpm 081977a5f9cd0812cd1db6230ff51782d17c83e0 fedora/2/updates-testing/i386/glibc-utils-2.3.3-27.1.1.legacy.i386.rpm be2cc7c357c799a8ad8288e3c99d9c53ea89692e fedora/2/updates-testing/i386/nptl-devel-2.3.3-27.1.1.legacy.i686.rpm d1a9e1c189d58b74a318dd1908cf6b9c0202ac9b fedora/2/updates-testing/i386/nscd-2.3.3-27.1.1.legacy.i386.rpm baafd5d75a788cc578f24fb83280052f3b8422db fedora/2/updates-testing/SRPMS/glibc-2.3.3-27.1.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 Thu Sep 15 02:01:16 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 14 Sep 2005 22:01:16 -0400 Subject: [FLSA-2005:163274] Updated CUPS packages fix security issue Message-ID: <4328D5EC.8010803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated CUPS packages fix security issue Advisory ID: FLSA:163274 Issue date: 2005-09-14 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2005-2154 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated CUPS packages that fix a security issue are now available. The Common UNIX Printing System provides a portable printing layer for UNIX(R) operating systems. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: When processing a request, the CUPS scheduler would use case-sensitive matching on the queue name to decide which authorization policy should be used. However, queue names are not case-sensitive. An unauthorized user could print to a password-protected queue without needing a password. The Common Vulnerabilities and Exposures project has assigned the name CAN-2005-2154 to this issue. All users of CUPS should upgrade to these erratum packages which contain a backported patch to correct this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163274 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cups-1.1.14-15.4.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-1.1.14-15.4.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-devel-1.1.14-15.4.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-libs-1.1.14-15.4.5.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cups-1.1.17-13.3.0.14.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cups-1.1.17-13.3.0.14.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/cups-devel-1.1.17-13.3.0.14.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/cups-libs-1.1.17-13.3.0.14.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/cups-1.1.19-13.9.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/cups-1.1.19-13.9.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/cups-devel-1.1.19-13.9.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/cups-libs-1.1.19-13.9.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/cups-1.1.20-11.11.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/cups-1.1.20-11.11.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cups-devel-1.1.20-11.11.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/cups-libs-1.1.20-11.11.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 0c703164c4314cc91e31a859ed8e149e4249bd68 redhat/7.3/updates/i386/cups-1.1.14-15.4.5.legacy.i386.rpm 62414dc09ab8e240f92fe476dc272d227ba223ce redhat/7.3/updates/i386/cups-devel-1.1.14-15.4.5.legacy.i386.rpm 4bce41d4c0323700d3a78adf21bb3ff0790cbe44 redhat/7.3/updates/i386/cups-libs-1.1.14-15.4.5.legacy.i386.rpm 2fa58515d46929fe6116c8c72e50c26b8313c504 redhat/7.3/updates/SRPMS/cups-1.1.14-15.4.5.legacy.src.rpm 4d6585d937c4855c8d999bc292d17e13258d5cb5 redhat/9/updates/i386/cups-1.1.17-13.3.0.14.legacy.i386.rpm 445a0332fff4b09cd2c4f8d7643fb12213498608 redhat/9/updates/i386/cups-devel-1.1.17-13.3.0.14.legacy.i386.rpm d65b045173aba91de7fa2d44217ba6d939a775a3 redhat/9/updates/i386/cups-libs-1.1.17-13.3.0.14.legacy.i386.rpm 35bf3fdafd340588d4c8f167709d53bcc2eb6ff4 redhat/9/updates/SRPMS/cups-1.1.17-13.3.0.14.legacy.src.rpm 97265e88f58dde6d0a9956ef9de0fce61c256077 fedora/1/updates/i386/cups-1.1.19-13.9.legacy.i386.rpm cb73c7d7e91cff10fab3c11a63dbcb002f1242d9 fedora/1/updates/i386/cups-devel-1.1.19-13.9.legacy.i386.rpm d3ae92680bbadfa11ce5f0c92c8243950e92d441 fedora/1/updates/i386/cups-libs-1.1.19-13.9.legacy.i386.rpm 244deb8d82130ecc23e143574cee05bda29d9e7c fedora/1/updates/SRPMS/cups-1.1.19-13.9.legacy.src.rpm 1973c00db116e6f20afb96acfc3f98d240ac1b1e fedora/2/updates/i386/cups-1.1.20-11.11.2.legacy.i386.rpm 0a6c53922499dc4a5917e25660478c25921752a7 fedora/2/updates/i386/cups-devel-1.1.20-11.11.2.legacy.i386.rpm 5989d3bc71592333e6dba34d37b2251e776b7318 fedora/2/updates/i386/cups-libs-1.1.20-11.11.2.legacy.i386.rpm e3fd4d455daaee834ab6b1888454b082a56d52ea fedora/2/updates/SRPMS/cups-1.1.20-11.11.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2154 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Sep 15 02:01:53 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 14 Sep 2005 22:01:53 -0400 Subject: [FLSA-2005:163047] Updated squirrelmail package fixes security issues Message-ID: <4328D611.4060308@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated squirrelmail package fixes security issues Advisory ID: FLSA:163047 Issue date: 2005-09-14 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2005-1769 CAN-2005-2095 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated squirrelmail package that fixes two security issues is now available. SquirrelMail is a standards-based webmail package written in PHP4. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A bug was found in the way SquirrelMail handled the $_POST variable. If a user is tricked into visiting a malicious URL, the user's SquirrelMail preferences could be read or modified. The Common Vulnerabilities and Exposures project assigned the name CAN-2005-2095 to this issue. Several cross-site scripting bugs were discovered in SquirrelMail. An attacker could inject arbitrary Javascript or HTML content into SquirrelMail pages by tricking a user into visiting a carefully crafted URL, or by sending them a carefully constructed HTML email message. The Common Vulnerabilities and Exposures project assigned the name CAN-2005-1769 to this issue. All users of SquirrelMail should upgrade to this updated package, which contains backported patches that resolve these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163047 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/squirrelmail-1.4.3-0.f0.9.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/squirrelmail-1.4.3-0.f0.9.6.legacy.noarch.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/squirrelmail-1.4.3-0.f1.1.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/squirrelmail-1.4.3-0.f1.1.5.legacy.noarch.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/squirrelmail-1.4.4-1.FC2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/squirrelmail-1.4.4-1.FC2.2.legacy.noarch.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 5182c295693a72d9602945a5985c39c125f2b422 redhat/9/updates/i386/squirrelmail-1.4.3-0.f0.9.6.legacy.noarch.rpm 1aec842c861408106c2818cf4c58caf762367230 redhat/9/updates/SRPMS/squirrelmail-1.4.3-0.f0.9.6.legacy.src.rpm 10dcfc4975cbe049df638ff43304e0a6a22f58a2 fedora/1/updates/i386/squirrelmail-1.4.3-0.f1.1.5.legacy.noarch.rpm 5f0c54493ae619de8a85813947470bfedd5415f2 fedora/1/updates/SRPMS/squirrelmail-1.4.3-0.f1.1.5.legacy.src.rpm 83e7c1b6a1f070894be5456b3dd850b3a6f090b2 fedora/2/updates/i386/squirrelmail-1.4.4-1.FC2.2.legacy.noarch.rpm de4f2ef84e23b310f7f845ee8624360dadb7b74d fedora/2/updates/SRPMS/squirrelmail-1.4.4-1.FC2.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1769 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2095 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Sep 15 02:02:32 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 14 Sep 2005 22:02:32 -0400 Subject: [FLSA-2005:162680] Updated Zlib packagea fix security issues Message-ID: <4328D638.50600@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated Zlib packagea fix security issues Advisory ID: FLSA:162680 Issue date: 2005-09-14 Product: Fedora Core Keywords: Bugfix CVE Names: CAN-2005-1849 CAN-2005-2096 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated Zlib packages that fix buffer overflows are now available. Zlib is a general-purpose lossless data compression library which is used by many different programs. 2. Relevant releases/architectures: Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Tavis Ormandy discovered a buffer overflow affecting Zlib version 1.2 and above. An attacker could create a carefully crafted compressed stream that would cause an application to crash if the stream is opened by a user. As an example, an attacker could create a malicious PNG image file which would cause a web browser or mail viewer to crash if the image is viewed. The Common Vulnerabilities and Exposures project assigned the name CAN-2005-2096 to this issue. Markus Oberhumer discovered additional ways a stream could trigger an overflow. An attacker could create a carefully crafted compressed stream that would cause an application to crash if the stream is opened by a user. As an example, an attacker could create a malicious PNG image file that would cause a Web browser or mail viewer to crash if the image is viewed. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2005-1849 to this issue. All users should update to these erratum packages which contain a patch from Mark Adler which corrects this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162680 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/zlib-1.2.0.7-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/zlib-1.2.0.7-2.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/zlib-devel-1.2.0.7-2.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/zlib-1.2.1.2-0.fc2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/zlib-1.2.1.2-0.fc2.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/zlib-devel-1.2.1.2-0.fc2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- f242225e07d39648b0d7d6558150285ddf7f62d8 fedora/1/updates/i386/zlib-1.2.0.7-2.3.legacy.i386.rpm 618d744e5a8f9a895b40f952a8593985c93fd6d6 fedora/1/updates/i386/zlib-devel-1.2.0.7-2.3.legacy.i386.rpm c812abcd0c5bcfccc86573e81d68ebff5b615ded fedora/1/updates/SRPMS/zlib-1.2.0.7-2.3.legacy.src.rpm d07c43de860f476302fcd1fc82d18db1835e1ba1 fedora/2/updates/i386/zlib-1.2.1.2-0.fc2.2.legacy.i386.rpm f3326c134c6346ca8f120d86d28908ad45907bf9 fedora/2/updates/i386/zlib-devel-1.2.1.2-0.fc2.2.legacy.i386.rpm 2d288f7b2dd848a4c3f36d3ff7c200b9b629c868 fedora/2/updates/SRPMS/zlib-1.2.1.2-0.fc2.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Thu Sep 15 02:03:09 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 14 Sep 2005 22:03:09 -0400 Subject: [FLSA-2005:160202] Updated mozilla packages fix security issues Message-ID: <4328D65D.6090306@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated mozilla packages fix security issues Advisory ID: FLSA:160202 Issue date: 2005-09-14 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2005-2260 CAN-2005-2261 CAN-2005-2263 CAN-2005-2265 CAN-2005-1937 CAN-2005-2266 CAN-2005-2267 CAN-2005-2268 CAN-2005-2269 CAN-2005-2270 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated mozilla packages that fix various security issues are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A bug was found in the way Mozilla handled synthetic events. It is possible that Web content could generate events such as keystrokes or mouse clicks that could be used to steal data or execute malicious Javascript code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-2260 to this issue. A bug was found in the way Mozilla executed Javascript in XBL controls. It is possible for a malicious webpage to leverage this vulnerability to execute other JavaScript based attacks even when JavaScript is disabled. (CAN-2005-2261) A bug was found in the way Mozilla installed its extensions. If a user can be tricked into visiting a malicious webpage, it may be possible to obtain sensitive information such as cookies or passwords. (CAN-2005-2263) A bug was found in the way Mozilla handled certain Javascript functions. It is possible for a malicious webpage to crash the browser by executing malformed Javascript code. (CAN-2005-2265) A bug was found in the way Mozilla handled multiple frame domains. It is possible for a frame as part of a malicious website to inject content into a frame that belongs to another domain. This issue was previously fixed as CAN-2004-0718 but was accidentally disabled. (CAN-2005-1937) A bug was found in the way Mozilla handled child frames. It is possible for a malicious framed page to steal sensitive information from its parent page. (CAN-2005-2266) A bug was found in the way Mozilla opened URLs from media players. If a media player opens a URL which is Javascript, the Javascript executes with access to the currently open webpage. (CAN-2005-2267) A design flaw was found in the way Mozilla displayed alerts and prompts. Alerts and prompts were given the generic title [JavaScript Application] which prevented a user from knowing which site created them. (CAN-2005-2268) A bug was found in the way Mozilla handled DOM node names. It is possible for a malicious site to overwrite a DOM node name, allowing certain privileged chrome actions to execute the malicious Javascript. (CAN-2005-2269) A bug was found in the way Mozilla cloned base objects. It is possible for Web content to traverse the prototype chain to gain access to privileged chrome objects. (CAN-2005-2270) Users of Mozilla are advised to upgrade to these updated packages, which contain Mozilla version 1.7.10 and are not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160202 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mozilla-1.7.10-0.73.1.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/galeon-1.2.14-0.73.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-chat-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-devel-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-js-debugger-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-mail-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-devel-1.7.10-0.73.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/galeon-1.2.14-0.73.4.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mozilla-1.7.10-0.90.1.legacy.src.rpm http://download.fedoralegacy.org/redhat/9/updates/SRPMS/galeon-1.2.14-0.90.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-chat-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-devel-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-dom-inspector-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-js-debugger-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-mail-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-devel-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nss-devel-1.7.10-0.90.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/galeon-1.2.14-0.90.4.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mozilla-1.7.10-1.1.1.legacy.src.rpm http://download.fedoralegacy.org/fedora/1/updates/SRPMS/epiphany-1.0.8-1.fc1.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-chat-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-devel-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-dom-inspector-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-js-debugger-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-mail-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nspr-devel-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mozilla-nss-devel-1.7.10-1.1.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/epiphany-1.0.8-1.fc1.4.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/mozilla-1.7.10-1.2.1.legacy.src.rpm http://download.fedoralegacy.org/fedora/2/updates/SRPMS/epiphany-1.2.10-0.2.5.legacy.src.rpm http://download.fedoralegacy.org/fedora/2/updates/SRPMS/devhelp-0.9.1-0.2.8.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-chat-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-devel-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-dom-inspector-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-js-debugger-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-mail-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nspr-devel-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/mozilla-nss-devel-1.7.10-1.2.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/epiphany-1.2.10-0.2.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/devhelp-0.9.1-0.2.8.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/devhelp-devel-0.9.1-0.2.8.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 21ef0fc3fb4a4b1bab035a3ca39f05793980f96c redhat/7.3/updates/i386/mozilla-1.7.10-0.73.1.legacy.i386.rpm bd577e6f2da710d29e4b80178c06824dc49f777e redhat/7.3/updates/i386/mozilla-chat-1.7.10-0.73.1.legacy.i386.rpm ead8a39e3bf89266c46ad4416b7089b1685c1611 redhat/7.3/updates/i386/mozilla-devel-1.7.10-0.73.1.legacy.i386.rpm f3cbc0d33c063472bd02836c5bb6fa1358a07144 redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.10-0.73.1.legacy.i386.rpm d80e8e4ca42908fcddb3fe210ca7e3239572d645 redhat/7.3/updates/i386/mozilla-js-debugger-1.7.10-0.73.1.legacy.i386.rpm cd099e3c6886784093ab23fc4217c3d9c8202ddc redhat/7.3/updates/i386/mozilla-mail-1.7.10-0.73.1.legacy.i386.rpm 7423c24f838e81e69f14363324bebad96c87bf87 redhat/7.3/updates/i386/mozilla-nspr-1.7.10-0.73.1.legacy.i386.rpm 1b4d201829286b23cf6f86068e82e1f116f5e238 redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.10-0.73.1.legacy.i386.rpm afce419aeac48067ec55ba4c54b75a96b84ae248 redhat/7.3/updates/i386/mozilla-nss-1.7.10-0.73.1.legacy.i386.rpm 9e2b0fc1e17b6a014fb78b1d4ed73aa9b33a6998 redhat/7.3/updates/i386/mozilla-nss-devel-1.7.10-0.73.1.legacy.i386.rpm a055ace074f9d074f8dc24b8467ef03ab2a4f56d redhat/7.3/updates/SRPMS/mozilla-1.7.10-0.73.1.legacy.src.rpm 9e617122c902d6a41fe8ab5a7541c6ad7d7a4274 redhat/7.3/updates/i386/galeon-1.2.14-0.73.4.legacy.i386.rpm 9a09d9823313a758f7d73631e46d5fd44f018a04 redhat/7.3/updates/SRPMS/galeon-1.2.14-0.73.4.legacy.src.rpm 361bb85b2bd856bb6f75a2067ca9f8b64740d55e redhat/9/updates/i386/mozilla-1.7.10-0.90.1.legacy.i386.rpm 5b5331a02a50612518a9b04e8e25e1f0e61afbc9 redhat/9/updates/i386/mozilla-chat-1.7.10-0.90.1.legacy.i386.rpm 1cef67b7101ca5ef94c2da52cf7e6fa1904ddab7 redhat/9/updates/i386/mozilla-devel-1.7.10-0.90.1.legacy.i386.rpm ebfd6b8d96a12c32c8c32cd06a0eb29ce44ebd9c redhat/9/updates/i386/mozilla-dom-inspector-1.7.10-0.90.1.legacy.i386.rpm 00a5dc6a4da814c68efa0e6f0bebaeb2e5af43e4 redhat/9/updates/i386/mozilla-js-debugger-1.7.10-0.90.1.legacy.i386.rpm 3cff356510a48956b0ce9e7ab7cc158da2f37906 redhat/9/updates/i386/mozilla-mail-1.7.10-0.90.1.legacy.i386.rpm 998feb261e696dcd5a08cfd2d884b30063944f78 redhat/9/updates/i386/mozilla-nspr-1.7.10-0.90.1.legacy.i386.rpm 12d4caa735df18edaf636d30de98ab41b0c394ac redhat/9/updates/i386/mozilla-nspr-devel-1.7.10-0.90.1.legacy.i386.rpm e20f1d5b4111a23b1f6ec30547ebd447c2c9eb54 redhat/9/updates/i386/mozilla-nss-1.7.10-0.90.1.legacy.i386.rpm 815236f90f4778e52a364ae4795b762f95b11909 redhat/9/updates/i386/mozilla-nss-devel-1.7.10-0.90.1.legacy.i386.rpm 49801c7d362ba0e659096516f7dc89960aaba5ab redhat/9/updates/SRPMS/mozilla-1.7.10-0.90.1.legacy.src.rpm abd5ff8e4e92dacc43cd8ddbb88061bee410a965 redhat/9/updates/i386/galeon-1.2.14-0.90.4.legacy.i386.rpm f252f4ec0b3132199e30362b5aa12fcf70345708 redhat/9/updates/SRPMS/galeon-1.2.14-0.90.4.legacy.src.rpm 024af661649ccdd80f61cdbcd67405146ddd290e fedora/1/updates/i386/mozilla-1.7.10-1.1.1.legacy.i386.rpm c714508dfbf5194b518ab8c36ef15e35b5f9f34d fedora/1/updates/i386/mozilla-chat-1.7.10-1.1.1.legacy.i386.rpm 9f87a7c1b15b1eacf77d785ba02a6e5272786483 fedora/1/updates/i386/mozilla-devel-1.7.10-1.1.1.legacy.i386.rpm 40d6a447c6fa50971449a12ed04d2139e7f38c86 fedora/1/updates/i386/mozilla-dom-inspector-1.7.10-1.1.1.legacy.i386.rpm 7d7993584caf000376d414adfea09ef03b5dcfcc fedora/1/updates/i386/mozilla-js-debugger-1.7.10-1.1.1.legacy.i386.rpm ddb668ea5ef6354bcea561d396f322b812986d3c fedora/1/updates/i386/mozilla-mail-1.7.10-1.1.1.legacy.i386.rpm ba21eee7662528448aeab774f9f1eedcd27bef6e fedora/1/updates/i386/mozilla-nspr-1.7.10-1.1.1.legacy.i386.rpm 6fc9017c5f1712648f83f74dfc289097244bf2fb fedora/1/updates/i386/mozilla-nspr-devel-1.7.10-1.1.1.legacy.i386.rpm b16af5524e6b5ae6d00b978aa7ae7e382045e42a fedora/1/updates/i386/mozilla-nss-1.7.10-1.1.1.legacy.i386.rpm fe6babcc981d3d8d00405bc668a163c762325556 fedora/1/updates/i386/mozilla-nss-devel-1.7.10-1.1.1.legacy.i386.rpm b897549c97460c0c77cb7cd2a5cc09fa2b87e648 fedora/1/updates/SRPMS/mozilla-1.7.10-1.1.1.legacy.src.rpm 8e927ac2f8ef17d3d33a5f244944c8e23bd349a5 fedora/1/updates/i386/epiphany-1.0.8-1.fc1.4.legacy.i386.rpm e7269e1c82160199d9922ee85116ca6c3b968aa4 fedora/1/updates/SRPMS/epiphany-1.0.8-1.fc1.4.legacy.src.rpm 84191565518894d9064043591f6bd8a87aadf7c1 fedora/2/updates/i386/mozilla-1.7.10-1.2.1.legacy.i386.rpm 840981293c815a81a1e2731cb70890fdcf4a9439 fedora/2/updates/i386/mozilla-chat-1.7.10-1.2.1.legacy.i386.rpm c8239468a1ee288b4a4c476d3499e2dd21f9e15f fedora/2/updates/i386/mozilla-devel-1.7.10-1.2.1.legacy.i386.rpm ead0223ae156bc10bc98d7b3e2b3d73fe295a3b8 fedora/2/updates/i386/mozilla-dom-inspector-1.7.10-1.2.1.legacy.i386.rpm 8f8ce4d865ca4f1a39044c5be16aa3226c379336 fedora/2/updates/i386/mozilla-js-debugger-1.7.10-1.2.1.legacy.i386.rpm f7f86824465f7cefb863edd0185a1d10dd1a9e5b fedora/2/updates/i386/mozilla-mail-1.7.10-1.2.1.legacy.i386.rpm 6ddbbe1bf072839e4d614f875c4bf2b9e613c252 fedora/2/updates/i386/mozilla-nspr-1.7.10-1.2.1.legacy.i386.rpm b19179e3c9636c693519859168c15a374868265b fedora/2/updates/i386/mozilla-nspr-devel-1.7.10-1.2.1.legacy.i386.rpm cb906332518766343ce2e0b42b1daa8ea365f5c2 fedora/2/updates/i386/mozilla-nss-1.7.10-1.2.1.legacy.i386.rpm b321daec595fa820fa1c61636b6e7ae04bc93ec0 fedora/2/updates/i386/mozilla-nss-devel-1.7.10-1.2.1.legacy.i386.rpm 84b27211a322366ed7b55ebd56b27bd311f268b1 fedora/2/updates/SRPMS/mozilla-1.7.10-1.2.1.legacy.src.rpm 602ce3dc7e96667ca3c854208447873660bbbbec fedora/2/updates/i386/epiphany-1.2.10-0.2.5.legacy.i386.rpm d1c8debf69421cf879a8cc124999f09b86849743 fedora/2/updates/SRPMS/epiphany-1.2.10-0.2.5.legacy.src.rpm 616b84cd1427ed5692afaad68e75fa78a306853d fedora/2/updates/i386/devhelp-0.9.1-0.2.8.legacy.i386.rpm 2f93f6d05bf459305427ee159b798a939087d125 fedora/2/updates/i386/devhelp-devel-0.9.1-0.2.8.legacy.i386.rpm 08ac95e7d0f4bdcebbe03994cdacd5074f166479 fedora/2/updates/SRPMS/devhelp-0.9.1-0.2.8.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2260 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2261 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2263 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2265 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1937 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2266 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2267 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2268 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2269 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2270 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Thu Sep 15 17:34:02 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Sep 2005 10:34:02 -0700 Subject: Move / Copy docs into Wiki Message-ID: <1126805642.2815.83.camel@prometheus.gamehouse.com> I would like to get volunteers to copy / move all our documentation into the Wiki system. Red Hat has been doing a lot of design work on the wiki, and a RH person has offered to maintain the docs in the wiki, with editing and all that. We just have to get them into the wiki initially. Would anybody like to take up this task? -- 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 From sebenste at weather.admin.niu.edu Thu Sep 15 19:05:49 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Thu, 15 Sep 2005 14:05:49 -0500 (CDT) Subject: [FC1] James' Updates In-Reply-To: <4321F650.7070202@beta.intcomgrp.com> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <4321B6AE.9070708@beta.intcomgrp.com> <4321F650.7070202@beta.intcomgrp.com> Message-ID: On Fri, 9 Sep 2005, James Kosin wrote: > I've got a version now with the document fixes. I took the '-a' > option out of the /etc/sysconfig/spamassassin file; although, it is a > noreplace file in the install script meaning any settings will not be > touched when upgrading. > > http://support.intcomgrp.com/mirror/fedora-core/beta/i386/spamassassin-3.0.4-1.fc1.i386.rpm > > Let me know if the '-a' problem was the only one. Or if you go with It was, and it works great, I've had it now for 4 days with no problems. Thanks! ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From sebenste at weather.admin.niu.edu Thu Sep 15 19:52:41 2005 From: sebenste at weather.admin.niu.edu (Gilbert Sebenste) Date: Thu, 15 Sep 2005 14:52:41 -0500 (CDT) Subject: James' Updates In-Reply-To: <20050913224820.GA3438@neu.nirvana> References: <431F6D46.8070901@beta.intcomgrp.com> <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> <20050909173613.GA28024@neu.nirvana> <20050913224820.GA3438@neu.nirvana> Message-ID: On Wed, 14 Sep 2005, Axel Thimm wrote: >> conflict between fontconfig and fonts-hebrew: >> >> Package tix needs libitcl3.2.so, this is not available. >> Package tix needs libitk3.2.so, this is not available. >> Package tix needs itcl.so, this is not available. > > you probably need to update yum first. Early yum versions would easily > mask existing packages under certain circumstances. OK, I did this. Now, when I type "yum update", I get: % yum update Repository updates-testing already added, not adding again Repository updates already added, not adding again Yum Version: 2.3.4 COMMAND: yum Installroot: / Setting up Update Process Setting up repositories Baseurl(s) for repo: ['http://mirrors.sunsite.dk/jpackage/1.6/generic/free', 'ftp://jpackage.hmdc.harvard.edu/JPackage/1.6/generic/free'] jpackage-generic-free 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/linux/1/i386/dries/RPMS'] dries 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://dl.atrpms.net/fc1-i386/atrpms/stable'] atrpms 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://mirrors.sunsite.dk/jpackage/1.6/fedora-1/free', 'ftp://jpackage.hmdc.harvard.edu/JPackage/1.6/fedora-1/free'] jpackage-distspecific-fre 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://gstreamer.freedesktop.org/pkg/fedora/1/i386/yum/gst'] gstreamer 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://mirrors.sunsite.dk/jpackage/1.6/generic/devel', 'ftp://jpackage.hmdc.harvard.edu/JPackage/1.6/generic/devel'] jpackage-generic-devel 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://download.fedoralegacy.org/fedora/1/updates-testing/i386'] Cannot open/read repomd.xml file for repository: updates-testing failure: repodata/repomd.xml from updates-testing: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from updates-testing: [Errno 256] No more mirrors to try. Now what do I do? ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste at weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** ******************************************************************************* From sheltren at cs.ucsb.edu Thu Sep 15 20:41:36 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 15 Sep 2005 16:41:36 -0400 (AST) Subject: Move / Copy docs into Wiki In-Reply-To: <1126805642.2815.83.camel@prometheus.gamehouse.com> References: <1126805642.2815.83.camel@prometheus.gamehouse.com> Message-ID: <49283.201.220.3.125.1126816896.squirrel@letters.cs.ucsb.edu> On Thu, September 15, 2005 1:34 pm, Jesse Keating said: > I would like to get volunteers to copy / move all our documentation into > the Wiki system. Red Hat has been doing a lot of design work on the > wiki, and a RH person has offered to maintain the docs in the wiki, with > editing and all that. We just have to get them into the wiki initially. > > Would anybody like to take up this task? > Yeah, I can do that. Today and tomorrow I'm pretty busy, but I'll work on it this weekend at the latest. -Jeff From akopps at LS.Berkeley.EDU Thu Sep 15 22:32:12 2005 From: akopps at LS.Berkeley.EDU (Akop Pogosian) Date: Thu, 15 Sep 2005 15:32:12 -0700 (PDT) Subject: [FLSA-2005:160202] Updated mozilla packages fix security issues In-Reply-To: <4328D65D.6090306@videotron.ca> References: <4328D65D.6090306@videotron.ca> Message-ID: How come this message did not show fedora-legacy-list or fedora-legacy-announce in the To: field? This breaks my filters. -akop > Date: Wed, 14 Sep 2005 22:03:09 -0400 > From: Marc Deslauriers > Reply-To: Discussion of the Fedora Legacy Project > > To: bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk > Subject: [FLSA-2005:160202] Updated mozilla packages fix security issues From mike.mccarty at sbcglobal.net Fri Sep 16 03:12:20 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 15 Sep 2005 22:12:20 -0500 Subject: YUM Update of MOZILLA with FC2: Problem Message-ID: <432A3814.7040901@sbcglobal.net> I did a yum update today, and pulled mozilla $ grep 09/15/05 yum.log 09/15/05 18:06:08 Updated: cups 1:1.1.20-11.11.2.legacy.i386 09/15/05 18:06:08 Updated: cups-libs 1:1.1.20-11.11.2.legacy.i386 09/15/05 18:06:08 Updated: zlib-devel 1.2.1.2-0.fc2.2.legacy.i386 09/15/05 18:06:08 Updated: mozilla-nspr 37:1.7.10-1.2.1.legacy.i386 09/15/05 18:06:08 Updated: mozilla-nss 37:1.7.10-1.2.1.legacy.i386 09/15/05 18:06:08 Updated: zlib 1.2.1.2-0.fc2.2.legacy.i386 09/15/05 18:06:08 Updated: mozilla 37:1.7.10-1.2.1.legacy.i386 09/15/05 18:06:08 Updated: cups-devel 1:1.1.20-11.11.2.legacy.i386 Now, when I select Edit->Preferences->Advanced, the selection screen on the right is blank. I found (after the update) that I inadvertently had left a copy of Mozilla running. What do I need to do? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Fri Sep 16 03:19:38 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 15 Sep 2005 22:19:38 -0500 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <432A3814.7040901@sbcglobal.net> References: <432A3814.7040901@sbcglobal.net> Message-ID: <432A39CA.50702@sbcglobal.net> Mike McCarty wrote: > I did a yum update today, and pulled mozilla [snip] > Now, when I select Edit->Preferences->Advanced, the selection screen > on the right is blank. And forgot to mention that I double-clicked on, for example, Scripts & Plug-ins, or any other element under Advanced. In fact, this is true for all the categories on the left. They expand, but nothing shows up on the right when I select one of the sub-categories. When I try to edit, for example, Advanced->Scripts & Plug-ins the title portion of the right hand side changes appropriately, but the only thing (near the bottom) on the right hand side other than the title are the OK, Cancel, and Help buttons. The Help button brings up a blank help screen which cannot be navigated. > > I found (after the update) that I inadvertently had left a copy of > Mozilla running. > > What do I need to do? > > Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From Axel.Thimm at ATrpms.net Fri Sep 16 07:51:57 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Sep 2005 09:51:57 +0200 Subject: James' Updates In-Reply-To: References: <432193AD.4040706@hajo.net> <20050909160020.GC18541@neu.nirvana> <20050909161649.GE18541@neu.nirvana> <20050909173613.GA28024@neu.nirvana> <20050913224820.GA3438@neu.nirvana> Message-ID: <20050916075157.GB19618@neu.nirvana> On Thu, Sep 15, 2005 at 02:52:41PM -0500, Gilbert Sebenste wrote: > On Wed, 14 Sep 2005, Axel Thimm wrote: > > >>conflict between fontconfig and fonts-hebrew: > >> > >>Package tix needs libitcl3.2.so, this is not available. > >>Package tix needs libitk3.2.so, this is not available. > >>Package tix needs itcl.so, this is not available. > > > >you probably need to update yum first. Early yum versions would easily > >mask existing packages under certain circumstances. > > OK, I did this. Now, when I type "yum update", I get: > > > % yum update > > Repository updates-testing already added, not adding again > Repository updates already added, not adding again > Yum Version: 2.3.4 > COMMAND: yum > ['http://download.fedoralegacy.org/fedora/1/updates-testing/i386'] > Cannot open/read repomd.xml file for repository: updates-testing > failure: repodata/repomd.xml from updates-testing: [Errno 256] No more > mirrors to try. > Error: failure: repodata/repomd.xml from updates-testing: [Errno 256] No > more mirrors to try. > > Now what do I do? Use http://dl.atrpms.net/fc1-i386/redhat/updates-legacy and http://dl.atrpms.net/fc1-i386/redhat/updates-legacy-testing/ instead for now. I think the link above only has yum20 compatible metadata format, and yum 2.3.4 needs the so called repo-md format. -- 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 jkosin at beta.intcomgrp.com Fri Sep 16 15:51:09 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 16 Sep 2005 11:51:09 -0400 Subject: [FC1: Samba] James' Update Advisory Message-ID: <432AE9ED.7050605@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, REMEMBER: ~ (1) My updates are not supported by anyone other than me or the original group that is currently developing the software. ~ (2) Fedora-Legacy, Fedora and other groups are not supporting these updates. Don't complain to them about my updates!!! They usually won't know what you are talking about. ~ (3) If I tell of a kernel update! DO NOT GET RID OF YOUR OLD KERNEL. Keeping an old kernel that works installed is kinda like having a bootable floppy that works, if something breaks you still have a good system. ~ (4) Please let me know if you would like to see any other updates. Right now, I can't do a lot of updates but, I'm willing to add as long as everyone knows I'm only one person. ~ (5) MY UPDATES HAVE ONLY BEEN TESTED WITH FC1 !!! If you want to try them on FC2, RedHat 7.3 etc you are welcome to try, but I can't help with any problems... I just don't have the time. ============================================== SAMBA 3.0.20 - ------------ Note: I'm bumping the -# based on the number of patches applied to the original source. I didn't forget about -6, -7... Jerry posted the patches to the website on Friday and included three patches; so, I'm skipping from -5 to -8. Fixes / Patches: (a) Fix a regression in net rpc shutdown BUG-3080 (b) Fix for BUG-3044 & 3060 for dos application interoperability issues (c) Fix crash bugs in winbindd & smbd for x64 systems Source for patches http://samba.org/samba/patches/ SOURCE RPM - ---------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/samba-3.0.20-8.fc1.src.rpm i386 RPMS - --------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-3.0.20-8.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-client-3.0.20-8.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-common-3.0.20-8.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/samba-swat-3.0.20-8.fc1.i386.rpm ===================================================================== All of my binary packages are signed..... http://support.intcomgrp.com/mirror/fedora-core/beta/RPM-GPG-KEY-JAMES The SHA1 Sums for the binaries are here: http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sha1sum.txt The SHA1 Sums for the source files are here: http://support.intcomgrp.com/mirror/fedora-core/beta/src/sha1sum.txt I run a YUM server for FC1.... you can also point your updates to http://support.intcomgrp.com/mirror/fedora-core/beta/i386 BUT ONLY IF YOU WANT! ====================================================================== Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKuntkNLDmnu1kSkRAzisAJ9awBs5fVuD45Pts7vYpv5QR16FhACeN/W0 xPtf8eHf7j3fkuda6nWXYsQ= =QPVj -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jpdalbec at ysu.edu Fri Sep 16 18:12:58 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 16 Sep 2005 14:12:58 -0400 Subject: dl.atrpms.net (was Re: James' Updates) Message-ID: <432B0B2A.6030406@ysu.edu> > Use http://dl.atrpms.net/fc1-i386/redhat/updates-legacy and > http://dl.atrpms.net/fc1-i386/redhat/updates-legacy-testing/ instead > for now. I think the link above only has yum20 compatible metadata > format, and yum 2.3.4 needs the so called repo-md format. I've been looking for such a repository for FC2 so that I can use mach with yum. What is the directory http://dl.atrpms.net/fc2-i386/redhat/updates for? Are those official Fedora updates to the packages in http://dl.atrpms.net/fc2-i386/redhat/release? If so, what is http://dl.atrpms.net/fc2-i386/redhat/updates-testing for? If not, where are the official Fedora updates? Do you mirror them? Thanks, John Dalbec From Axel.Thimm at ATrpms.net Fri Sep 16 18:24:28 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Sep 2005 20:24:28 +0200 Subject: dl.atrpms.net (was Re: James' Updates) In-Reply-To: <432B0B2A.6030406@ysu.edu> References: <432B0B2A.6030406@ysu.edu> Message-ID: <20050916182428.GA13253@neu.nirvana> On Fri, Sep 16, 2005 at 02:12:58PM -0400, John Dalbec wrote: > >Use http://dl.atrpms.net/fc1-i386/redhat/updates-legacy and > >http://dl.atrpms.net/fc1-i386/redhat/updates-legacy-testing/ instead > >for now. I think the link above only has yum20 compatible metadata > >format, and yum 2.3.4 needs the so called repo-md format. > > I've been looking for such a repository for FC2 so that I can use mach with > yum. What is the directory http://dl.atrpms.net/fc2-i386/redhat/updates > for? Are those official Fedora updates to the packages in > http://dl.atrpms.net/fc2-i386/redhat/release? Yes. > If so, what is http://dl.atrpms.net/fc2-i386/redhat/updates-testing > for? Fedora has updates and updates-testing channels, this is the latter. > If not, where are the official Fedora updates? Do you mirror them? The layout at ATrpms looks like this: release release w/o updates updates released before EOL updates updates-testing pending before EOL updates updates-legacy released legacy updates updates-legacy-testing pending legacy updates So for building package in chroots, you probably only want o either release by itself only (for 100% ensuring ABI compatibility), or o release & updates & updates-legacy IMHO other combinations don't make much sense for your goals. -- 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 jkosin at beta.intcomgrp.com Fri Sep 16 18:57:12 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 16 Sep 2005 14:57:12 -0400 Subject: [FC1: ClamAV] James' Update Advisory Message-ID: <432B1588.3000803@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, REMEMBER: ~ (1) My updates are not supported by anyone other than me or the original group that is currently developing the software. ~ (2) Fedora-Legacy, Fedora and other groups are not supporting these updates. Don't complain to them about my updates!!! They usually won't know what you are talking about. ~ (3) If I tell of a kernel update! DO NOT GET RID OF YOUR OLD KERNEL. Keeping an old kernel that works installed is kinda like having a bootable floppy that works, if something breaks you still have a good system. ~ (4) Please let me know if you would like to see any other updates. Right now, I can't do a lot of updates but, I'm willing to add as long as everyone knows I'm only one person. ~ (5) MY UPDATES HAVE ONLY BEEN TESTED WITH FC1 !!! If you want to try them on FC2, RedHat 7.3 etc you are welcome to try, but I can't help with any problems... I just don't have the time. ============================================== ClamAV 0.87 - ------------ ClamAV updated their virus scanning application. SOURCE RPM - ---------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/clamav-0.87-0.fc1.src.rpm i386 RPMS - --------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/clamav-0.87-0.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/clamav-devel-0.87-0.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/clamav-milter-0.87-0.fc1.i386.rpm ===================================================================== All of my binary packages are signed..... http://support.intcomgrp.com/mirror/fedora-core/beta/RPM-GPG-KEY-JAMES The SHA1 Sums for the binaries are here: http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sha1sum.txt The SHA1 Sums for the source files are here: http://support.intcomgrp.com/mirror/fedora-core/beta/src/sha1sum.txt I run a YUM server for FC1.... you can also point your updates to http://support.intcomgrp.com/mirror/fedora-core/beta/i386 BUT ONLY IF YOU WANT! ====================================================================== Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKxWIkNLDmnu1kSkRA66bAJ9tpyEz3Zb5lHqk+fQYGlavHFUA/gCaA79z xIwabr8Y/r9X8kEiLw0hNfM= =8hMt -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkosin at beta.intcomgrp.com Fri Sep 16 21:14:50 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Fri, 16 Sep 2005 17:14:50 -0400 Subject: [FC1: SpamAssassin] James' Update Advisory Message-ID: <432B35CA.6020706@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, REMEMBER: ~ (1) My updates are not supported by anyone other than me or the original group that is currently developing the software. ~ (2) Fedora-Legacy, Fedora and other groups are not supporting these updates. Don't complain to them about my updates!!! They usually won't know what you are talking about. ~ (3) If I tell of a kernel update! DO NOT GET RID OF YOUR OLD KERNEL. Keeping an old kernel that works installed is kinda like having a bootable floppy that works, if something breaks you still have a good system. ~ (4) Please let me know if you would like to see any other updates. Right now, I can't do a lot of updates but, I'm willing to add as long as everyone knows I'm only one person. ~ (5) MY UPDATES HAVE ONLY BEEN TESTED WITH FC1 !!! If you want to try them on FC2, RedHat 7.3 etc you are welcome to try, but I can't help with any problems... I just don't have the time. ============================================== SpamAssassin 3.1.0 - ------------------- SpamAssassin has released version 3.1.0 today also..... I've been busy today on two fronts..!!! WOW. SOURCE RPM - ---------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/spamassassin-3.1.0-0.fc1.src.rpm i386 RPMS - --------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/apamassassin-3.1.0-0.fc1.i386.rpm ===================================================================== All of my binary packages are signed..... http://support.intcomgrp.com/mirror/fedora-core/beta/RPM-GPG-KEY-JAMES The SHA1 Sums for the binaries are here: http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sha1sum.txt The SHA1 Sums for the source files are here: http://support.intcomgrp.com/mirror/fedora-core/beta/src/sha1sum.txt I run a YUM server for FC1.... you can also point your updates to http://support.intcomgrp.com/mirror/fedora-core/beta/i386 BUT ONLY IF YOU WANT! ====================================================================== Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKzXKkNLDmnu1kSkRA0mGAJ9waLkA6u8cYgQ2LGX2hlZdBFt/xQCfSAXk g4JcofHpclFHTLG6SJ7p9wg= =yOz6 -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From sheltren at cs.ucsb.edu Sat Sep 17 19:32:42 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 17 Sep 2005 15:32:42 -0400 (AST) Subject: Move / Copy docs into Wiki In-Reply-To: <49283.201.220.3.125.1126816896.squirrel@letters.cs.ucsb.edu> References: <1126805642.2815.83.camel@prometheus.gamehouse.com> <49283.201.220.3.125.1126816896.squirrel@letters.cs.ucsb.edu> Message-ID: <49881.201.220.3.125.1126985562.squirrel@letters.cs.ucsb.edu> On Thu, September 15, 2005 4:41 pm, Jeff Sheltren said: > On Thu, September 15, 2005 1:34 pm, Jesse Keating said: >> I would like to get volunteers to copy / move all our documentation into >> the Wiki system. Red Hat has been doing a lot of design work on the >> wiki, and a RH person has offered to maintain the docs in the wiki, with >> editing and all that. We just have to get them into the wiki initially. >> >> Would anybody like to take up this task? >> > > Yeah, I can do that. Today and tomorrow I'm pretty busy, but I'll work on > it this weekend at the latest. > > -Jeff > Hi Jesse, I've added a number of new pages to the wiki: Legacy/Yum73Detailed Legacy/Yum73Quick Legacy/Yum9Detailed Legacy/YumFC1Detailed Legacy/YumFC2Detailed Legacy/Up2dateFC1 Could you please add ACLs for those? Thanks, Jeff From jkosin at beta.intcomgrp.com Mon Sep 19 12:56:25 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 19 Sep 2005 08:56:25 -0400 Subject: [FC1: SpamAssassin] James' Update Advisory In-Reply-To: <432B35CA.6020706@beta.intcomgrp.com> References: <432B35CA.6020706@beta.intcomgrp.com> Message-ID: <432EB579.60906@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, I have a new version of SpamAssassin-3.1.0 for FC1. For some reason, they want to set the persistant states for the sockets to 0; but, FC1 does not have a persistant state for a UDP connection. At least from what I can gather from the error message. I have a simple patch for the version of spamassassin for FC1 to fix this in my initial release of the package. Sorry for any troubles this may have caused. New SOURCE RPM - ---------------------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/spamassassin-3.1.0-1.fc1.src.rpm New BINARY RPM - ---------------------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/spamassassin-3.1.0-1.fc1.i386.rpm I caught this on Friday; but, couldn't get a patch done quick enough to get it out then. Sorry again, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDLrV5kNLDmnu1kSkRA9QQAJsFQuUs0bxycbfkXAzA/6ya1Oyt7QCfcJk3 DN80UdjVk6BHSV7onS0Z5vc= =OW8u -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From gene.heskett at verizon.net Mon Sep 19 14:48:34 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 19 Sep 2005 10:48:34 -0400 Subject: recent ntpd problems Message-ID: <200509191048.34895.gene.heskett@verizon.net> Greetings; This somewhat FC2 box has been keeping time quite well since I finally managed to get the ntpd daemon working, and worked quite well up thru kernel 2.6.13-rc5. At 2.6.13-rc6, and now for 2.6.13.1, time synch is not being done and the time drifts several minutes a day. I've rebuilt 2.6.13.1 using the 2.6.13-rc5 .config after a make oldconfig. I'm not sure if that might fix it, but I found a vulnerability notice for versions earlier than 4.2.0b, so I've also been playing with both that, and the version pf 4.2.0a as patched for FC3. This latter version does not seem to be writing to /var/log/ntpd.log at all, so I have no idea what its doing. So I built it from the tarball for ntp-dev-4.2.0b, (./configure --prefix=/usr, so it would overwrite the rpm install) and its still not writing to /var/log/ntpd.log. But at least ntpstat says its approaching sync, as in: [root at coyote ntp-dev-4.2.0b-20050827]# ntpstat synchronised to NTP server (64.5.1.129) at stratum 3 time correct to within 41 ms polling server every 64 s This is while booted to 2.6.13-rc5, which was known to work with the older, version 4.1.1 ntpd. Now I'm going to reboot to a 2.6.13.1 made from the 2.6.13-rc5 & a make oldconfig and see if that will work. It didn't, sync was to the local ntp server only. Nobody on the kernel list seems to be having this problem with post 2.6.13-rc5 kernels, which is why I'm posting here on the legacy list. So I've now turned on some IpSec stuff in the .config, and rebuilt it again. And, 10 minutes after rebooting to this 2.6.13.1 build, there is still no logging, and ntpstat is telling me this: [root at coyote ntp-dev-4.2.0b-20050827]# ntpstat synchronised to NTP server (64.5.1.130) at stratum 3 time correct to within 483 ms polling server every 64 s Which is the first time its admitted using an non-local time src when booted to 2.6.13-rc6 or 2.6.13.1, so maybe I've got it. I turned on some IpSec stuff in the .config this time. Comments anybody? As in when did it become a requirement to have IpSec stuff enabled (if indeed thats what fixed it) before ntpd would run? No firewall on this box, its on another box & no changes have been made there in many months. And, secondarily, why is there no logging now so that I have to query it with ntpstat to see if its running right? This is with [root at coyote ntp-dev-4.2.0b-20050827]# ntpd --version ntpd: ntpd 4.2.0b at 1.1407-o Mon Sep 19 13:24:39 UTC 2005 (1) installed from the tarball, and the older /etc/ntp/keys and /etc/ntp/step-tickers from an .rpmsave rewritten over the FC3 installed versions. -- 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 hjp+fedora-legacy at wsr.ac.at Mon Sep 19 15:42:23 2005 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 19 Sep 2005 17:42:23 +0200 Subject: recent ntpd problems In-Reply-To: <200509191048.34895.gene.heskett@verizon.net> References: <200509191048.34895.gene.heskett@verizon.net> Message-ID: <20050919154222.GH18439@wsr.ac.at> On 2005-09-19 10:48:34 -0400, Gene Heskett wrote: [new version of ntpd] > This latter version does not seem to be writing to /var/log/ntpd.log > at all, so I have no idea what its doing. Have you started it with -l /var/log/ntpd.log? Normally ntpd writes to syslog (and I believe this it has done this for the last 10 years or so). hp -- _ | Peter J. Holzer | In our modern say,learn,know in a day |_|_) | Sysadmin WSR | world, perhaps being an expert is an | | | hjp at wsr.ac.at | outdated concept. __/ | http://www.hjp.at/ | -- Catharine Drozdowski on dbi-users. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From gene.heskett at verizon.net Mon Sep 19 15:51:59 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 19 Sep 2005 11:51:59 -0400 Subject: recent ntpd problems In-Reply-To: <20050919154222.GH18439@wsr.ac.at> References: <200509191048.34895.gene.heskett@verizon.net> <20050919154222.GH18439@wsr.ac.at> Message-ID: <200509191151.59964.gene.heskett@verizon.net> On Monday 19 September 2005 11:42, Peter J. Holzer wrote: >On 2005-09-19 10:48:34 -0400, Gene Heskett wrote: >[new version of ntpd] > >> This latter version does not seem to be writing to /var/log/ntpd.log >> at all, so I have no idea what its doing. > >Have you started it with -l /var/log/ntpd.log? Normally ntpd writes to >syslog (and I believe this it has done this for the last 10 years or >so). No, but I didn't have to before. In the init.d/ntpd script, the ntpd starter is "daemon ntpd $OPTIONS" but I've NDI where $OPTIONS actually gets set. Or am I just being dense in my advancing years?, coming up on the 71st birthday now. > > hp -- 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 hjp+fedora-legacy at wsr.ac.at Mon Sep 19 15:59:53 2005 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 19 Sep 2005 17:59:53 +0200 Subject: recent ntpd problems In-Reply-To: <200509191151.59964.gene.heskett@verizon.net> References: <200509191048.34895.gene.heskett@verizon.net> <20050919154222.GH18439@wsr.ac.at> <200509191151.59964.gene.heskett@verizon.net> Message-ID: <20050919155953.GI18439@wsr.ac.at> On 2005-09-19 11:51:59 -0400, Gene Heskett wrote: > On Monday 19 September 2005 11:42, Peter J. Holzer wrote: > >On 2005-09-19 10:48:34 -0400, Gene Heskett wrote: > >[new version of ntpd] > > > >> This latter version does not seem to be writing to /var/log/ntpd.log > >> at all, so I have no idea what its doing. > > > >Have you started it with -l /var/log/ntpd.log? Normally ntpd writes to > >syslog (and I believe this it has done this for the last 10 years or > >so). > > No, but I didn't have to before. In the init.d/ntpd script, the ntpd > starter is "daemon ntpd $OPTIONS" but I've NDI where $OPTIONS > actually gets set. It gets set in /etc/sysconfig/ntpd On my system it contains # Drop root to id 'ntp:ntp' by default. Requires kernel >= 2.2.18. OPTIONS="-U ntp -p /var/run/ntpd.pid" which I believe is the default for FC2 (I certainly can't remember changing it). AFAIR the default for (x)ntpd on Redhat systems has always been to log to syslog since Redhat 3.0.3 (before I used Slackware, and I think it was the same). hp -- _ | Peter J. Holzer | In our modern say,learn,know in a day |_|_) | Sysadmin WSR | world, perhaps being an expert is an | | | hjp at wsr.ac.at | outdated concept. __/ | http://www.hjp.at/ | -- Catharine Drozdowski on dbi-users. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From gene.heskett at verizon.net Mon Sep 19 16:28:11 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 19 Sep 2005 12:28:11 -0400 Subject: recent ntpd problems In-Reply-To: <20050919155953.GI18439@wsr.ac.at> References: <200509191048.34895.gene.heskett@verizon.net> <200509191151.59964.gene.heskett@verizon.net> <20050919155953.GI18439@wsr.ac.at> Message-ID: <200509191228.11111.gene.heskett@verizon.net> On Monday 19 September 2005 11:59, Peter J. Holzer wrote: >On 2005-09-19 11:51:59 -0400, Gene Heskett wrote: >> On Monday 19 September 2005 11:42, Peter J. Holzer wrote: >> >On 2005-09-19 10:48:34 -0400, Gene Heskett wrote: >> >[new version of ntpd] >> > >> >> This latter version does not seem to be writing to >> >> /var/log/ntpd.log at all, so I have no idea what its doing. >> > >> >Have you started it with -l /var/log/ntpd.log? Normally ntpd writes >> > to syslog (and I believe this it has done this for the last 10 years >> > or so). >> >> No, but I didn't have to before. In the init.d/ntpd script, the ntpd >> starter is "daemon ntpd $OPTIONS" but I've NDI where $OPTIONS >> actually gets set. > >It gets set in /etc/sysconfig/ntpd > Ahh, I see. I appended it there, and on a restart, its back to using its own log, many thanks. >On my system it contains > > # Drop root to id 'ntp:ntp' by default. Requires kernel >= 2.2.18. > OPTIONS="-U ntp -p /var/run/ntpd.pid" > >which I believe is the default for FC2 (I certainly can't remember >changing it). AFAIR the default for (x)ntpd on Redhat systems has always >been to log to syslog since Redhat 3.0.3 (before I used Slackware, and I >think it was the same). > > hp -- 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 jkosin at beta.intcomgrp.com Tue Sep 20 14:29:39 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 20 Sep 2005 10:29:39 -0400 Subject: [FC1: SpamAssassin] James' Update Advisory In-Reply-To: <432B35CA.6020706@beta.intcomgrp.com> References: <432B35CA.6020706@beta.intcomgrp.com> Message-ID: <43301CD3.1080103@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, I have a new version of SpamAssassin-3.1.0 for FC1. I've fixed the problem with perl-Net-DNS being at version 0.31, this version of spamassassin requires the version be >= 0.34 for this module. ~ Luckly, the .src.rpm for FC2 at version 0.45 works good for our use. I've undid the previous patch, updated the requirements for spamassassin to include the perl-Net-DNS >= 0.34 and rebuilt the whole lot. Sorry for any troubles this may have caused. New SOURCE RPM - ---------------------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/spamassassin-3.1.0-2.fc1.src.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/src/perl-Net-DNS-0.45-3.fc1.src.rpm New BINARY RPM - ---------------------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/spamassassin-3.1.0-1.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/perl-Net-DNS-0.45-3.fc1.i386.rpm Sorry again, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMBzTkNLDmnu1kSkRAzkxAJ9UPwzc/kh1JE7GdgkfgJCCNpDxTwCeIQ92 yjwc2YV7qaIw00oNg9ZcLxI= =bztQ -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From mike.mccarty at sbcglobal.net Tue Sep 20 15:50:33 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 20 Sep 2005 10:50:33 -0500 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <432A39CA.50702@sbcglobal.net> References: <432A3814.7040901@sbcglobal.net> <432A39CA.50702@sbcglobal.net> Message-ID: <43302FC9.4080008@sbcglobal.net> Mike McCarty wrote: > Mike McCarty wrote: > >> I did a yum update today, and pulled mozilla > > > > [snip] > >> Now, when I select Edit->Preferences->Advanced, the selection screen >> on the right is blank. > > > And forgot to mention that I double-clicked on, for example, > Scripts & Plug-ins, or any other element under Advanced. In fact, > this is true for all the categories on the left. They expand, > but nothing shows up on the right when I select one of the > sub-categories. When I try to edit, for example, > Advanced->Scripts & Plug-ins > the title portion of the right hand side changes appropriately, > but the only thing (near the bottom) on the right hand side > other than the title are the OK, Cancel, and Help buttons. > The Help button brings up a blank help screen which cannot be > navigated. > >> >> I found (after the update) that I inadvertently had left a copy of >> Mozilla running. >> >> What do I need to do? Ok, well, after some getting in and back out, Mozilla (seemed) to start working. Unfortunately, it's not all there. I've still got a problem. I use Gnome with FC2. I can view whatever I like, and I can use a plugin (like Acrobat) to display files, but the download manager seems not to work. When I try File->SavePageAs or right-click a link and try Save Link Target, instead of getting a dialogue box I just get a lock-up of Mozilla. When I click on the little X widget to close the window, I get a pop-up dialogue with a message saying The window "page i'm looking at - Mozilla" is not responding. Forcing this application to quit will cause you to lose any unsaved changes. It has two buttons: Cancel and Force Quit. It seems that it can download when using a plugin, and put things in a temp area, but it cannot activate an interactive download. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Sep 20 16:11:21 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 20 Sep 2005 11:11:21 -0500 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <432A3814.7040901@sbcglobal.net> References: <432A3814.7040901@sbcglobal.net> Message-ID: <433034A9.9090908@sbcglobal.net> Mike McCarty wrote: > I did a yum update today, and pulled mozilla > > $ grep 09/15/05 yum.log > 09/15/05 18:06:08 Updated: cups 1:1.1.20-11.11.2.legacy.i386 > 09/15/05 18:06:08 Updated: cups-libs 1:1.1.20-11.11.2.legacy.i386 > 09/15/05 18:06:08 Updated: zlib-devel 1.2.1.2-0.fc2.2.legacy.i386 > 09/15/05 18:06:08 Updated: mozilla-nspr 37:1.7.10-1.2.1.legacy.i386 > 09/15/05 18:06:08 Updated: mozilla-nss 37:1.7.10-1.2.1.legacy.i386 > 09/15/05 18:06:08 Updated: zlib 1.2.1.2-0.fc2.2.legacy.i386 > 09/15/05 18:06:08 Updated: mozilla 37:1.7.10-1.2.1.legacy.i386 > 09/15/05 18:06:08 Updated: cups-devel 1:1.1.20-11.11.2.legacy.i386 > > Now, when I select Edit->Preferences->Advanced, the selection screen > on the right is blank. > > I found (after the update) that I inadvertently had left a copy of > Mozilla running. More information: I find that I can use Acrobat to look at pdf (for example) as a plug-in, but cannot download the same file. It causes Mozilla to hang. $ rpm -V mozilla missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/content missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/skin missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie/content missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor/content missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/content missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/skin Should I try a # yum remove mozilla # yum install mozilla # yum update ? Or what other recommendations? Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mike.mccarty at sbcglobal.net Tue Sep 20 17:31:54 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 20 Sep 2005 12:31:54 -0500 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <20050920110806.B11006@mail.harddata.com> References: <432A3814.7040901@sbcglobal.net> <20050915220909.A7681@mail.harddata.com> <433031FF.8020906@sbcglobal.net> <20050920110806.B11006@mail.harddata.com> Message-ID: <4330478A.8090905@sbcglobal.net> Michal Jaegermann wrote: > On Tue, Sep 20, 2005 at 10:59:59AM -0500, Mike McCarty wrote: > >>OOPS! >> >>$ rpm -V mozilla >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/content >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/skin >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie/content >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor/content >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/content >>missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/skin >> >>So I apparently have an incomplete install. > > > No, not really. 'mozilla' is a nasty case. Ok. > > $ rpm -q --scripts mozilla > postinstall scriptlet (through /bin/sh): > # run ldconfig before regxpcom > /sbin/ldconfig >/dev/null 2>/dev/null > > if [ -f /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl ]; then > /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl > fi > ..... > > and the program in question has pretty close to the beginning: > > # remove all of the old files > rmtree("/usr/lib/mozilla-1.7.10/chrome/overlayinfo"); > unlink ; > unlink("/usr/lib/mozilla-1.7.10/component.reg"); > unlink("/usr/lib/mozilla-1.7.10/components/compreg.dat"); > unlink("/usr/lib/mozilla-1.7.10/components/xpti.dat"); > ..... > > That probably can be worked around in specs by adding in right places > > %ghost %config(missingok) %verify(not md5 size mtime) > > or by just dumping the whole chrome/overlayinfo tree from packaging (but > then you will leave leftovers on removals/updates, which happens anyway) > although this 'rmtree' is behind a conditional so one should be careful. > > I suggested that in the past and I think that some of these directives are > in place. But maybe not enough of these or this does not work on > directories. These are directories you see complaints about about. Try > > rpm -qlv mozilla | grep overlayinfo $ rpm -qlv mozilla | grep overlayinfo drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/content drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/skin drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/communicator drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/communicator/content drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie/content drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor/content drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/content drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/skin drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/navigator drwxr-xr-x 2 root root 0 Aug 11 18:59 /usr/lib/mozilla-1.7.10/chrome/overlayinfo/navigator/content > mozilla spec is rather big and you try not to mess with it too much. :-) Heh. >>Did you suggest then >> >>$ rpm -Uvh --force mozilla > > > Not in this particular case as this will not help without > '--noscripts' as well and this script presumably has reasons. Thanks for the reply, but I'm still in a quandary about getting Mozilla to work for me. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From michal at harddata.com Tue Sep 20 17:33:54 2005 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 20 Sep 2005 11:33:54 -0600 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <433034A9.9090908@sbcglobal.net>; from mike.mccarty@sbcglobal.net on Tue, Sep 20, 2005 at 11:11:21AM -0500 References: <432A3814.7040901@sbcglobal.net> <433034A9.9090908@sbcglobal.net> Message-ID: <20050920113354.D11006@mail.harddata.com> On Tue, Sep 20, 2005 at 11:11:21AM -0500, Mike McCarty wrote: > > $ rpm -V mozilla > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/content > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/skin > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie/content > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor/content > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/content > missing /usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/skin These directories (and they are all directories) are removed by %post. Like this: if [ -f /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl ]; then /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl fi and .... if ( -f "/usr/lib/mozilla-1.7.10/regxpcom" ) { # remove all of the old files rmtree("/usr/lib/mozilla-1.7.10/chrome/overlayinfo"); unlink ; unlink("/usr/lib/mozilla-1.7.10/component.reg"); unlink("/usr/lib/mozilla-1.7.10/components/compreg.dat"); unlink("/usr/lib/mozilla-1.7.10/components/xpti.dat"); ..... Nasty, but what we can do? Maybe they can be marked in specs as '%ghost %config(missingok) ...' but I am not sure if this works on directories. > Should I try a > > # yum remove mozilla > # yum install mozilla > # yum update The above shows that this will not help, at least with those "missing", and it is not a source of your problems. OTOH if something went funny during an installation (multiple instances locking itself out and so on) then maybe rerunning /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl will resolve the issues? Michal From mike.mccarty at sbcglobal.net Tue Sep 20 18:15:19 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 20 Sep 2005 13:15:19 -0500 Subject: YUM Update of MOZILLA with FC2: Problem In-Reply-To: <20050920113354.D11006@mail.harddata.com> References: <432A3814.7040901@sbcglobal.net> <433034A9.9090908@sbcglobal.net> <20050920113354.D11006@mail.harddata.com> Message-ID: <433051B7.10003@sbcglobal.net> Michal Jaegermann wrote: > On Tue, Sep 20, 2005 at 11:11:21AM -0500, Mike McCarty wrote: [that he was having problems with a Mozilla install] [snip] > The above shows that this will not help, at least with those > "missing", and it is not a source of your problems. OTOH if > something went funny during an installation (multiple instances > locking itself out and so on) then maybe rerunning > /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl will resolve > the issues? You're a good man, Charlie Brown! (with great admiration and respect for the late Charles Shultz) That seems to have done it! Downloads now work as they did. (Though the "homepage" setting seems to have gone away, and I don't know where it was... it was FC2 release notes) Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Tue Sep 20 22:11:26 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Sep 2005 15:11:26 -0700 Subject: Vacation Message-ID: <1127254286.24908.95.camel@prometheus.gamehouse.com> I'm taking a vacation next week and will not be able to get email. I'll be on a 7 day cruise to Mexico from California and I don't imagine they have a lot of free wireless services on said boat. I'll bring the laptop just in case, but my wife will likely throw me and it overboard if she catches me using it (: Cheers! -- 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 From deisenst at gtw.net Wed Sep 21 22:17:50 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 21 Sep 2005 17:17:50 -0500 (CDT) Subject: Some Suggestions (Mirror Space, gaim, ethereal, etc) In-Reply-To: <1122347487.6017.11.camel@mdlinux> Message-ID: On Mon, 25 Jul 2005, Marc Deslauriers wrote: > On Mon, 2005-07-25 at 10:29 -1000, Warren Togami wrote: > > rh73 has a working gtk2 for gaim-1.x? > > > > Yep, it seems to be working enough for gaim. I did basic testing of it a > while back and nobody has complained about the 3-4 releases so far. > > > > If you can give me details about the perl path for RH73 and RH9, I can > > improve the default gaim.spec. I just never bothered to do so for the > > past year because the upstream perl plugin has been broken and unsable > > for a long time, so nobody would miss it being gone anyway. > > Curiously, people noticed it was missing from rh7.3 and rh9 for a while. > I guess they didn't actually try to use it. :) > > Thanks for the offer. Next time I build gaim for FL, I'll check what I > did to the spec file. > > Marc. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Marc, and all, I have just rebuilt gaim-1.5.0 for FC1 and have a .src.rpm package out there for QA. http://www.fedoralegacy.org/contrib/gaim/gaim-1.5.0-1.fc1.2.legacy.src.rpm 943907fbd013a565e3634b69a1542b2763b13dc7 gaim-1.5.0-1.fc1.2.legacy.src.rpm Are there some special changes that need to be made to spec files for rh7.3 and rh9 so newer gaim packages will work in these environments? If so, would you share those? Thanks! -David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFDMdg8xou1V/j9XZwRAhxSAJ0XfqHO6uQaC86W5bpUuxodDpdHSQCgmWZn t7c8RfZCnb56J4jlCpn3NcI= =YsZz -----END PGP SIGNATURE----- From deisenst at gtw.net Thu Sep 22 02:21:00 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 21 Sep 2005 21:21:00 -0500 (CDT) Subject: Some Suggestions (Mirror Space, gaim, ethereal, etc) In-Reply-To: <42E4DA56.8070705@togami.com> Message-ID: On Mon, 25 Jul 2005, Warren Togami wrote: > <> > (FC1's gnome-open was broken due to broken default config tools and > gconf schedule, so you might want to turn that off if Legacy hasn't > backported my control-center and gnome-vfs2 schema patch from FC2 like I > suggested a while ago. Probably not worth it now though, because this > does nothing to help existing user profiles.) > Hey Warren, As I just built some FC1 packages and wasn't aware of this -- can you fill us in on or remind us of the suggestion you had about backporting the control center and gnome-vfs2 schema patch from FC2? I don't know whether or not we did that. Are you talking about /usr/bin/gnome-open in package libgnome-2.4.0-1? Are there other .src.rpm packages you are talking about here, Warren? When I type: $ gnome-open http://www.fedora.us/ a mozilla window opens to that web page. Regards, David From jimpop at yahoo.com Thu Sep 22 13:15:23 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 22 Sep 2005 09:15:23 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] Message-ID: <4332AE6B.8030002@yahoo.com> Anyone know if this impacts FL? I did a quick BugTraq look at Pekka's lists and didn't see it mentioned. Thx, -Jim P. -------- Original Message -------- Subject: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution Resent-Date: Thu, 22 Sep 2005 03:47:31 -0500 (CDT) Resent-From: debian-security-announce at lists.debian.org Date: Thu, 22 Sep 2005 10:44:23 +0200 (CEST) From: joey at infodrom.org (Martin Schulze) Reply-To: debian-security at lists.debian.org To: debian-security-announce at lists.debian.org (Debian Security Announcements) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------------------------------------------------------------------------- Debian Security Advisory DSA 817-1 security at debian.org http://www.debian.org/security/ Martin Schulze September 22nd, 2005 http://www.debian.org/security/faq - -------------------------------------------------------------------------- Package : python2.2 Vulnerability : integer overflow Problem type : remote Debian-specific: no CVE ID : CAN-2005-2491 BugTraq ID : 14620 Debian Bug : 324531 An integer overflow with a subsequent buffer overflow has been detected in PCRE, the Perl Compatible Regular Expressions library, which allows an attacker to execute arbitrary code, and is also present in Python. Exploiting this vulnerability requires an attacker to specify the used regular expression. For the old stable distribution (woody) this problem has been fixed in version 2.2.1-4.8. For the stable distribution (sarge) this problem has been fixed in version 2.2.3dfsg-2sarge1. For the unstable distribution (sid) this problem has been fixed in version 2.2.3dfsg-4. We recommend that you upgrade your python2.2 packages. Upgrade Instructions - -------------------- wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8.dsc Size/MD5 checksum: 1150 0bcb5a04905bfafb0fe5ed1373914d54 http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8.diff.gz Size/MD5 checksum: 95524 da620a7770bef5dfb59d25eddf272743 http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1.orig.tar.gz Size/MD5 checksum: 6536167 88aa07574673ccfaf35904253c78fc7d Architecture independent components: http://security.debian.org/pool/updates/main/p/python2.2/idle-python2.2_2.2.1-4.8_all.deb Size/MD5 checksum: 113252 250b9b4c08c27a0d801ac617c83fb8b3 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-doc_2.2.1-4.8_all.deb Size/MD5 checksum: 1314656 367bb83c81d696e9f32333bab44a7cab http://security.debian.org/pool/updates/main/p/python2.2/python2.2-elisp_2.2.1-4.8_all.deb Size/MD5 checksum: 50356 b7bfd835461b316ee08d8e8b561f5427 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-examples_2.2.1-4.8_all.deb Size/MD5 checksum: 478060 bd598b6adf274f9b64b10c4f35ae198f Alpha architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_alpha.deb Size/MD5 checksum: 2139152 7287b982100612efcb66d30689bc5a0f http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_alpha.deb Size/MD5 checksum: 864054 0112c98bdbaabea2b705157fca7ba7e0 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_alpha.deb Size/MD5 checksum: 18344 0b540f3fa82e486b5801a0b78621c528 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_alpha.deb Size/MD5 checksum: 21978 54aa2124c896d7dd862bf612387e00fa http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_alpha.deb Size/MD5 checksum: 86482 b4258e95f175468e03e60dccf9f5b73e http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_alpha.deb Size/MD5 checksum: 52596 0ca4010a7875b23e0a808dcd19f2d1eb ARM architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_arm.deb Size/MD5 checksum: 1952354 bb429adcc8ae9592fc858d97a8def5d6 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_arm.deb Size/MD5 checksum: 774816 28178610e965293fdd87550c5c62195b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_arm.deb Size/MD5 checksum: 17166 7aef987aad73b5dcce081916ef4c2474 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_arm.deb Size/MD5 checksum: 20406 c95d640f1f3dec4298861072cd97120a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_arm.deb Size/MD5 checksum: 84794 e08d0bb2e49b134851db5abb5ece860a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_arm.deb Size/MD5 checksum: 50032 bbb0e83fbc3c5aca942e418adf9610ce Intel IA-32 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_i386.deb Size/MD5 checksum: 1888206 11c45d65ead488c8beff562951a470a4 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_i386.deb Size/MD5 checksum: 684308 4c238882cbb0d25911ef842dd52c7e76 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_i386.deb Size/MD5 checksum: 16964 b70c737f2eb52d86942e85773fb4c51e http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_i386.deb Size/MD5 checksum: 20352 4370a5fbc2626805038aa1d81331e34e http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_i386.deb Size/MD5 checksum: 83598 85d8a67ef938bfd25003c81b79af32a4 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_i386.deb Size/MD5 checksum: 49000 15ded72e48ca1872e235c85607e01045 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_ia64.deb Size/MD5 checksum: 2490294 1ed56fce85c165540f2f221a5fcc3c09 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_ia64.deb Size/MD5 checksum: 936846 2e083b7b5d9415903fdd8020462f81bd http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_ia64.deb Size/MD5 checksum: 19848 1672edc7e12b76398c5cd448ede84c83 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_ia64.deb Size/MD5 checksum: 25694 5f7f7bfb0602c32c4137376065e7407f http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_ia64.deb Size/MD5 checksum: 90618 ffb52a5414f53b1e86c7ccb2b1a8dc7d http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_ia64.deb Size/MD5 checksum: 56658 55fd67342252c0327402209c709e0a5e HP Precision architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_hppa.deb Size/MD5 checksum: 2356790 2e77caf227e3589210b7d98127eae66b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_hppa.deb Size/MD5 checksum: 925136 71e9a6e254c1330e08568caa74ec2c1a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_hppa.deb Size/MD5 checksum: 18510 e8e1da534f0ceb418debae46a5e2acaa http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_hppa.deb Size/MD5 checksum: 24302 3dd3b3bebcaabe29be67cb138233cc79 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_hppa.deb Size/MD5 checksum: 88316 ec19de9dece10d3c5b0c005db0cd06a8 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_hppa.deb Size/MD5 checksum: 55212 b8cab916fb51da11b97829df18cb11bf Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_m68k.deb Size/MD5 checksum: 1894914 5221e85f3db1a854c62bdca5ee2ace8f http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_m68k.deb Size/MD5 checksum: 661110 e495c688199fe90ed2d7987aa3f0047b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_m68k.deb Size/MD5 checksum: 17090 5b4d7417ad469f74dac416f66b106129 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_m68k.deb Size/MD5 checksum: 20028 6ccb252c0b00f7ae55d7a448f3aa8b57 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_m68k.deb Size/MD5 checksum: 84480 e232882817832296cf23b5b3a0c75bbb http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_m68k.deb Size/MD5 checksum: 49810 b29b83567c057f64371c4bd70f1bb5eb Big endian MIPS architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_mips.deb Size/MD5 checksum: 1953242 7a3614d50723288ce950f4ccd651595f http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_mips.deb Size/MD5 checksum: 790472 80ecae5ca1db6d5b163b1bda4c5fa10d http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_mips.deb Size/MD5 checksum: 17168 959bbe60af4db6d89bb3788181348c9b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_mips.deb Size/MD5 checksum: 20432 87585967c4bb1ff386e1d88a368882c2 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_mips.deb Size/MD5 checksum: 83624 f1b3370d71d538275b322c87d342cd88 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_mips.deb Size/MD5 checksum: 49188 a3bca10b355f967b8feab7cd353dc3e6 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 1948152 e596c21b0a65f358970a902a573cec65 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 790446 9107450b1df520ab26825129b99bf125 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 17188 822c53ec527f4fe674d80f179fc99810 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 20458 3b2292944224778370e2df77f9eb63d7 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 83566 688b4aaf09573511d90d0b8277ec9e30 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_mipsel.deb Size/MD5 checksum: 49126 05b2da890ccea142e188c46d18cebb69 PowerPC architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 1999096 28c0fa9ff6bdd56e640cd5668b27c2b8 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 775712 6d3c25a525912113b34b824d77265df4 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 17376 a51248e9ab62f8158342c048a4ba5ea4 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 21022 81b1d17a01b408bc56083d1ffabc90a5 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 85204 01352400a765d29dc42a41758f20f4c2 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_powerpc.deb Size/MD5 checksum: 50558 d415ceb0b9d81c2adb2232e426e7695d IBM S/390 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_s390.deb Size/MD5 checksum: 1940912 ba728158bb5c856aae115c01d979ad4a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_s390.deb Size/MD5 checksum: 692972 7bf3be3f38fa2bfe5f224a84587a7bfe http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_s390.deb Size/MD5 checksum: 17612 00f09594e81103b00a121d49bb73e207 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_s390.deb Size/MD5 checksum: 20776 e1dd59f69b68560b463381ebd421da22 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_s390.deb Size/MD5 checksum: 85578 1d5f6dd53840d83c598764f1b6fe2765 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_s390.deb Size/MD5 checksum: 50078 84c08653597bc72cbdf4e399615b8527 Sun Sparc architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.8_sparc.deb Size/MD5 checksum: 2037344 03282aced4a76399bd687e43de8ca850 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.8_sparc.deb Size/MD5 checksum: 738416 85af696a55da091188b6608c7a2077db http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.8_sparc.deb Size/MD5 checksum: 20286 01841352ff7d4947b84887c37e4de2fa http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.8_sparc.deb Size/MD5 checksum: 19934 1bb815d9f83f67002ccbc6555b02a90b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.8_sparc.deb Size/MD5 checksum: 84430 20256de3f68c5bb5084b6b7ae3463755 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.8_sparc.deb Size/MD5 checksum: 49798 b2cac7b087f521df0b7633a1bd602ec3 Debian GNU/Linux 3.1 alias sarge - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1.dsc Size/MD5 checksum: 1188 4f719b1e6ea09c001c878c82dd235aa2 http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1.diff.gz Size/MD5 checksum: 1963578 bd95fcae22dcc43a1e9b9a9d0f261abf http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg.orig.tar.gz Size/MD5 checksum: 6691331 8ed6e66f125308f55115e7df8cc9f18a Architecture independent components: http://security.debian.org/pool/updates/main/p/python2.2/idle-python2.2_2.2.3dfsg-2sarge1_all.deb Size/MD5 checksum: 118536 62629861b83514a4c11dccf7373c25cb http://security.debian.org/pool/updates/main/p/python2.2/python2.2-doc_2.2.3dfsg-2sarge1_all.deb Size/MD5 checksum: 2303758 3531fb12f5c9be109052b14b0a553f8f http://security.debian.org/pool/updates/main/p/python2.2/python2.2-examples_2.2.3dfsg-2sarge1_all.deb Size/MD5 checksum: 483068 d5787eb95dcf34957cdb6c9611fc43dd Alpha architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 2326760 d1952a138c6d336e1421a65d0833ad55 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 1385846 212cb8f31e7cc2534efc4afed2bb1037 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 24606 eb5e7dafc6d4c2c89b085661e50429cd http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 28318 df39515fcda166a2d02618f8850d0cc2 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 101102 17ad2ea00e31e8fd0b93b97a3b66f4bd http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_alpha.deb Size/MD5 checksum: 58478 c53cb670d6b42afe0850da41260f158f AMD64 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 2373126 42faecd922ace44b96c00b9f1c9391d7 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 1257232 54e9b79a4dbbec5606132ae56a1d201d http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 24144 34daea57a73dfe7b8516e8f1df4a26e4 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 28834 ce5994129f332e023b59b00cc48b5112 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 100178 c108c75b16f2a6692707ef6d3e4c5ebc http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_amd64.deb Size/MD5 checksum: 58472 85a6ab647bb98952e3ab866dc0fd8f87 ARM architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 2263734 a397cb83a73ef125a59de84bc168cc21 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 1306792 7de6477492ec686b99617fb8199aaa6e http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 23670 8c103c161948751bf75ef9954c51265b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 27304 4e7403fc6dabb095f19b154bc3b36779 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 97816 14679a6686ff6e32413972df2a557a13 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_arm.deb Size/MD5 checksum: 57056 c9f2b649a9274b6ef4fd0d0db7986422 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 2274472 5280fc41aa7de7c12f153ae8b6e771f3 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 1156394 7d2e2283394218a34ac46eb3474e7861 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 23868 4182ae276e81cbc373d5cbcfe76bb709 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 27770 10463e00b1771eb94e24df96636a9359 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 98106 67739054bd2b94ef92be93ac475bc742 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_i386.deb Size/MD5 checksum: 57184 e06bdfdfe07521ea2ca443b091398a24 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 3198986 4d12b1936ab36dda9b268d0a24541f07 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 1981048 88c1e9f12d81708e7d03b14c5ec2d176 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 26414 50c1bbb4cd4bc2ba90bf81c7716ccab2 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 34104 ad4d9c76bf3368520e8a85b28ea6b784 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 111140 74f74aa85155ceefc80117cf0b2b0e16 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_ia64.deb Size/MD5 checksum: 65040 cee73bd0cb107b3a4fa26b6ca0b4539f HP Precision architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 2597032 1baa46fbf3dc415adeb17b6c5db77e28 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 1464966 9489562f794216b606d3a5c03d93c8da http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 25094 a1f730d79f004266e410375d3cd2b76b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 30164 c9eecfb7d3a07577ca49f95f759acbbc http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 103854 993995a665342ede70699e517836db48 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_hppa.deb Size/MD5 checksum: 60720 c9371bd5133ae6364d01ddb37763f161 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 2201546 12766e82b601448b0f9f0675e92a8a6b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 1036262 3282b2d2018ec54480c329cdf50ee993 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 23622 8622de5795855b8dfd15a6a76e64ca56 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 27006 e0147ff7f677c562aeb15fa73a31c602 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 97808 fffaa0f786268add8b2b866d801555df http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_m68k.deb Size/MD5 checksum: 57126 2a19f81b10a7e111fcd5a7bbdafcd79a Big endian MIPS architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 2381540 a4642b1739fec486978bd2405b8991e5 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 1347112 ccc452ba8388794cba43a67b29d2ed25 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 23858 ec964c8827fd506ffb793f5f89291d22 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 27984 b12aeda0c800c107fb5c530fa93f7cb5 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 97616 4a16eb4b07ea567705d4a5bb0b617832 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_mips.deb Size/MD5 checksum: 57208 2960ecf825040c01c37c7f055df05446 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 2379930 b75de32ccb46fb9da97c12552cf8e0ae http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 1349136 5cb9990e25f9d98e40fd18b9742ed9c1 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 23830 8c94dedfb55f069f97e279b36ac3946a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 28000 857265053bfe62789b07e939baa31c31 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 97550 2099bc32b221b98a9d9facac592544aa http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_mipsel.deb Size/MD5 checksum: 57208 5e6eed56a30f541fb7affb2767dac8d4 PowerPC architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 2490332 67495753cef58e5b55cb552f8fd10bf3 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 1358422 e95444fd0aa0e7f5b0141e5f6007f808 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 25636 7a66cef80caa4d853cc9b136e0de3e9d http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 29904 87dc6f5f38558c31924eaa09f5ebcf3a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 100828 4ec685ecdcda7224d6bb0596b5e80094 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_powerpc.deb Size/MD5 checksum: 59464 53aa59da79bec45bcb07d7002f221faa IBM S/390 architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 2406302 3b9aff7425d217b05234affd2076d78b http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 1283222 6f801e0070d17a12af0c8559f1bd75bb http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 24736 e307b83addb7cd68d304e933b9029856 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 29342 543b4f0d1f46a009a167e35b8183b93a http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 102504 a666d6fa5c230f72b155c4437d590e2c http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_s390.deb Size/MD5 checksum: 59134 f8805e65f13c663e0b5ff6e58f9d9a38 Sun Sparc architecture: http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 2417842 c3ed6bf896fc12f66a095ea8a6f55301 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 1323076 ba91511241b13da53c0bbf6d8e4c61f9 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 23964 c6686cc728b17be851b65c95a1b174df http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 28300 8b7278274654ff133c1d689f275edbda http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 100048 fe4dacf9ae487658d76178d825aa1c27 http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2sarge1_sparc.deb Size/MD5 checksum: 58218 2213824db44713f60f75ba076e1d2b19 These files will probably be moved into the stable distribution on its next update. - --------------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce at lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDMm7nW5ql+IAeqTIRAkaQAKCe3iKBWxzTdPtc6A5fNojgJXgO+gCfZ+4D 1jGXU5cpMDyXaDqm333rVzs= =avpI -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-security-announce-REQUEST at lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org From jkosin at beta.intcomgrp.com Thu Sep 22 13:22:36 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 22 Sep 2005 09:22:36 -0400 Subject: [FC1: Many...] James' Update Advisory In-Reply-To: <432B35CA.6020706@beta.intcomgrp.com> References: <432B35CA.6020706@beta.intcomgrp.com> Message-ID: <4332B01C.2000606@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, REMEMBER: ~ (1) My updates are not supported by anyone other than me or the original group that is currently developing the software. ~ (2) Fedora-Legacy, Fedora and other groups are not supporting these updates. Don't complain to them about my updates!!! They usually won't know what you are talking about. ~ (3) If I tell of a kernel update! DO NOT GET RID OF YOUR OLD KERNEL. Keeping an old kernel that works installed is kinda like having a bootable floppy that works, if something breaks you still have a good system. ~ (4) Please let me know if you would like to see any other updates. Right now, I can't do a lot of updates but, I'm willing to add as long as everyone knows I'm only one person. ~ (5) MY UPDATES HAVE ONLY BEEN TESTED WITH FC1 !!! If you want to try them on FC2, RedHat 7.3 etc you are welcome to try, but I can't help with any problems... I just don't have the time. ============================================== Kernel 2.4.32-rc1 - ------------------ I've patched the vanilla kernel to 2.4.32-rc1 level and added the ia64 patch for the normal page_not_found error in region 5 (whatever that means). The kernel website is not exactly up to date on this... I think the web people are on vacation or something. Anyway, I patched these by hand from the posted gilt diffs. !!BE CAREFUL WITH UPDATING YOUR KERNEL!! SOURCES - ------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/kernel-2.4.30-2.4.fc1.vanilla.src.rpm BINARIES - -------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/kernel-doc-2.4.30-2.4.fc1.vanilla.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/kernel-source-2.4.30-2.4.fc1.vanilla.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/kernel-2.4.30-2.4.fc1.vanilla.i686.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/kernel-smp-2.4.30-2.4.fc1.vanilla.i686.rpm ============================================== SendMail 8.13.5 - ---------------- Sendmail.org released version 8.13.5 on 16-Sep-2005. I've just got around to updating the RPMs and etc for this. The release notes are here for those interested http://www.sendmail.org/8.13.5.html . SOURCES - ------- http://support.intcomgrp.com/mirror/fedora-core/beta/src/sendmail-8.13.5-0.fc1.src.rpm BINARIES - -------- http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sendmail-8.13.5-0.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sendmail-doc-8.13.5-0.fc1.i386.rpm http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sendmail-devel-8.13.5-0.fc1.i386.rpm *** MOST PEOPLE WILL NOT NEED TO UPGRADE THIS LAST PACKAGE *** http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sendmail-cf-8.13.5-0.fc1.i386.rpm Please be sure to clean and rebuild all your config files for sendmail. ~ Easiest way is to go to /etc/mail and type: ~ make clean ~ mkdir backup ~ mv *.cf backup ~ make all Ignore the error message about the .cf files. The makefile is setup to check the timestamps on the files and if the files are not there it still wants to copy / move the files that are not there when it goes to build the files from the .mc files. ===================================================================== All of my binary packages are signed..... http://support.intcomgrp.com/mirror/fedora-core/beta/RPM-GPG-KEY-JAMES The SHA1 Sums for the binaries are here: http://support.intcomgrp.com/mirror/fedora-core/beta/i386/sha1sum.txt The SHA1 Sums for the source files are here: http://support.intcomgrp.com/mirror/fedora-core/beta/src/sha1sum.txt I run a YUM server for FC1.... you can also point your updates to http://support.intcomgrp.com/mirror/fedora-core/beta/i386 BUT ONLY IF YOU WANT! ====================================================================== Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMrAckNLDmnu1kSkRA40OAJ9QnGbDzeeKAAyOlwvtXQWieC1F/ACeNEXb fJHi8tSCysxx7B7w9yPZXVs= =fB4v -----END PGP SIGNATURE----- From michal at harddata.com Thu Sep 22 15:58:06 2005 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 22 Sep 2005 09:58:06 -0600 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4332AE6B.8030002@yahoo.com>; from jimpop@yahoo.com on Thu, Sep 22, 2005 at 09:15:23AM -0400 References: <4332AE6B.8030002@yahoo.com> Message-ID: <20050922095806.A3637@mail.harddata.com> On Thu, Sep 22, 2005 at 09:15:23AM -0400, Jim Popovitch wrote: > Anyone know if this impacts FL? [ a description of Pyton problems from Debian advisory skipped ] Most likely this is the case. It is hard to imagine that somebody quietly fixed such hole in Python packages for Red Hat distributions and did not mention that anybody. Well, a pcre code could be possibly not compiled in but I am not sure if this is an option. If this is used as a shared library then fixing that in one place would fix all users but a quick look at some samples seems to show that this is not the case. OTOH I do not know in this moment if python-1.5, like the one used in RH7.3, has a code from pcre or not. If it does then the problem potentially is not limited to python2. > I did a quick BugTraq look at Pekka's > lists and didn't see it mentioned. Well, you could be the one who will add that to bugzilla. Of course if you would look first at patches Debian used, and also other pcre patches, and check before writing a bugzilla entry if they indeed apply that would be a truly good move. Michal From charles.f.johnson at intel.com Thu Sep 22 17:00:54 2005 From: charles.f.johnson at intel.com (Johnson, Charles F) Date: Thu, 22 Sep 2005 10:00:54 -0700 Subject: SATA Support for RH7.3 ?? Message-ID: <58719AF72C399343948CE6ADE4FD019502C97632@orsmsx405> Has anyone ever backported the SATA support in the newer 2.4 kernels to RH7.3 ??? Charles Johnson Channel Software Operation Intel Corporation charles.f.johnson at intel.com 503-712-5181 From gbailey at lxpro.com Thu Sep 22 17:05:10 2005 From: gbailey at lxpro.com (Greg Bailey) Date: Thu, 22 Sep 2005 10:05:10 -0700 Subject: SATA Support for RH7.3 ?? In-Reply-To: <58719AF72C399343948CE6ADE4FD019502C97632@orsmsx405> References: <58719AF72C399343948CE6ADE4FD019502C97632@orsmsx405> Message-ID: <4332E446.6090405@lxpro.com> Johnson, Charles F wrote: >Has anyone ever backported the SATA support in the newer 2.4 kernels to >RH7.3 ??? > >Charles Johnson >Channel Software Operation >Intel Corporation >charles.f.johnson at intel.com >503-712-5181 > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > I've done somthing similar for Red Hat 9. However, rather than backport the SATA support into the older kernel, I just replaced the kernel with the latest version (2.4.31). Then, you have to modify the hwdata RPM to recognize the SATA controllers and rebuild the anaconda installer if you want it to be installable on SATA hardware at installation time. -Greg From sarejusv at delfi.lt Thu Sep 22 17:11:34 2005 From: sarejusv at delfi.lt (auksiniz) Date: Thu, 22 Sep 2005 20:11:34 +0300 Subject: SATA Support for RH7.3 ?? In-Reply-To: <58719AF72C399343948CE6ADE4FD019502C97632@orsmsx405> References: <58719AF72C399343948CE6ADE4FD019502C97632@orsmsx405> Message-ID: <4332E5C6.9020800@delfi.lt> Right now the 2.4 kernel doesnt support SATA with out a patch to the kernel. At the moment if you want a kernel with that all ready built in you have to run with Suse 8.2 or newer. If your competent at recompiling kernels then you can either get the kernel module and recompile your current kernel or you can download and compile any one of the test/beta 2.5 or 2.6 kernels. Only catch is that the current module doesnt support raid on SATA for most raid chipsets which leaves me at a loss. Any way those are your choices unfortunately. Kernel 2.6 is going to rock the house, hang in there. -- http://www.daiva-foto.com -- Nebrangus ir kokybi?kas internetas http://www.dtiltas.lt D?MESIO! VYKSTA AKCIJOS http://www.dtiltas.lt/main.php?category=11&number=5 http://www.reklama.lt/ - ie?kantiems nuolaid?, akcij?, atrakcij? From jimpop at yahoo.com Thu Sep 22 16:35:34 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 22 Sep 2005 12:35:34 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050922095806.A3637@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> Message-ID: <4332DD56.6080700@yahoo.com> Michal Jaegermann wrote: > >>I did a quick BugTraq look at Pekka's >>lists and didn't see it mentioned. > > > Well, you could be the one who will add that to bugzilla. Of course > if you would look first at patches Debian used, and also other pcre > patches, and check before writing a bugzilla entry if they indeed > apply that would be a truly good move. Well, would prudent research also involve questioning others (such as this lists' readership) as well? ;-) If no one else responds with any data, I'll do some research and log any necessary bugs. -Jim P. From eduardo at log.furg.br Thu Sep 22 19:01:34 2005 From: eduardo at log.furg.br (Eduardo Albergone) Date: Thu, 22 Sep 2005 16:01:34 -0300 Subject: Vacation References: <1127254286.24908.95.camel@prometheus.gamehouse.com> Message-ID: <003201c5bfa8$0db67740$5a4e84c8@anp4> be carefull with rita eduardo ----- Original Message ----- From: "Jesse Keating" To: "Discussion of the Fedora Legacy Project" Sent: Tuesday, September 20, 2005 7:11 PM Subject: Vacation > I'm taking a vacation next week and will not be able to get email. I'll > be on a 7 day cruise to Mexico from California and I don't imagine they > have a lot of free wireless services on said boat. I'll bring the > laptop just in case, but my wife will likely throw me and it overboard > if she catches me using it (: > > Cheers! > > -- > 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 > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > From pekkas at netcore.fi Fri Sep 23 05:07:24 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 08:07:24 +0300 (EEST) Subject: releasing updates-testing packages without VERIFY votes In-Reply-To: <1125148443.14397.9.camel@mdlinux> References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> <1125148443.14397.9.camel@mdlinux> Message-ID: Hi, There was some discussion almost a month ago under the subject title "Fedora Legacy Test Update Notification: rp-pppoe" which didn't get wrapped up. In the interest of trying to wrap this up by making a specific proposal, I suggest changing the policy so that packages in updates-testing which haven't got any VERIFY votes could: - after 2 weeks, marked with a timeout - after the timeout of 4 weeks [i.e., 6 weeks total] be officially published (And rp-pppoe and squid currently in updates-testing could be released immediately upon the acceptance of this policy.) On Sat, 27 Aug 2005, Marc Deslauriers wrote: > On Sat, 2005-08-27 at 08:49 +0300, Pekka Savola wrote: >> 1) officially forgetting the update, removing it from >> updates-testing, and from the issue lists >> 2) specially marking "QA still needed but these are very low >> priority" updates, or >> 3) just releasing them with lower amount of QA or no QA at all after >> some timeout (e.g., 6 weeks) and revising if someone complains it >> doesn't work right. >> > > I vote to just release them after a long timeout period. If there are > any issues, we can quickly fix them afterwards. We most often use > patches that came from upstream or from another distro anyway, so most > of them have already gone through QA. > > It just doesn't make sense to have stuff in the updates-testing > directory for ever. > >> I don't have strong preference here, but I think 3) would probably be >> best. If no-one wants to do (official) QA, we could just release the >> update if it looks trivial, and fix it later if something is reported >> to break. >> > > I think that is a good idea. > > Marc. > -- 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 Sep 23 05:11:00 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 08:11:00 +0300 (EEST) Subject: issues list(s) Message-ID: Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting In particular, IMHO the biggest need right now is getting people to propose updated packages for *ALL* the distribution versions (this is challenging at least for me because I don't have access to all of them -- are there any ways to make this easier). There are also 4 pretty trivial updates in "lacking PUBLISH" category. Lots of packages also need updates, but I don't think folks are inclined to create these until more people show up to do QA on the existing ones. 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 jkeating at j2solutions.net Fri Sep 23 07:21:04 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Sep 2005 00:21:04 -0700 Subject: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> <1125148443.14397.9.camel@mdlinux> Message-ID: <1127460064.2933.69.camel@yoda.loki.me> On Fri, 2005-09-23 at 08:07 +0300, Pekka Savola wrote: > I suggest changing the policy so that packages in updates-testing > which haven't got any VERIFY votes could: > > - after 2 weeks, marked with a timeout > - after the timeout of 4 weeks [i.e., 6 weeks total] be > officially published > > (And rp-pppoe and squid currently in updates-testing could be released > immediately upon the acceptance of this policy.) If nobody else has a (reasonable) objection, I'm inclined to agree with this. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sheltren at cs.ucsb.edu Fri Sep 23 11:35:14 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 23 Sep 2005 07:35:14 -0400 (AST) Subject: releasing updates-testing packages without VERIFY votes In-Reply-To: <1127460064.2933.69.camel@yoda.loki.me> References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu><1125148443.14397.9.camel@mdlinux> <1127460064.2933.69.camel@yoda.loki.me> Message-ID: <49302.201.220.1.253.1127475314.squirrel@letters.cs.ucsb.edu> On Fri, September 23, 2005 3:21 am, Jesse Keating said: > On Fri, 2005-09-23 at 08:07 +0300, Pekka Savola wrote: >> I suggest changing the policy so that packages in updates-testing >> which haven't got any VERIFY votes could: >> >> - after 2 weeks, marked with a timeout >> - after the timeout of 4 weeks [i.e., 6 weeks total] be >> officially published >> >> (And rp-pppoe and squid currently in updates-testing could be released >> immediately upon the acceptance of this policy.) > > If nobody else has a (reasonable) objection, I'm inclined to agree with > this. > I'll second (third?) that. If there isn't a large enough user base for a package that we can get verifies, I think that releasing the security fix after a timeout is a good thing. We may need stipulations for this for more 'critical' packages (kernel, glibc, etc. come to mind), but those usually have quite a bit of interest and therefore get tested more extensively. -Jeff From eric.rostetter at physics.utexas.edu Fri Sep 23 16:27:40 2005 From: eric.rostetter at physics.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 11:27:40 -0500 Subject: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> <1125148443.14397.9.camel@mdlinux> Message-ID: <1127492860.1b1d605ac2853@mail.ph.utexas.edu> Quoting Pekka Savola : > I suggest changing the policy so that packages in updates-testing > which haven't got any VERIFY votes could: First, let me say that it would take less time for the people invloved in these "lets publish without QA" discussions to just QA the packages than they are spending arguing if we should publish them without any QA. But, back to the current point of discussion... > - after 2 weeks, marked with a timeout > - after the timeout of 4 weeks [i.e., 6 weeks total] be > officially published This goes against everything this group was founded on, and all Best Practices. However, it does seem to be popular with the few folks involved in these conversations. So, I'll approve of this, but only if ammended to include the following: After the 2 week period when it is marked with a timeout, a message MUST be posted to the fedoral-legacy-list at redhat.com informing people that it is being marked for timeout, and making a plee for people to QA test it. In addition, if it is released without any QA, the bug ticket for the package MUST note that it was released without any QA. > (And rp-pppoe and squid currently in updates-testing could be released > immediately upon the acceptance of this policy.) I've just submitted QA for those for RHL 7.3 and RHL 9. Take those votes for what you will. I guess there is still a question: If I QA a package on RL 7.3 and RHL 9 is that one vote (since one person did the QA) or two votes (since I did two OS versions)? > > I vote to just release them after a long timeout period. If there are > > any issues, we can quickly fix them afterwards. We most often use > > patches that came from upstream or from another distro anyway, so most > > of them have already gone through QA. I agree, with the above stipulation about announcing it to the mailing list and marking it as such in Bugzilla. -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From rostetter at mail.utexas.edu Fri Sep 23 16:29:45 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 11:29:45 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes Message-ID: <1127492985.556df2210fc83@mail.ph.utexas.edu> Arg, sent with wrong From: address, so here it is again, since the moderator probably won't get to it for a while... ----- Forwarded message ----- Subject: Re: releasing updates-testing packages without VERIFY votes To: fedora-legacy-list at redhat.com Quoting Pekka Savola : > I suggest changing the policy so that packages in updates-testing > which haven't got any VERIFY votes could: First, let me say that it would take less time for the people invloved in these "lets publish without QA" discussions to just QA the packages than they are spending arguing if we should publish them without any QA. But, back to the current point of discussion... > - after 2 weeks, marked with a timeout > - after the timeout of 4 weeks [i.e., 6 weeks total] be > officially published This goes against everything this group was founded on, and all Best Practices. However, it does seem to be popular with the few folks involved in these conversations. So, I'll approve of this, but only if ammended to include the following: After the 2 week period when it is marked with a timeout, a message MUST be posted to the fedoral-legacy-list at redhat.com informing people that it is being marked for timeout, and making a plee for people to QA test it. In addition, if it is released without any QA, the bug ticket for the package MUST note that it was released without any QA. > (And rp-pppoe and squid currently in updates-testing could be released > immediately upon the acceptance of this policy.) I've just submitted QA for those for RHL 7.3 and RHL 9. Take those votes for what you will. I guess there is still a question: If I QA a package on RL 7.3 and RHL 9 is that one vote (since one person did the QA) or two votes (since I did two OS versions)? > > I vote to just release them after a long timeout period. If there are > > any issues, we can quickly fix them afterwards. We most often use > > patches that came from upstream or from another distro anyway, so most > > of them have already gone through QA. I agree, with the above stipulation about announcing it to the mailing list and marking it as such in Bugzilla. -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! ----- End forwarded message ----- -- Eric Rostetter From mike.mccarty at sbcglobal.net Fri Sep 23 16:44:31 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 23 Sep 2005 11:44:31 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <1127492985.556df2210fc83@mail.ph.utexas.edu> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> Message-ID: <433430EF.3050305@sbcglobal.net> Eric Rostetter wrote: > Arg, sent with wrong From: address, so here it is again, since the moderator > probably won't get to it for a while... > > ----- Forwarded message ----- > Subject: Re: releasing updates-testing packages without VERIFY votes > To: fedora-legacy-list at redhat.com > > Quoting Pekka Savola : > > >>I suggest changing the policy so that packages in updates-testing >>which haven't got any VERIFY votes could: > > > First, let me say that it would take less time for the people invloved in these > "lets publish without QA" discussions to just QA the packages than they are > spending arguing if we should publish them without any QA. But, back to > the current point of discussion... > > >> - after 2 weeks, marked with a timeout >> - after the timeout of 4 weeks [i.e., 6 weeks total] be >> officially published > > > This goes against everything this group was founded on, and all Best > Practices. However, it does seem to be popular with the few folks > involved in these conversations. So, I'll approve of this, but only > if ammended to include the following: Well I don't. I object to it, period. It's not only not best practice, it's bad practice. If no one picks it up, and tests it, then how do we know it doesn't create a worse problem than it reputedly solves? [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From wstockal at compusmart.ab.ca Fri Sep 23 17:03:55 2005 From: wstockal at compusmart.ab.ca (William Stockall) Date: Fri, 23 Sep 2005 11:03:55 -0600 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433430EF.3050305@sbcglobal.net> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> Message-ID: <4334357B.3050701@compusmart.ab.ca> I concur with Mr. McCarty. If untested updates are moved in with the tested updates then NONE of the updates can be trusted. Who wants to go back to the bug entry to check for sure if an update actually got tested prior to rolling it out? Also, if there was little enough interest that no one tested the patch, why is it so important that it be rolled out at all? If they are rolled out, they should at least be kept separate from the tested updates. That way people can choose whether they add that repository to pull updates from. Will. Mike McCarty wrote: > Eric Rostetter wrote: > >> Arg, sent with wrong From: address, so here it is again, since the >> moderator >> probably won't get to it for a while... >> >> ----- Forwarded message ----- >> Subject: Re: releasing updates-testing packages without VERIFY votes >> To: fedora-legacy-list at redhat.com >> >> Quoting Pekka Savola : >> >> >>> I suggest changing the policy so that packages in updates-testing >>> which haven't got any VERIFY votes could: >> >> >> >> First, let me say that it would take less time for the people invloved >> in these >> "lets publish without QA" discussions to just QA the packages than >> they are >> spending arguing if we should publish them without any QA. But, back to >> the current point of discussion... >> >> >>> - after 2 weeks, marked with a timeout >>> - after the timeout of 4 weeks [i.e., 6 weeks total] be >>> officially published >> >> >> >> This goes against everything this group was founded on, and all Best >> Practices. However, it does seem to be popular with the few folks >> involved in these conversations. So, I'll approve of this, but only >> if ammended to include the following: > > > Well I don't. I object to it, period. It's not only not best practice, > it's bad practice. > > If no one picks it up, and tests it, then how do we know it doesn't > create a worse problem than it reputedly solves? > > [snip] > > Mike From pekkas at netcore.fi Fri Sep 23 17:21:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 20:21:59 +0300 (EEST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <1127492985.556df2210fc83@mail.ph.utexas.edu> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> Message-ID: On Fri, 23 Sep 2005, Eric Rostetter wrote: > I guess there is still a question: If I QA a package on RL 7.3 and RHL 9 > is that one vote (since one person did the QA) or two votes (since I did > two OS versions)? That's two votes, by current counting. -- 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 maillist at jasonlim.com Fri Sep 23 17:32:25 2005 From: maillist at jasonlim.com (Jason Lim) Date: Sat, 24 Sep 2005 01:32:25 +0800 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes References: <1127492985.556df2210fc83@mail.ph.utexas.edu><433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> Message-ID: <25ef01c5c064$c57d8f50$6400a8c0@tw1> To tell the truth, to me at least, to support legacy systems I only really care about critical security updates that could remotely compromise the system (not even theoretical stuff is of interest). Even local compromise is not THAT important to me... but in my view, a critical remote vulnerability should get priority, and at least those should get tested, everything else can really take the back burner. I think we need to spend our very limited energy more productively. If someone wants to use updates that supposedly haven't been tested, they can use the testing respository, right? Nothing stopping them from using it. As for everyone else... I'm more about plain old stability. Think about the people still using legacy systems like RH9, they obviously aren't "leading-edge" or anything, and probably aren't interested in little bug fixes here and there, and would probably only be interested in the worst-case security problems. ----- Original Message ----- From: "William Stockall" To: "Discussion of the Fedora Legacy Project" Sent: Saturday, September 24, 2005 1:03 AM Subject: Re: Fwd: Re: releasing updates-testing packages without VERIFY votes > I concur with Mr. McCarty. If untested updates are moved in with the > tested updates then NONE of the updates can be trusted. Who wants to go > back to the bug entry to check for sure if an update actually got tested > prior to rolling it out? > > Also, if there was little enough interest that no one tested the patch, > why is it so important that it be rolled out at all? If they are rolled > out, they should at least be kept separate from the tested updates. > That way people can choose whether they add that repository to pull > updates from. > > > Will. > Mike McCarty wrote: > > Eric Rostetter wrote: > > > >> Arg, sent with wrong From: address, so here it is again, since the > >> moderator > >> probably won't get to it for a while... > >> > >> ----- Forwarded message ----- > >> Subject: Re: releasing updates-testing packages without VERIFY votes > >> To: fedora-legacy-list at redhat.com > >> > >> Quoting Pekka Savola : > >> > >> > >>> I suggest changing the policy so that packages in updates-testing > >>> which haven't got any VERIFY votes could: > >> > >> > >> > >> First, let me say that it would take less time for the people invloved > >> in these > >> "lets publish without QA" discussions to just QA the packages than > >> they are > >> spending arguing if we should publish them without any QA. But, back to > >> the current point of discussion... > >> > >> > >>> - after 2 weeks, marked with a timeout > >>> - after the timeout of 4 weeks [i.e., 6 weeks total] be > >>> officially published > >> > >> > >> > >> This goes against everything this group was founded on, and all Best > >> Practices. However, it does seem to be popular with the few folks > >> involved in these conversations. So, I'll approve of this, but only > >> if ammended to include the following: > > > > > > Well I don't. I object to it, period. It's not only not best practice, > > it's bad practice. > > > > If no one picks it up, and tests it, then how do we know it doesn't > > create a worse problem than it reputedly solves? > > > > [snip] > > > > Mike > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From pekkas at netcore.fi Fri Sep 23 17:25:52 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 20:25:52 +0300 (EEST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <4334357B.3050701@compusmart.ab.ca> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> Message-ID: On Fri, 23 Sep 2005, William Stockall wrote: > I concur with Mr. McCarty. If untested updates are moved in with the tested > updates then NONE of the updates can be trusted. Who wants to go back to the > bug entry to check for sure if an update actually got tested prior to rolling > it out? > > Also, if there was little enough interest that no one tested the patch, why > is it so important that it be rolled out at all? If they are rolled out, > they should at least be kept separate from the tested updates. That way > people can choose whether they add that repository to pull updates from. The energy has already been spent in proposing the updates, doing publish QA on them, building them in mach and sending out testing notifications, etc. It is HIGHLY discouraging to do any QA work if you can end up in the situation "well, nobody seemed to care. Sorry for your wasted effort on this package". -- 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 Fri Sep 23 17:32:53 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 12:32:53 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433430EF.3050305@sbcglobal.net> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> Message-ID: <1127496773.cca84ccac14a4@mail.ph.utexas.edu> Quoting Mike McCarty : > Eric Rostetter wrote: > > This goes against everything this group was founded on, and all Best > > Practices. However, it does seem to be popular with the few folks > > involved in these conversations. So, I'll approve of this, but only > > if ammended to include the following: > > Well I don't. I object to it, period. It's not only not best practice, > it's bad practice. I agree. > If no one picks it up, and tests it, then how do we know it doesn't > create a worse problem than it reputedly solves? I agree. But I'm tired of being on the losing side of the same battle every 3-6 months... > Mike I'm hoping that if we send the message to the mailing list, it will prompt people like me to at least *try* to do some limited QA testing... And I insist we note it in the bugzilla, and now that I think about it in the advisory notice also, so people doing due diligence (reading the advisory before installing) will know that it hasn't been QA'd and they need to do their own QA if they want to use it. -- Eric Rostetter From wstockal at compusmart.ab.ca Fri Sep 23 17:41:48 2005 From: wstockal at compusmart.ab.ca (William Stockall) Date: Fri, 23 Sep 2005 11:41:48 -0600 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> Message-ID: <43343E5C.6000607@compusmart.ab.ca> Pekka Savola wrote: > On Fri, 23 Sep 2005, William Stockall wrote: > > The energy has already been spent in proposing the updates, doing > publish QA on them, building them in mach and sending out testing > notifications, etc. > > It is HIGHLY discouraging to do any QA work if you can end up in the > situation "well, nobody seemed to care. Sorry for your wasted effort on > this package". > While I agree it is discouraging for your effort to seem to go to waste, the goal of an update can't just be an ego boost for the person who prepared it, either. I don't have any problem with updates being produced, as long as the tested updates are separate from the untested ones. Will. From sheltren at cs.ucsb.edu Fri Sep 23 18:12:24 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 23 Sep 2005 14:12:24 -0400 (AST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <4334357B.3050701@compusmart.ab.ca> References: <1127492985.556df2210fc83@mail.ph.utexas.edu><433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> Message-ID: <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> On Fri, September 23, 2005 1:03 pm, William Stockall said: > I concur with Mr. McCarty. If untested updates are moved in with the > tested updates then NONE of the updates can be trusted. Who wants to go > back to the bug entry to check for sure if an update actually got tested > prior to rolling it out? > > Also, if there was little enough interest that no one tested the patch, > why is it so important that it be rolled out at all? If they are rolled > out, they should at least be kept separate from the tested updates. > That way people can choose whether they add that repository to pull > updates from. > > > Will. Well, if you are serious about having a stable system, you should always test the packages yourself on a mock-production machine, otherwise you can never be sure that the package won't break your system, no matter how many other people have tested it previously. Second, lack of interest in QAing a package does not make the security issue any less of a threat. When people point yum to use FL repos, they are under the impression that they will get security patches in a timely manner. Due to a lack of (wo)man power, it already takes us long enough to get packages out - if we have packages sitting in updates-testing for months/years, we are simply doing a dis-service to those who are using FL with the belief that they are safe simply having a nightly yum update run. Most of the patches we used come straight from RHEL or FC RPMs which have received quite a bit of QA before release - and that makes me feel more confident in having this sort of timeout for packages we can't get enough verifies for. -Jeff From rostetter at mail.utexas.edu Fri Sep 23 18:47:27 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 13:47:27 -0500 Subject: issues list(s) In-Reply-To: References: Message-ID: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> Quoting Pekka Savola : > Remember, there's always a need for folks to do some QA testing. See the I've done PUBLISH QA for enscript and a2ps, but I can't update the whiteboard, so someone else will have to do that. I did VERIFY QA for rp-pppoe and squid, but again, can't update the whiteboard. -- Eric Rostetter From mike.mccarty at sbcglobal.net Fri Sep 23 18:58:10 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 23 Sep 2005 13:58:10 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <25ef01c5c064$c57d8f50$6400a8c0@tw1> References: <1127492985.556df2210fc83@mail.ph.utexas.edu><433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <25ef01c5c064$c57d8f50$6400a8c0@tw1> Message-ID: <43345042.90900@sbcglobal.net> Jason Lim wrote: > To tell the truth, to me at least, to support legacy systems I only really > care about critical security updates that could remotely compromise the > system (not even theoretical stuff is of interest). Even local compromise is > not THAT important to me... but in my view, a critical remote vulnerability > should get priority, and at least those should get tested, everything else > can really take the back burner. > > I think we need to spend our very limited energy more productively. > > If someone wants to use updates that supposedly haven't been tested, they > can use the testing respository, right? Nothing stopping them from using it. > As for everyone else... I'm more about plain old stability. Think about the Sir, you have struck the nail upon the head with perfect orthogonality. Why Legacy support? For stability. Putting things into a "release state" without "full" (whatever that is) QA compromises stability. So if you do that, then why have the Legacy support at all? No reason that I can see. If Legacy support does this, then I'm moving to CentOS. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From shiva at sewingwitch.com Fri Sep 23 18:56:57 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 23 Sep 2005 11:56:57 -0700 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> Message-ID: --On Friday, September 23, 2005 2:12 PM -0400 Jeff Sheltren wrote: > Second, lack of interest in QAing a package does not make the security > issue any less of a threat. This is to me the real incentive for moving updates from testing to released after a timeout. Any non-security updates should remain in testing for those (like me) willing to forgo the QA. From pekkas at netcore.fi Fri Sep 23 19:12:39 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 22:12:39 +0300 (EEST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> Message-ID: On Fri, 23 Sep 2005, Kenneth Porter wrote: > This is to me the real incentive for moving updates from testing to released > after a timeout. Any non-security updates should remain in testing for those > (like me) willing to forgo the QA. Maybe you missed the point of Fedora Legacy. We don't do any updates which don't fix security issues. (There are very, very few exceptions -- e.g., a proposal to update 'rpm' to fix the lockup issues, 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 mike.mccarty at sbcglobal.net Fri Sep 23 19:13:43 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 23 Sep 2005 14:13:43 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> Message-ID: <433453E7.3000509@sbcglobal.net> Kenneth Porter wrote: > --On Friday, September 23, 2005 2:12 PM -0400 Jeff Sheltren > wrote: > >> Second, lack of interest in QAing a package does not make the security >> issue any less of a threat. > > > This is to me the real incentive for moving updates from testing to > released after a timeout. Any non-security updates should remain in > testing for those (like me) willing to forgo the QA. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > As far as I can see, the sole reason for existence of the Fedora Legacy is stability. If I were willing to forego the stability, I'd upgrade to FC4 right now, today. I'm not willing to do that, so I came to Legacy. If Legacy compromises stability, then I see no need for it to exist. If Legacy takes this move, then I predict mass exodus. I'm not going to contribute further to this thread, unless a vote on the future of Legacy is called for, as I think I have presented all the argument that there is, or even should need to be. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From pekkas at netcore.fi Fri Sep 23 19:16:33 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 22:16:33 +0300 (EEST) Subject: issues list(s) In-Reply-To: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> Message-ID: On Fri, 23 Sep 2005, Eric Rostetter wrote: > Quoting Pekka Savola : > >> Remember, there's always a need for folks to do some QA testing. See the > > I've done PUBLISH QA for enscript and a2ps, but I can't update the > whiteboard, so someone else will have to do that. > > I did VERIFY QA for rp-pppoe and squid, but again, can't update the whiteboard. Thanks. I did update the whiteboard for VERIFYs. (Only the bug creator and specially privileged folks can edit these, unfortunately.) I didn't yet update the PUBLISH votes, because the patches need to be verified, check the requirements at: http://www.fedoraproject.org/wiki/Legacy/QAPublish In additionl, PUBLISH needs to be done for all distro versions before the package can be built. Would it be possible to the FC1 review for a2ps? -- 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 Fri Sep 23 19:18:48 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Sep 2005 12:18:48 -0700 Subject: To Timeout or Not Message-ID: <1127503128.16225.48.camel@prometheus.gamehouse.com> I see there are lots of thoughts on this issue. I'm seeing positive and negative responses. Given that I'm taking the next week off, I don't really want to make a decision just yet. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From pekkas at netcore.fi Fri Sep 23 19:19:21 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Sep 2005 22:19:21 +0300 (EEST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433453E7.3000509@sbcglobal.net> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> <433453E7.3000509@sbcglobal.net> Message-ID: On Fri, 23 Sep 2005, Mike McCarty wrote: > If Legacy takes this move, then I predict mass exodus. If nothing happens, I predict mass exodus for the QA testers involved in the project. Wait... That has already happened. There are less than 5 people who do this stuff at least in semi-regular manner. Maybe folks writing on the list should consider how they could contribute to Fedora Legacy process so that we wouldn't NEED to have this discussion in the first place. -- 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 shiva at sewingwitch.com Fri Sep 23 19:26:04 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 23 Sep 2005 12:26:04 -0700 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433453E7.3000509@sbcglobal.net> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> <433453E7.3000509@sbcglobal.net> Message-ID: <68113C03656810EEC13E490D@[10.169.6.233]> --On Friday, September 23, 2005 2:13 PM -0500 Mike McCarty wrote: > As far as I can see, the sole reason for existence of the Fedora > Legacy is stability. If I were willing to forego the stability, > I'd upgrade to FC4 right now, today. I'm not willing to do that, > so I came to Legacy. I have 3 FC2 servers I'd love to put FC4 on but am blocked for various reasons, none really "stability", at least for packages not required to boot the system. One is colo'd, and I'm uncomfortable to do an upgrade of that scope without physical access. One has old hardware (MegaRAID IDE) and I need to first get a working kernel (in progress, need to build a test boot CD) before I can update. The last is waiting for adequate downtime to effect the upgrade. (I'll be copying the drive, then upgrading with the copy.) For all of these servers I update piecemeal, often from Rawhide SRPM's to get something close to the upstream stable release. For some packages with good SRPM's upstream, I'll go straight to those. (I just did that for SpamAssassin.) From sheltren at cs.ucsb.edu Fri Sep 23 19:47:17 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 23 Sep 2005 15:47:17 -0400 (AST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433453E7.3000509@sbcglobal.net> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> <433453E7.3000509@sbcglobal.net> Message-ID: <50200.201.220.2.30.1127504837.squirrel@letters.cs.ucsb.edu> On Fri, September 23, 2005 3:13 pm, Mike McCarty said: > > As far as I can see, the sole reason for existence of the Fedora > Legacy is stability. If I were willing to forego the stability, > I'd upgrade to FC4 right now, today. I'm not willing to do that, > so I came to Legacy. > > If Legacy compromises stability, then I see no need for it to exist. > > If Legacy takes this move, then I predict mass exodus. > > I'm not going to contribute further to this thread, unless a vote on > the future of Legacy is called for, as I think I have presented all > the argument that there is, or even should need to be. > > Mike OK, but from my point of view, the purpose of FL is to extend the EOL of old RedHat/Fedora distributions by providing security (and only security) updates. How stable is your box going to be when it gets exploited with an old security hole for which the fix is sitting in updates-testing due to lack of QA? Don't answer that, it's a rhetorical quesiton. The point is, in order to obtain this stability you speak of, Fedora Legacy needs to make security updates in a timely manner. -Jeff From michal at harddata.com Fri Sep 23 20:55:29 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 23 Sep 2005 14:55:29 -0600 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <25ef01c5c064$c57d8f50$6400a8c0@tw1>; from maillist@jasonlim.com on Sat, Sep 24, 2005 at 01:32:25AM +0800 References: <1127492985.556df2210fc83@mail.ph.utexas.edu><433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <25ef01c5c064$c57d8f50$6400a8c0@tw1> Message-ID: <20050923145529.C5689@mail.harddata.com> On Sat, Sep 24, 2005 at 01:32:25AM +0800, Jason Lim wrote: > Even local compromise is > not THAT important to me... The problem, of course, is that if you have a local compromise and somebody managed to get a remote shell (by a social engineering tricks or whatever) this immediately converts that into a remote compromise. Michal From sheltren at cs.ucsb.edu Sat Sep 24 00:13:57 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 23 Sep 2005 20:13:57 -0400 Subject: issues list(s) In-Reply-To: References: Message-ID: On Sep 23, 2005, at 1:11 AM, Pekka Savola wrote: > > In particular, IMHO the biggest need right now is getting people to > propose updated packages for *ALL* the distribution versions (this > is challenging at least for me because I don't have access to all > of them -- are there any ways to make this easier). Are you talking about creating packages for each distribution, or QAing them? If it's for creating them, I'd suggest using mock. See: http://fedoraproject.org/wiki/Legacy/Mock Note that Paul Howarth found a bug in FC1 glibc which causes FC1 build root creation to fail on 32bit processors (everything seems to work fine on x86_64). I think this can be fixed like so: ---------- The workaround is to turn off vDSO support in the host kernel: # sysctl -w kernel.vdso=0 ---------- I need to add that to the wiki page I suppose. -Jeff From rostetter at mail.utexas.edu Sat Sep 24 04:11:26 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 23:11:26 -0500 Subject: issues list(s) In-Reply-To: References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> Message-ID: <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> Quoting Pekka Savola : > I did update the whiteboard for VERIFYs. (Only the bug creator and > specially privileged folks can edit these, unfortunately.) Thanks. > I didn't yet update the PUBLISH votes, because the patches need to be > verified, check the requirements at: > > http://www.fedoraproject.org/wiki/Legacy/QAPublish That doesn't explicitely state that I must do so. If each of the things there *must* be done, then you need to make that more clear, and restate things that are optional as being optional, and restate what you mean since it isn't clear. I did diff the files, I did inspect the patch(es). I even *tested* the patched packages to make sure they fixed the problem. I didn't see anything unusal when I look at the patched code. I just didn't try to find the "original source" or "upstream patch" it was based on and compare them. Since others have already (before me) verified the patches versus the upstream provider, I think it can be implied that they are valid in my version since the sha1sum matched for both them and me. If not, the other person needs to be banished. ;) But I see there is a trust issue here, so I get why I should have done this step. > In additionl, PUBLISH needs to be done for all distro versions before > the package can be built. Would it be possible to the FC1 review for > a2ps? No, I don't run FC1. So, are my PUBLISH votes worth zero votes since I didn't compare the patch against the upstream publisher's version, dispite all the other work I did? Or maybe they can at least be a 0.5 vote? > -- > 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 rostetter at mail.utexas.edu Sat Sep 24 04:19:56 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Sep 2005 23:19:56 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <50034.201.220.2.30.1127499144.squirrel@letters.cs.ucsb.edu> <433453E7.3000509@sbcglobal.net> Message-ID: <1127535596.98095460e5865@mail.ph.utexas.edu> Quoting Pekka Savola : > On Fri, 23 Sep 2005, Mike McCarty wrote: > > If Legacy takes this move, then I predict mass exodus. > > If nothing happens, I predict mass exodus for the QA testers involved > in the project. > > Wait... > > That has already happened. There are less than 5 people who do this > stuff at least in semi-regular manner. There was no mass exodus, as there were never more than a handful of people anyway. > Maybe folks writing on the list should consider how they could > contribute to Fedora Legacy process so that we wouldn't NEED to have > this discussion in the first place. Yes, like I said previously, we spend more time arguing about this than it would take to just do the QA in the first place. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From pekkas at netcore.fi Sat Sep 24 09:21:55 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Sep 2005 12:21:55 +0300 (EEST) Subject: issues list(s) In-Reply-To: <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> Message-ID: On Fri, 23 Sep 2005, Eric Rostetter wrote: >> I didn't yet update the PUBLISH votes, because the patches need to be >> verified, check the requirements at: >> >> http://www.fedoraproject.org/wiki/Legacy/QAPublish > > That doesn't explicitely state that I must do so. If each of the things > there *must* be done, then you need to make that more clear, and restate > things that are optional as being optional, and restate what you mean since > it isn't clear. It should: the first three steps are mandatory. I tried to see if I could add clarification on this, but apparently I don't have the edit rights for the page (shouldn't it be more open?) The latter bullet points are optional (which is mentioned there), implying (but not saying) that the previous ones are mandatory. > I did diff the files, I did inspect the patch(es). I even *tested* the > patched packages to make sure they fixed the problem. I didn't see > anything unusal when I look at the patched code. I just didn't try to find > the "original source" or "upstream patch" it was based on and compare them. > > Since others have already (before me) verified the patches versus the > upstream provider, I think it can be implied that they are valid > in my version since the sha1sum matched for both them and me. If not, the > other person needs to be banished. ;) But I see there is a trust issue here, > so I get why I should have done this step. The others have only verified the patch on the OS version for which they gave a PUBLISH vote; the patches could be different -- one could have a trojan (or just a honest mistake!), while the already QA'd version doesn't. If the SHA1sum of the patches (already verified) matches the one at your OS version (i.e., the identical patch in multiple OS versions), yes, there is no technical reason to have to verify the patch again. But for clarity, it should be pointed in the PUBLISH vote message. >> In additionl, PUBLISH needs to be done for all distro versions before >> the package can be built. Would it be possible to the FC1 review for >> a2ps? > > No, I don't run FC1. As you wish, but note that giving PUBLISH votes does not require one to run the OS version in question. I.e., it is not required to test the package; just reviewing 1) source integrity, 2) the .spec file, and 3) the new patches [if they come from an already-QA'd source] is sufficient. > So, are my PUBLISH votes worth zero votes since I didn't compare the > patch against the upstream publisher's version, dispite all the other > work I did? Or maybe they can at least be a 0.5 vote? I'm a bit impartial in this because I proposed the packages in the first place, but I think verifying the patches is essential. Even thorough testing of the packages may not show problems if the patch is not (quite) right. -- 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 Sat Sep 24 09:26:31 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Sep 2005 12:26:31 +0300 (EEST) Subject: Mock [Re: issues list(s)] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2005, Jeff Sheltren wrote: > Are you talking about creating packages for each distribution, or QAing them? > If it's for creating them, I'd suggest using mock. Creating, yes. > See: > http://fedoraproject.org/wiki/Legacy/Mock > > Note that Paul Howarth found a bug in FC1 glibc which causes FC1 build root > creation to fail on 32bit processors (everything seems to work fine on > x86_64). I think this can be fixed like so: > ---------- > The workaround is to turn off vDSO support in the host kernel: > # sysctl -w kernel.vdso=0 > ---------- Hmm.. I guess this requires having quick access to all the RPMs in all the OS versions so building can be done quickly. Maybe the Fedora Legacy should provide 'Mock' as a service for creating packages for PUBLISH QA? That way all folks wouldn't need to set up their own Mock systems. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sheltren at cs.ucsb.edu Sat Sep 24 10:33:59 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 24 Sep 2005 06:33:59 -0400 Subject: Mock [Re: issues list(s)] In-Reply-To: References: Message-ID: <506815A5-E52B-4AAE-8C95-6A97B8E4F6E2@cs.ucsb.edu> On Sep 24, 2005, at 5:26 AM, Pekka Savola wrote: > > Hmm.. I guess this requires having quick access to all the RPMs in > all the OS versions so building can be done quickly. > > Maybe the Fedora Legacy should provide 'Mock' as a service for > creating packages for PUBLISH QA? > > That way all folks wouldn't need to set up their own Mock systems. Yes, you'll want to have a local (either on your LAN or on the build machine itself) mirror of the repositories. I like the idea of perhaps having a mock build system available to a handful of people who create packages for Legacy - it could perhaps be setup much the same way as the Fedora Extras build system, with the difference being, once it is built it spits it back out for you to download/post instead of queuing it for signing, release, etc. See http:// fedoraproject.org/wiki/Projects/Plague to read more about their build system. -Jeff From sheltren at cs.ucsb.edu Sat Sep 24 10:37:40 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 24 Sep 2005 06:37:40 -0400 Subject: issues list(s) In-Reply-To: References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> Message-ID: <3A2BC6CC-F658-452E-BE58-4D3FD3E2B366@cs.ucsb.edu> On Sep 24, 2005, at 5:21 AM, Pekka Savola wrote: > > It should: the first three steps are mandatory. I tried to see if > I could add clarification on this, but apparently I don't have the > edit rights for the page (shouldn't it be more open?) Most of our pages are setup with an ACL to only allow legacy people to edit the page. What is your username on the wiki? I'll see if I can add you to the group. -Jeff From deisenst at gtw.net Sat Sep 24 10:55:43 2005 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 24 Sep 2005 05:55:43 -0500 (CDT) Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4332DD56.6080700@yahoo.com> Message-ID: On Thu, 22 Sep 2005, Jim Popovitch wrote: > <>> > If no one else responds with any data, I'll do some research and log any > necessary bugs. > -Jim P. I think we're vulnerable to this in our distros. >From CAN-2005-2491: "Integer overflow in pcre_compile.c in Perl Compatible Regular Expressions (PCRE) before 6.2, as used in multiple products, allows attackers to execute arbitrary code via quantifier values in regular expressions, which leads to a heap-based buffer overflow." * pcre library (FL bug already opened: Bugzilla # 168516): Ref: Bugzilla 166330 (RHEL) - CAN-2005-2491 PCRE heap overflow Ref: RHSA-2005:761 - Moderate: pcre security update ). Ref: FEDORA-2005-802, Fedora Core 3 Update: pcre-4.5-3.1.1.fc3 Notification at Ref: FEDORA-2005-803, Fedora Core 4 Update: pcre-5.0-4.1.fc4 Notification at Our affected Packages: RH7.3: 265407 Apr 17 2002 pcre-3.9-2.src.rpm RH9: 266725 Feb 24 2003 pcre-3.9-10.src.rpm FC1: 346767 Oct 28 2003 pcre-4.4-1.src.rpm FC2: 355225 May 06 2004 pcre-4.5-2.src.rpm * python Ref: Bugzilla 166335 (RHEL) - CAN-2005-2491 PCRE heap overflow Ref: Bugzilla 168318 (FC3) - CAN-2005-2491 PCRE heap overflow -- Looks like RH Security team is assessing Python's vulnera- bility to this. Both Bugzilla items are still open. -- FL already has Python Bugzilla, # 152897, for another issue. Maybe we could fold this one in with it, if this is truly a vulnerability. Our potentially affected packages: RH7.3 updates: 3296238 Feb 12 2003 python-1.5.2-43.73.src.rpm RH7.3 updates: 6954498 Feb 12 2003 python2-2.2.2-11.7.3.src.rpm RH9: 6968043 Feb 25 2003 python-2.2.2-26.src.rpm FC1: 7008684 Jan 06 2004 python-2.2.3-7.src.rpm FC2: 7503689 May 07 2004 python-2.3.3-6.src.rpm From jimpop at yahoo.com Sat Sep 24 14:23:00 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 24 Sep 2005 10:23:00 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050922095806.A3637@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> Message-ID: <43356144.3080007@yahoo.com> Michal Jaegermann wrote: > On Thu, Sep 22, 2005 at 09:15:23AM -0400, Jim Popovitch wrote: > >>Anyone know if this impacts FL? > > > [ a description of Pyton problems from Debian advisory skipped ] > > Most likely this is the case. It is hard to imagine that somebody > quietly fixed such hole in Python packages for Red Hat distributions > and did not mention that anybody. Wouldn't this count: http://rhn.redhat.com/errata/RHSA-2005-761.html -Jim P. From michal at harddata.com Sat Sep 24 18:10:18 2005 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 24 Sep 2005 12:10:18 -0600 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <43356144.3080007@yahoo.com>; from jimpop@yahoo.com on Sat, Sep 24, 2005 at 10:23:00AM -0400 References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> Message-ID: <20050924121018.A29892@mail.harddata.com> On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: > Michal Jaegermann wrote: > > > > It is hard to imagine that somebody > > quietly fixed such hole in Python packages for Red Hat distributions > > and did not mention that anybody. > > Wouldn't this count: > http://rhn.redhat.com/errata/RHSA-2005-761.html Count to what? That above is a bug in pcre itself and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 is a corresponding bugzilla entry for Legacy packages. You were talking about the same bug showing up, unfortunately, in a different context. What David Eisenstein posted (thanks!) gives a lot of relevant cross-referrences. All that info should show up eventually in a Legacy bugzilla report. Michal From jimpop at yahoo.com Sat Sep 24 19:15:15 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 24 Sep 2005 15:15:15 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050924121018.A29892@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> Message-ID: <4335A5C3.3040502@yahoo.com> Michal Jaegermann wrote: > On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: > >>Michal Jaegermann wrote: >> >>>It is hard to imagine that somebody >>>quietly fixed such hole in Python packages for Red Hat distributions >>>and did not mention that anybody. >> >>Wouldn't this count: >> http://rhn.redhat.com/errata/RHSA-2005-761.html > > > Count to what? Count towards showing that RH had indeed released fixes. Isn't that what you were stating above, that you hadn't seen any releases for RH yet? -Jim P. From rostetter at mail.utexas.edu Sat Sep 24 20:19:38 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 24 Sep 2005 15:19:38 -0500 Subject: issues list(s) In-Reply-To: References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> Message-ID: <1127593178.78569923f0a85@mail.ph.utexas.edu> Quoting Pekka Savola : > On Fri, 23 Sep 2005, Eric Rostetter wrote: > >> I didn't yet update the PUBLISH votes, because the patches need to be > >> verified, check the requirements at: > >> > >> http://www.fedoraproject.org/wiki/Legacy/QAPublish > > > > That doesn't explicitely state that I must do so. If each of the things > > there *must* be done, then you need to make that more clear, and restate > > things that are optional as being optional, and restate what you mean since > > it isn't clear. > > It should: the first three steps are mandatory. I tried to see if I > could add clarification on this, but apparently I don't have the edit > rights for the page (shouldn't it be more open?) It isn't open any more due to the spam/abuse it was receiving previously. The "Required checklist" is at the bottom of the page. It says "Patches should be mainly taken from publicly available sources, e.g., other distributions such as RHEL, so that their correctness can be more easily verified." I didn't read this as "I need to do a direct comparison of the patch source code with the upstream provider's patch source code." So maybe it should be made more explicit. > The latter bullet points are optional (which is mentioned there), > implying (but not saying) that the previous ones are mandatory. I wouldn't count on that being interpreted that way. Especially since at the bottom of the page you have a "Required Checklist" for Publish which differs from the list at the top that you are trying to say is the required checklist. > > No, I don't run FC1. Yes, I said that, but it is wrong. Since you don't want me to actually test the code (which I did before) I don't need to run the code, so it doesn't matter that I don't run FC1, so I now retract that stupid statement. > As you wish, but note that giving PUBLISH votes does not require one > to run the OS version in question. I.e., it is not required to test > the package; just reviewing 1) source integrity, 2) the .spec file, > and 3) the new patches [if they come from an already-QA'd source] is > sufficient. I thought that was what I did, but you say I didn't since I didn't do a literal comparison of sources, but the wiki is unclear as to what needs to be done... > I'm a bit impartial in this because I proposed the packages in the > first place, but I think verifying the patches is essential. Even > thorough testing of the packages may not show problems if the patch is > not (quite) right. True. If I can get the time Monday I'll try to redo the tests. But someone really needs to re-write the wiki page, and when Pekka asks for help with QA he needs to make sure he says only PUBLISH votes following the wiki required checklist will be accepted. This requirement does not exist for VERIFY votes, and that should probably also be noted in Pekka's mails. This will avoid the confusion in the future. > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From michal at harddata.com Sat Sep 24 20:42:54 2005 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 24 Sep 2005 14:42:54 -0600 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4335A5C3.3040502@yahoo.com>; from jimpop@yahoo.com on Sat, Sep 24, 2005 at 03:15:15PM -0400 References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> Message-ID: <20050924144254.A32335@mail.harddata.com> On Sat, Sep 24, 2005 at 03:15:15PM -0400, Jim Popovitch wrote: > Michal Jaegermann wrote: > > On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: > > > >>Michal Jaegermann wrote: > >> > >>>It is hard to imagine that somebody > >>>quietly fixed such hole in Python packages for Red Hat distributions > >>>and did not mention that anybody. > >> > >>Wouldn't this count: > >> http://rhn.redhat.com/errata/RHSA-2005-761.html > > > > > > Count to what? > > Count towards showing that RH had indeed released fixes. Isn't that > what you were stating above, that you hadn't seen any releases for RH yet? Sigh! The above is about pcre itself and we are talking here about a code embedded in Python. Unfortunately this is an independet, although related, issue. There are now bugzilla numbers for that (#166335 and #168318) but AFAICS no releases so far. Would you like, please, to write a corresponding bugzilla entry for Legacy packages or we should ask David for that? It appears that he already collected all data. Michal From sheltren at cs.ucsb.edu Sat Sep 24 20:51:46 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 24 Sep 2005 16:51:46 -0400 Subject: issues list(s) In-Reply-To: <1127593178.78569923f0a85@mail.ph.utexas.edu> References: <1127501247.8d8ec37a129d0@mail.ph.utexas.edu> <1127535086.2bdd4f9ac6b09@mail.ph.utexas.edu> <1127593178.78569923f0a85@mail.ph.utexas.edu> Message-ID: On Sep 24, 2005, at 4:19 PM, Eric Rostetter wrote: >> > > It isn't open any more due to the spam/abuse it was receiving > previously. > > The "Required checklist" is at the bottom of the page. It says > > "Patches should be mainly taken from publicly available sources, > e.g., other > distributions such as RHEL, so that their correctness can be more > easily verified." > > I didn't read this as "I need to do a direct comparison of the > patch source > code with the upstream provider's patch source code." So maybe it > should > be made more explicit. Hi Eric, I've made some changes to the wiki page - let me know if that helps. Pekka, can you double check the changes as well? :) If I forgot something, please let me know. -Jeff From jimpop at yahoo.com Sat Sep 24 22:20:38 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 24 Sep 2005 18:20:38 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050924144254.A32335@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> Message-ID: <4335D136.4060005@yahoo.com> Michal Jaegermann wrote: > Would you like, please, to write a corresponding bugzilla entry for > Legacy packages or we should ask David for that? It appears that he > already collected all data. Maybe I'm missing something, didn't the move to RH's bugzilla negate the need for us to re-list our own bugs? Isn't a bug in pcre a bug in pcre regardless of the many flavors of RH that it affects? I'm not involved enough with bugzilla to know this, but it strikes me as odd that we would have a duplicate bug entries in the same system. -Jim P. From sheltren at cs.ucsb.edu Sat Sep 24 22:40:07 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 24 Sep 2005 18:40:07 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4335D136.4060005@yahoo.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> <4335D136.4060005@yahoo.com> Message-ID: On Sep 24, 2005, at 6:20 PM, Jim Popovitch wrote: > Michal Jaegermann wrote: > >> Would you like, please, to write a corresponding bugzilla entry for >> Legacy packages or we should ask David for that? It appears that he >> already collected all data. >> > > Maybe I'm missing something, didn't the move to RH's bugzilla > negate the need for us to re-list our own bugs? Isn't a bug in > pcre a bug in pcre regardless of the many flavors of RH that it > affects? I'm not involved enough with bugzilla to know this, but > it strikes me as odd that we would have a duplicate bug entries in > the same system. > > -Jim P. True, it is the same bug system, but we need our own bugs in order to track our package status, QA, etc. -Jeff From marcdeslauriers at videotron.ca Sun Sep 25 00:21:25 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 24 Sep 2005 20:21:25 -0400 Subject: releasing updates-testing packages without VERIFY votes In-Reply-To: References: <1125110788.1a54e28ba753e@mail.ph.utexas.edu> <1125148443.14397.9.camel@mdlinux> Message-ID: <1127607685.19154.18.camel@mdlinux> On Fri, 2005-09-23 at 08:07 +0300, Pekka Savola wrote: > I suggest changing the policy so that packages in updates-testing > which haven't got any VERIFY votes could: > > - after 2 weeks, marked with a timeout > - after the timeout of 4 weeks [i.e., 6 weeks total] be > officially published I agree with this. 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 Sun Sep 25 00:29:12 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 24 Sep 2005 20:29:12 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4335D136.4060005@yahoo.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> <4335D136.4060005@yahoo.com> Message-ID: <1127608152.19154.21.camel@mdlinux> On Sat, 2005-09-24 at 18:20 -0400, Jim Popovitch wrote: > Maybe I'm missing something, didn't the move to RH's bugzilla negate the > need for us to re-list our own bugs? Isn't a bug in pcre a bug in pcre > regardless of the many flavors of RH that it affects? I'm not involved > enough with bugzilla to know this, but it strikes me as odd that we > would have a duplicate bug entries in the same system. RH's bugzilla has a different bug open for each platform the bug appears on. So it should contain a bug for FC3, a bug for FC4, a bug for RHEL3, a bug for legacy-FC1, etc. 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 jimpop at yahoo.com Sun Sep 25 18:51:57 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sun, 25 Sep 2005 14:51:57 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050924144254.A32335@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> Message-ID: <4336F1CD.5080307@yahoo.com> Michal Jaegermann wrote: > On Sat, Sep 24, 2005 at 03:15:15PM -0400, Jim Popovitch wrote: > >>Michal Jaegermann wrote: >> >>>On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: >>> >>> >>>>Michal Jaegermann wrote: >>>> >>>> >>>>>It is hard to imagine that somebody >>>>>quietly fixed such hole in Python packages for Red Hat distributions >>>>>and did not mention that anybody. >>>> >>>>Wouldn't this count: >>>> http://rhn.redhat.com/errata/RHSA-2005-761.html >>> >>> >>>Count to what? >> >>Count towards showing that RH had indeed released fixes. Isn't that >>what you were stating above, that you hadn't seen any releases for RH yet? > > > Sigh! The above is about pcre itself and we are talking here about > a code embedded in Python. Unfortunately this is an independet, > although related, issue. There are now bugzilla numbers for that > (#166335 and #168318) but AFAICS no releases so far. > > Would you like, please, to write a corresponding bugzilla entry for > Legacy packages or we should ask David for that? It appears that he > already collected all data. > > Michal Michal, I am confused about all your comments on this thread. I first posted a question about this issue on 22-Sept. On that same day you suggested I add it to bugzilla, I chose to wait for further input. Now today I see that you already opened a bug back on 16-Sept https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 Why didn't you just say that this bug already existed? -Jim P. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 From jkeating at j2solutions.net Sun Sep 25 19:48:27 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 25 Sep 2005 12:48:27 -0700 Subject: Mock [Re: issues list(s)] In-Reply-To: <506815A5-E52B-4AAE-8C95-6A97B8E4F6E2@cs.ucsb.edu> References: <506815A5-E52B-4AAE-8C95-6A97B8E4F6E2@cs.ucsb.edu> Message-ID: <1127677707.2482.1.camel@localhost.localdomain> On Sat, 2005-09-24 at 06:33 -0400, Jeff Sheltren wrote: > Yes, you'll want to have a local (either on your LAN or on the build > machine itself) mirror of the repositories. I like the idea of > perhaps having a mock build system available to a handful of people > who create packages for Legacy - it could perhaps be setup much the > same way as the Fedora Extras build system, with the difference > being, once it is built it spits it back out for you to download/post > instead of queuing it for signing, release, etc. See http:// > fedoraproject.org/wiki/Projects/Plague to read more about their build > system. I'm working on converting our existing Legacy build server into a Plague/mock server. I have test hardware at my house that I am using to test it out before I deploy it over the system we currently use. When I get back from vacation (as I quickly look around to make sure my wife doesn't catch me answering email....) I'll be putting more effort into this. -- 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 michal at harddata.com Sun Sep 25 20:38:26 2005 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 25 Sep 2005 14:38:26 -0600 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <4336F1CD.5080307@yahoo.com>; from jimpop@yahoo.com on Sun, Sep 25, 2005 at 02:51:57PM -0400 References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> <4336F1CD.5080307@yahoo.com> Message-ID: <20050925143826.C22683@mail.harddata.com> On Sun, Sep 25, 2005 at 02:51:57PM -0400, Jim Popovitch wrote: > > Michal, I am confused about all your comments on this thread. You raised a possibility that PCRE bugs affect also various Python packages. Quite timely alert, I would say, and from all what we know by now you were right. After that we got some followups on the topic and some which left me somewhat baffled. > Now > today I see that you already opened a bug back on 16-Sept > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 Indeed I wrote that. But this is about bugs in 'pcre' package itself. Fixing that does not seem to help 'python' as that appears to re-cycle that code with security bugs directly and not using 'pcre' as a library. Even if that would be used as a statically linked library then all affected packages would need to be at least recompiled (but most likely they need direct patches). So the report you qoute is not sufficient as bugzilla entries are for a package and not for a bug with a list of all possible packages where this may apply. Therefore we need a corresponding entry in bugzilla. If you cannot and/or do not want to do that then say so and somebody else will have to write something up. > Why didn't you just say that this bug already existed? Eh? Was that not explicit enough? https://www.redhat.com/archives/fedora-legacy-list/2005-September/msg00110.html I thought also that explanations why http://rhn.redhat.com/errata/RHSA-2005-761.html is not good enough for us to track the issue were pretty clear. Obviously this can be _one of_ references. Michal From jancio_wodnik at wp.pl Sun Sep 25 20:40:20 2005 From: jancio_wodnik at wp.pl (Jancio Wodnik) Date: Sun, 25 Sep 2005 22:40:20 +0200 Subject: what about vsftpd - version 2.0.3 Message-ID: <43370B34.1050104@wp.pl> Hi all ! What is going on with vsftpd for legacy systems: FC2 ? there is version 2.0.3 on their website. Anybody working with that to pull vsftpd 2.0.3 for fedora legacy ? Regards, Jancio Wodnik From sheltren at cs.ucsb.edu Sun Sep 25 20:40:54 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 25 Sep 2005 16:40:54 -0400 Subject: Mock [Re: issues list(s)] In-Reply-To: <1127677707.2482.1.camel@localhost.localdomain> References: <506815A5-E52B-4AAE-8C95-6A97B8E4F6E2@cs.ucsb.edu> <1127677707.2482.1.camel@localhost.localdomain> Message-ID: On Sep 25, 2005, at 3:48 PM, Jesse Keating wrote: > On Sat, 2005-09-24 at 06:33 -0400, Jeff Sheltren wrote: > >> Yes, you'll want to have a local (either on your LAN or on the build >> machine itself) mirror of the repositories. I like the idea of >> perhaps having a mock build system available to a handful of people >> who create packages for Legacy - it could perhaps be setup much the >> same way as the Fedora Extras build system, with the difference >> being, once it is built it spits it back out for you to download/post >> instead of queuing it for signing, release, etc. See http:// >> fedoraproject.org/wiki/Projects/Plague to read more about their build >> system. >> > > I'm working on converting our existing Legacy build server into a > Plague/mock server. I have test hardware at my house that I am > using to > test it out before I deploy it over the system we currently use. > When I > get back from vacation (as I quickly look around to make sure my wife > doesn't catch me answering email....) I'll be putting more effort into > this. Jesse, I'm not sure if I mentioned to you before, but I'd be glad to help you with this if needed. Then, what I was implying was that there could be a way for package builders to submit jobs to the server (maybe a different one than the main build server - but I guess we'll need to see who all wants to use it) in order to build them in mock. This would be a different queue than used for real builds (which would go on to be pgp signed, and released), instead, it would make the SRPMs accessible to the builder so they could post them for QA. Anyway, just a thought - not sure how much demand there is for such a setup. -Jeff From jimpop at yahoo.com Sun Sep 25 20:59:21 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sun, 25 Sep 2005 16:59:21 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <20050925143826.C22683@mail.harddata.com> References: <4332AE6B.8030002@yahoo.com> <20050922095806.A3637@mail.harddata.com> <43356144.3080007@yahoo.com> <20050924121018.A29892@mail.harddata.com> <4335A5C3.3040502@yahoo.com> <20050924144254.A32335@mail.harddata.com> <4336F1CD.5080307@yahoo.com> <20050925143826.C22683@mail.harddata.com> Message-ID: <43370FA9.5050305@yahoo.com> Michal Jaegermann wrote: > On Sun, Sep 25, 2005 at 02:51:57PM -0400, Jim Popovitch wrote: > >>Michal, I am confused about all your comments on this thread. > > > You raised a possibility that PCRE bugs affect also various Python > packages. Quite timely alert, I would say, and from all what we > know by now you were right. After that we got some followups on > the topic and some which left me somewhat baffled. > > >>Now >>today I see that you already opened a bug back on 16-Sept >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 > > > Indeed I wrote that. But this is about bugs in 'pcre' package > itself. Fixing that does not seem to help 'python' > as that appears to re-cycle that code with security bugs directly > and not using 'pcre' as a library. Even if that would be used > as a statically linked library then all affected packages would > need to be at least recompiled (but most likely they need direct > patches). > > So the report you qoute is not sufficient as bugzilla entries > are for a package and not for a bug with a list of all possible > packages where this may apply. Therefore we need a corresponding > entry in bugzilla. If you cannot and/or do not want to do that > then say so and somebody else will have to write something up. > OK, I have opened 169235 as "python2.2 integer overflow" (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169235) Please, please double check what I did. As I've mentioned before I am not all that up to speed wrt Bugzilla best practices. Thank you Michal for your help/explainations so far. -Jim P. From sheltren at cs.ucsb.edu Sun Sep 25 21:19:40 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 25 Sep 2005 17:19:40 -0400 Subject: what about vsftpd - version 2.0.3 In-Reply-To: <43370B34.1050104@wp.pl> References: <43370B34.1050104@wp.pl> Message-ID: <7318CF9B-AD8D-4919-ADB0-73569598308F@cs.ucsb.edu> On Sep 25, 2005, at 4:40 PM, Jancio Wodnik wrote: > Hi all ! > > What is going on with vsftpd for legacy systems: FC2 ? there is > version 2.0.3 on their website. Anybody working with that to pull > vsftpd 2.0.3 for fedora legacy ? > > Regards, > > Jancio Wodnik Hi Jancio, we don't upgrade to the latest versions for legacy distributions, we only patch security issues. -Jeff From warren at togami.com Mon Sep 26 05:29:45 2005 From: warren at togami.com (Warren Togami) Date: Mon, 26 Sep 2005 01:29:45 -0400 Subject: Thoughts about James' Updates on Legacy list Message-ID: <43378749.9090705@togami.com> Please consider this as only a *suggestion*. The actual decision should be made by Legacy project leadership and general consensus. I think it is confusing and misleading for James to post his update announcements to Legacy list, even despite the huge explicit disclaimer. It is not a good precedent as it would be clearly bad to have all 3rd party packagers with their own repositories post package update notifications to Legacy list. At the very least this type of mail causes unnecessary noise, and adds to confusion and loss of focus of the Legacy package development and support purpose of this list. http://lists.atrpms.net/mailman/listinfo/repo-coord I think instead James' repository would be better suited as being part of an external individually maintained coalition of repositories like these guys. I think it is appropriate for James to occasionally mention the existence of his repository on Legacy list, as it is related to the same distributions used by Legacy list members. The posts would contain a general repo description and link to more information, and appear maybe a few times during the year. However it is off-topic for individual package announcements or even summaries to be posted here as they are version upgrades, outside the scope of Legacy's mandate. Another important part of Legacy is collaborative development of a centralized repository, which is not the goal of James' updates. Again this is just my personal opinion and I don't care so much about the outcome. Warren Togami wtogami at redhat.com From Axel.Thimm at ATrpms.net Mon Sep 26 07:17:36 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Sep 2005 09:17:36 +0200 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <43378749.9090705@togami.com> References: <43378749.9090705@togami.com> Message-ID: <20050926071736.GA23452@neu.nirvana> On Mon, Sep 26, 2005 at 01:29:45AM -0400, Warren Togami wrote: > Please consider this as only a *suggestion*. The actual decision should > be made by Legacy project leadership and general consensus. > > I think it is confusing and misleading for James to post his update > announcements to Legacy list, even despite the huge explicit disclaimer. > It is not a good precedent as it would be clearly bad to have all 3rd > party packagers with their own repositories post package update > notifications to Legacy list. At the very least this type of mail > causes unnecessary noise, and adds to confusion and loss of focus of the > Legacy package development and support purpose of this list. > > http://lists.atrpms.net/mailman/listinfo/repo-coord > I think instead James' repository would be better suited as being part > of an external individually maintained coalition of repositories like > these guys. That's a list for maintainers, not users. E.g. not something you would post announcements of new packages in. But of course James and anyone else doing packaging is welcome to join it, I believe all repos not hosted on redhat.com are on this list. FWIW I don't feel like James is spamming this list. His work is focused around EOL'd releases that have been picked up by Fedora Legacy. The user group he is targeting *is* on this list. -- 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 jkosin at beta.intcomgrp.com Mon Sep 26 13:07:39 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 26 Sep 2005 09:07:39 -0400 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <43378749.9090705@togami.com> References: <43378749.9090705@togami.com> Message-ID: <4337F29B.4060702@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Warren Togami wrote: | Please consider this as only a *suggestion*. The actual decision | should be made by Legacy project leadership and general consensus. | | I think it is confusing and misleading for James to post his update | announcements to Legacy list, even despite the huge explicit | disclaimer. It is not a good precedent as it would be clearly bad | to have all 3rd party packagers with their own repositories post | package update notifications to Legacy list. At the very least | this type of mail causes unnecessary noise, and adds to confusion | and loss of focus of the Legacy package development and support | purpose of this list. Ok, so what would be the purpose of the list? This list, I've found is very low volume and is more of a hodge-podge list than anything else. Sorry if I hurt anyone with this comment... I don't mean to. True, my posts don't really, exactly belong here; but, I do mean well and try to help people out with updates on a few packages. | | http://lists.atrpms.net/mailman/listinfo/repo-coord I think instead | James' repository would be better suited as being part of an | external individually maintained coalition of repositories like | these guys. I don't really fit in here either. I just maintain an FC1 server and have been stuck with this due to HW problems if I upgrade. So, I've been dabbling (if you don't mind the use of the word) in creating RPM's from the fedora core RPMs for FC1 and the updates online at the developers sites for the software, and rolling out new packages for FC1 that way. This way I can keep ahead with some of the software that I use regularly that doesn't get updated in Fedora Legacy. | | I think it is appropriate for James to occasionally mention the | existence of his repository on Legacy list, as it is related to the | same distributions used by Legacy list members. The posts would | contain a general repo description and link to more information, | and appear maybe a few times during the year. | | However it is off-topic for individual package announcements or | even summaries to be posted here as they are version upgrades, | outside the scope of Legacy's mandate. Another important part of | Legacy is collaborative development of a centralized repository, | which is not the goal of James' updates. Ok, point taken. I'd be willing to do this if no one objects. Or I could post a web-page (if I had the time) to post my complete announcements to and only post an occasional reminder to the list with the web-page address. This might make everyone happier, including me. | | Again this is just my personal opinion and I don't care so much | about the outcome. No, you should value your opinion and share it with others. If you don't say anything nothing usually changes, and no one would have FC 4 or FC 5 , etc. | | Warren Togami wtogami at redhat.com | | -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-legacy-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDN/KakNLDmnu1kSkRA6f9AJ4uAtCMW2l5XjUKrijH+H6ZZRdP/gCggwUe p9x8mIK25zFr0VvQ1Llbyjw= =Wb6A -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From deisenst at gtw.net Tue Sep 27 06:17:37 2005 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 27 Sep 2005 01:17:37 -0500 (CDT) Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: <43370FA9.5050305@yahoo.com> Message-ID: On Sun, 25 Sep 2005, Jim Popovitch wrote: > > OK, I have opened 169235 as "python2.2 integer overflow" > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169235) > > Please, please double check what I did. As I've mentioned before I am > not all that up to speed wrt Bugzilla best practices. The bug opening looks good to me, Jim. But then again, you quoted me extensively. ;-) I would suggest that you add "LEGACY, 1, 2, rh73, rh90, NEEDSWORK" (without the quotes around them) to the Status Whiteboard slot under "Additional Bug Information," down towards the bottom of the bug report. I think that pressing -W will take you right to that slot once the bug report is loaded in your browser. And sending you another suggestion in Bug #152897 (another open Python bug). Thanks for opening the bug, Jim. -David From jimpop at yahoo.com Tue Sep 27 15:12:11 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 27 Sep 2005 11:12:11 -0400 Subject: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution] In-Reply-To: References: Message-ID: <4339614B.5080501@yahoo.com> David Eisenstein wrote: > I would suggest that you add "LEGACY, 1, 2, rh73, rh90, NEEDSWORK" > (without the quotes around them) to the Status Whiteboard slot under > "Additional Bug Information," down towards the bottom of the bug report. > I think that pressing -W will take you right to that slot once the > bug report is loaded in your browser. Thanks for the input, I have added those identifiers. > > And sending you another suggestion in Bug #152897 (another open Python > bug). I updated 169235 as you suggested in 152897. Thank you for adding me to the CC list for that bug. -Jim P. From jkosin at beta.intcomgrp.com Tue Sep 27 15:52:00 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 27 Sep 2005 11:52:00 -0400 Subject: Web-Page for James' Updates. Message-ID: <43396AA0.1080407@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Ok, This may be easier than writing a long detailed email all the time. Everyone can get / see updates via my newly created web-page at ~ http://support.intcomgrp.com/~jkosin For now; I'm open to comments on how to modify or make the page better. I've never been very good at creating fancy pages. I usually like to keep the pages simple. Also, the page doesn't have a complete list yet! So, don't start off saying that I know you've built more than what is listed. I already know that fact. Thanks James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOWqgkNLDmnu1kSkRA/N2AJ40uh/OkQCmzy5fq85HnVh3XhloaACff2aO 5lxhepKexAJ92H9be0bYKLs= =V0at -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From lists at benjamindsmith.com Tue Sep 27 17:36:46 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Tue, 27 Sep 2005 10:36:46 -0700 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <4334357B.3050701@compusmart.ab.ca> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> Message-ID: <200509271036.46856.lists@benjamindsmith.com> On Friday 23 September 2005 10:03, William Stockall wrote: > I concur with Mr. McCarty. If untested updates are moved in with the > tested updates then NONE of the updates can be trusted. Who wants to go > back to the bug entry to check for sure if an update actually got tested > prior to rolling it out? So don't release them to the same place... What if a repo is set up just for these timed out packages, and if somebody wants to use them, they can set their yum.conf to include this "semi-trusted" repository? If the package is given a name like bison-1.28-7.FEDORA-LEGACY-TIMEDOUT Then it would be easy to see what you have installed that you might consider checking out by piping the output from "rpm -qa" thru grep. I think this answers both sides of the equation, the underlying question seems to be "Does the risk of not publishing security updates exceed the risk of installing untested packages?" Would this add much to the administrative overhead for these packages? -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From michal at harddata.com Tue Sep 27 18:11:17 2005 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 27 Sep 2005 12:11:17 -0600 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <200509271036.46856.lists@benjamindsmith.com>; from lists@benjamindsmith.com on Tue, Sep 27, 2005 at 10:36:46AM -0700 References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <200509271036.46856.lists@benjamindsmith.com> Message-ID: <20050927121117.A11211@mail.harddata.com> On Tue, Sep 27, 2005 at 10:36:46AM -0700, Benjamin Smith wrote: > On Friday 23 September 2005 10:03, William Stockall wrote: > > I concur with Mr. McCarty. If untested updates are moved in with the > > tested updates then NONE of the updates can be trusted. ... > > What if a repo is set up just for these timed out packages, and if somebody > wants to use them, they can set their yum.conf to include this "semi-trusted" > repository? It seems to me that this is a terrible idea. Things are already quite fragmented in the context and that would create even further fragmentation and administrative headaches which someone would have to suffer. Besides I do not get it. There is a clamour for tested and verified packages but who is supposed to do that? Waiting for others does not help. If I am putting in a bug report a note that it is easy to recompile a package from updates to some other distribution, or give a reference to what I believe is a fixed package which I put together myself, then you can be sure that it works for me and is in an actual use. Beyond that I cannot tell very much on my own. Personally I think that if a "release early, release often" principle would be applied to Legacy releases too, with a quick re-release to follow for an occasional dud (which happened anyway), we would be much further in the whole project. This seems to be a minority opinion. As things are people are instead running for months with known security holes. Sure, if such box is heavily firewalled, and you are not ever using on it things like a web browser, then you may not care but this is not always the case. Oh, well ... I will probably get out of "7.3 business" pretty soon anyway. Michal From pekkas at netcore.fi Tue Sep 27 18:16:18 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Sep 2005 21:16:18 +0300 (EEST) Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <20050927121117.A11211@mail.harddata.com> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <200509271036.46856.lists@benjamindsmith.com> <20050927121117.A11211@mail.harddata.com> Message-ID: On Tue, 27 Sep 2005, Michal Jaegermann wrote: > Personally I think that if a "release early, release often" > principle would be applied to Legacy releases too, with a quick > re-release to follow for an occasional dud (which happened anyway), > we would be much further in the whole project. This seems to be a > minority opinion. I totally agree with you here, especially when we're basically using the RHEL updates (which have already been subject to QA). Things would be a bit different for packages where we create the patches ourselves (or in a very non-straightforward manner), but I haven't seen many of those around.. -- 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 mike.mccarty at sbcglobal.net Tue Sep 27 20:59:27 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Tue, 27 Sep 2005 15:59:27 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <200509271036.46856.lists@benjamindsmith.com> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <200509271036.46856.lists@benjamindsmith.com> Message-ID: <4339B2AF.3030705@sbcglobal.net> Benjamin Smith wrote: > On Friday 23 September 2005 10:03, William Stockall wrote: > >>I concur with Mr. McCarty. If untested updates are moved in with the >>tested updates then NONE of the updates can be trusted. Who wants to go >>back to the bug entry to check for sure if an update actually got tested >>prior to rolling it out? > > > So don't release them to the same place... > > What if a repo is set up just for these timed out packages, and if somebody > wants to use them, they can set their yum.conf to include this "semi-trusted" > repository? > > If the package is given a name like > bison-1.28-7.FEDORA-LEGACY-TIMEDOUT This would be acceptable to me, at least. My main issue is that people always get only what they want, and can know that for a fact. If I point to a repository and do a yum update, and then see the list of things that would be done, I don't want to wonder how much, if any, has actually been through QA. If the non-released stuff is put into a number of categories, then that's not a problem, so long as one can set ones options to pull from those areas or not, as one wishes. > Then it would be easy to see what you have installed that you might consider > checking out by piping the output from "rpm -qa" thru grep. > > I think this answers both sides of the equation, the underlying question seems > to be "Does the risk of not publishing security updates exceed the risk of > installing untested packages?" And gives the end-user the power to make that decision, rather than the developers. Which is what I'm interested in. I want to control what is on my machine, without a lot of labor. > Would this add much to the administrative overhead for these packages? Dunno, but it looks ok to me. If the developers don't mind the extra work (and I'm sure it is some extra work), then that's fine. One little reservation I have: This must be carefully documented. The end-user must be made aware of exactly what is in each of the repositories and how it got there, and what the percieved pros and cons are for pulling from each piece of the repository. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From shiva at sewingwitch.com Tue Sep 27 21:07:05 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 27 Sep 2005 14:07:05 -0700 Subject: Web-Page for James' Updates. In-Reply-To: <43396AA0.1080407@beta.intcomgrp.com> References: <43396AA0.1080407@beta.intcomgrp.com> Message-ID: <782B6B96723AF989DFF08A94@[10.169.6.233]> --On Tuesday, September 27, 2005 11:52 AM -0400 James Kosin wrote: > For now; I'm open to comments on how to modify or make the page > better. I've never been very good at creating fancy pages. I usually > like to keep the pages simple. You might use a change detection service like this one: This is like the old Netminder server that emails interested visitors when a page of interest changes. From warren at togami.com Wed Sep 28 04:39:34 2005 From: warren at togami.com (Warren Togami) Date: Wed, 28 Sep 2005 00:39:34 -0400 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <4337F29B.4060702@beta.intcomgrp.com> References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> Message-ID: <433A1E86.3010809@togami.com> James Kosin wrote: > | > | http://lists.atrpms.net/mailman/listinfo/repo-coord I think instead > | James' repository would be better suited as being part of an > | external individually maintained coalition of repositories like > | these guys. > > I don't really fit in here either. I just maintain an FC1 server and > have been stuck with this due to HW problems if I upgrade. So, I've > been dabbling (if you don't mind the use of the word) in creating > RPM's from the fedora core RPMs for FC1 and the updates online at the > developers sites for the software, and rolling out new packages for > FC1 that way. This way I can keep ahead with some of the software > that I use regularly that doesn't get updated in Fedora Legacy. > One possible danger here is if you no longer maintain this FC1 server at some point in the future, people previously relying on your updates suddenly no longer have a supported source of updates. Then those users are faced with the choice of upgrading distros, downgrading to Legacy supported packages, or beginning to make their own packages. > | > | I think it is appropriate for James to occasionally mention the > | existence of his repository on Legacy list, as it is related to the > | same distributions used by Legacy list members. The posts would > | contain a general repo description and link to more information, > | and appear maybe a few times during the year. > | > | However it is off-topic for individual package announcements or > | even summaries to be posted here as they are version upgrades, > | outside the scope of Legacy's mandate. Another important part of > | Legacy is collaborative development of a centralized repository, > | which is not the goal of James' updates. > > Ok, point taken. I'd be willing to do this if no one objects. Or I > could post a web-page (if I had the time) to post my complete > announcements to and only post an occasional reminder to the list with > the web-page address. > This might make everyone happier, including me. You might also want to create your own mailing list for interested users, and that can be part of your periodic mention on this list about your repository. Warren Togami wtogami at redhat.com From rdieter at math.unl.edu Wed Sep 28 14:42:08 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Sep 2005 09:42:08 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <20050927121117.A11211@mail.harddata.com> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <200509271036.46856.lists@benjamindsmith.com> <20050927121117.A11211@mail.harddata.com> Message-ID: <433AABC0.3010902@math.unl.edu> Michal Jaegermann wrote: > Personally I think that if a "release early, release often" > principle would be applied to Legacy releases too, with a quick > re-release to follow for an occasional dud (which happened anyway), > we would be much further in the whole project. Hear, hear. Amen brother. If it's not clear, I comletely agree with Michal. An occasional possible broken release is better than no release at all. And please no separate repo for timed-out packages. That's even worse. -- Rex From jkosin at beta.intcomgrp.com Wed Sep 28 15:21:41 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 28 Sep 2005 11:21:41 -0400 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <433A1E86.3010809@togami.com> References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> <433A1E86.3010809@togami.com> Message-ID: <433AB505.7080600@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Warren Togami wrote: | James Kosin wrote: | |> | |> | http://lists.atrpms.net/mailman/listinfo/repo-coord I think instead |> | James' repository would be better suited as being part of an |> | external individually maintained coalition of repositories like |> | these guys. |> |> I don't really fit in here either. I just maintain an FC1 server and |> have been stuck with this due to HW problems if I upgrade. So, I've |> been dabbling (if you don't mind the use of the word) in creating |> RPM's from the fedora core RPMs for FC1 and the updates online at the |> developers sites for the software, and rolling out new packages for |> FC1 that way. This way I can keep ahead with some of the software |> that I use regularly that doesn't get updated in Fedora Legacy. |> | | One possible danger here is if you no longer maintain this FC1 | server at some point in the future, people previously relying on | your updates suddenly no longer have a supported source of updates. | Then those users are faced with the choice of upgrading distros, | downgrading to Legacy supported packages, or beginning to make their | own packages. Actually, I thought I was alone in using FC1... and will probably do so long past may have moved on. Like I said earlier, unless a catastrophic event blows up our development server... I will keep it at FC1 as long as humanly possible. I also don't provide a large scope of updates. Except for the vanilla kernel and the gcc update to 3.3.6 that I have. Most of the others are easily repackaged. I actually learned the gcc package was more complicated than the kernel package, but, I stuck with it. | |> | |> | I think it is appropriate for James to occasionally mention the |> | existence of his repository on Legacy list, as it is related to the |> | same distributions used by Legacy list members. The posts would |> | contain a general repo description and link to more information, |> | and appear maybe a few times during the year. |> | |> | However it is off-topic for individual package announcements or |> | even summaries to be posted here as they are version upgrades, |> | outside the scope of Legacy's mandate. Another important part of |> | Legacy is collaborative development of a centralized repository, |> | which is not the goal of James' updates. |> |> Ok, point taken. I'd be willing to do this if no one objects. Or I |> could post a web-page (if I had the time) to post my complete |> announcements to and only post an occasional reminder to the list with |> the web-page address. |> This might make everyone happier, including me. | | | You might also want to create your own mailing list for interested | users, and that can be part of your periodic mention on this list | about your repository. I'll think on this. It is a good suggestion; but, I still would like to see Fedora-Legacy embrace my packages one day. Except for maybe the kernel packages, since they are further from the RedHat / Fedora norm. I post here; because I want everyone to benefit from these updates. Not because I want to confuse the issue. RedHat, Fedora and Fedora Legacy have a two fold operation on updates: (1) If it is not broke, don't update it. (sometimes a good idea; but, what about new features or more supported features) (2) Only patch security fixes or CAN / CSV security updates. (sometimes an important bug doesn't get fixed unless addressed by a CAN). This makes the procedure of verifying packages easier. Less broken things, because you only fix what is broken and don't add new features that may break or introduce new problems. I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good point. But, some of us need more than just patches to get us by. I know, If you really want the latest, why not update to FC4... The problem there is that this is a server. I shouldn't have to strip the system down and rebuild it every 6-months or so. I also don't have the money or budget to spend lots of money on RedHat ES. Also, my time is money $$$. I can't spend 2-days to a week debugging and setting up the server again.... and again... and again... DAG, ATrpms and others are OK. But, I find they often have dependencies on libraries not in the FC1 build or they only have optimized builds for i686 that either crash my system or have problems of their own. But, they also have their place in the scheme of things. I'm also not knocking these repos... They do a far better job than I could at keeping things updated. They usually take things to the cutting edge. I just don't want to be their either... I just want something in the middle. | | Warren Togami | wtogami at redhat.com Thanks, James Kosin | | -- | fedora-legacy-list mailing list | fedora-legacy-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-legacy-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOrUFkNLDmnu1kSkRAyMiAJ9djVRgVmhONF1GgkCZZ79ONp2NeACeLjyF ZEZweZP9p/0nRfxlBR+6bFA= =sJIC -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From rostetter at mail.utexas.edu Wed Sep 28 15:43:08 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Sep 2005 10:43:08 -0500 Subject: Fwd: Re: releasing updates-testing packages without VERIFY votes In-Reply-To: <433AABC0.3010902@math.unl.edu> References: <1127492985.556df2210fc83@mail.ph.utexas.edu> <433430EF.3050305@sbcglobal.net> <4334357B.3050701@compusmart.ab.ca> <200509271036.46856.lists@benjamindsmith.com> <20050927121117.A11211@mail.harddata.com> <433AABC0.3010902@math.unl.edu> Message-ID: <1127922188.b0705fe272de4@mail.ph.utexas.edu> Quoting Rex Dieter : > Michal Jaegermann wrote: > > > Personally I think that if a "release early, release often" > > principle would be applied to Legacy releases too, with a quick > > re-release to follow for an occasional dud (which happened anyway), > > we would be much further in the whole project. > > Hear, hear. Amen brother. If it's not clear, I comletely agree with > Michal. An occasional possible broken release is better than no release > at all. While I generally disagree with the above, there are times when it would benefit us. We've had serveral kernel updates delayed because additional bugs are found before we release a version that is in QA. I disagree with this. Release them once they get QA, then fix the additional bugs and release again. We have a nfs-config package held up for a similar reason. It was in QA with the upstream patch, and it fixes the problem as well as any other patch. But a rare case was found where it doesn't fix the problem. Well, why not release it like every other vendor did (maybe even document the new case it doesn't address). Then go back and fix the new bug, and release again. I hate seeing a perfectly good patch go through QA and then be put on hold or held back while we try to patch additional bugs. Release a version for each bug if we need to, so that people are protected from each bug as soon as possible. But this is not the issue at hand. We need to do QA, no two ways about it. But let's not drop good QA because of new/additional bugs in the same package. -- Eric Rostetter From shiva at sewingwitch.com Wed Sep 28 23:41:18 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 28 Sep 2005 16:41:18 -0700 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <433AB505.7080600@beta.intcomgrp.com> References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> Message-ID: --On Wednesday, September 28, 2005 11:21 AM -0400 James Kosin wrote: > I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good > point. But, some of us need more than just patches to get us by. > I know, If you really want the latest, why not update to FC4... The > problem there is that this is a server. I shouldn't have to strip the > system down and rebuild it every 6-months or so. I also don't have > the money or budget to spend lots of money on RedHat ES. I don't think ES would solve that issue anyway. ES would have the same policy as legacy, providing only security updates. It's just got more manpower to do so. You still wouldn't get new features. For that you need an OS upgrade. Those of us who want to upgrade incrementally without doing the whole platform are pretty much on our own. (I'm in a similar situation with FC2.) From tdiehl at rogueind.com Thu Sep 29 00:31:19 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 28 Sep 2005 20:31:19 -0400 (EDT) Subject: Thoughts about James' Updates on Legacy list In-Reply-To: References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> Message-ID: On Wed, 28 Sep 2005, Kenneth Porter wrote: > --On Wednesday, September 28, 2005 11:21 AM -0400 James Kosin > wrote: > > > I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good > > point. But, some of us need more than just patches to get us by. > > I know, If you really want the latest, why not update to FC4... The > > problem there is that this is a server. I shouldn't have to strip the > > system down and rebuild it every 6-months or so. I also don't have > > the money or budget to spend lots of money on RedHat ES. Maybe centos, whitebox or one of the other rebuild distros would help. > I don't think ES would solve that issue anyway. ES would have the same > policy as legacy, providing only security updates. It's just got more > manpower to do so. You still wouldn't get new features. For that you need > an OS upgrade. I do not know where you got the impression that RHEL only gets security updates but that is not true. What is true is that whatever version of a particular package a given version of RHEL is released with is the version it will have throughout its lifetime. Once a version is over 5 years old [1] then it goes into maintenance mode and will only get security updates. Before that it gets quarterly updates. Granted you will not get the latest and greatest versions once it is released but a lot of packages have various enhancments backported into them during the quarterly updates. IMO, it really depends on what the actual problem you are trying to solve is. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com [1] I think it is 5 years but it might be 7 years. I am too lazy to actually look it up right now but I think you get the point. :-) From tgc at statsbiblioteket.dk Thu Sep 29 06:59:24 2005 From: tgc at statsbiblioteket.dk (Tom G. Christensen) Date: Thu, 29 Sep 2005 08:59:24 +0200 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> Message-ID: <433B90CC.3050603@statsbiblioteket.dk> Tom Diehl wrote: > I do not know where you got the impression that RHEL only gets security updates > but that is not true. What is true is that whatever version of a particular > package a given version of RHEL is released with is the version it will have > throughout its lifetime. Once a version is over 5 years old [1] then it goes > into maintenance mode and will only get security updates. Before that it > gets quarterly updates. Granted you will not get the latest and greatest > versions once it is released but a lot of packages have various enhancments > backported into them during the quarterly updates. > > [1] I think it is 5 years but it might be 7 years. I am too lazy to actually > look it up right now but I think you get the point. :-) > For reference the full story is here: http://www.redhat.com/security/updates/errata/ -tgc From guallar at easternrad.com Thu Sep 29 11:32:19 2005 From: guallar at easternrad.com (Josep L. Guallar-Esteve) Date: Thu, 29 Sep 2005 07:32:19 -0400 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <433AB505.7080600@beta.intcomgrp.com> References: <43378749.9090705@togami.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> Message-ID: <200509290732.21792.guallar@easternrad.com> On Wednesday 28 September 2005 11:21, James Kosin wrote: > I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good > point. ?But, some of us need more than just patches to get us by. > I know, If you really want the latest, why not update to FC4... ?The > problem there is that this is a server. ?I shouldn't have to strip the > system down and rebuild it every 6-months or so. ? Exactly. This is why Fedora Core is not recomended for production server usage. For home server, sure, works good like anty other distributution. But for enterprise-grade server... no way. > I also don't have > the money or budget to spend lots of money on RedHat ES. Then I strongly recommed you to try out CentOS. CentOS is the "free as in beer" version of RHEL. CentOS is the result of recompiling the freely available sourfes of RHEL. There are others (WhiteBox...) that do the same. In my experience, the distribution with more community following and dedication is CentOS. No, I do not work for CentOS. I use some CentOS side-by-side with RHEL. And I find CentOS to be as good as RHEL. After all, CentOS is binary-compatible with RHEL. Even Oracle installs fine on CentOS. > Also, my time is money $$$. ?I can't spend 2-days to a week debugging > and setting up the server again.... and again... and again... Then go for CentOS. Cheers, Josep -- Josep L. Guallar-Esteve - IT Department - 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 shiva at sewingwitch.com Thu Sep 29 18:35:42 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 29 Sep 2005 11:35:42 -0700 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: References: <43378749.9090705@togami.com> <4337F29B.4060702@beta.intcomgrp.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> Message-ID: <0CE32808E7AE91010F964E61@[10.170.7.6]> --On Wednesday, September 28, 2005 8:31 PM -0400 Tom Diehl wrote: > I do not know where you got the impression that RHEL only gets security > updates but that is not true. What is true is that whatever version of a > particular package a given version of RHEL is released with is the > version it will have throughout its lifetime. Once a version is over 5 > years old [1] then it goes into maintenance mode and will only get > security updates. Before that it gets quarterly updates. Granted you will > not get the latest and greatest versions once it is released but a lot of > packages have various enhancments backported into them during the > quarterly updates. Ok, thanks for the clarification. From mike.mccarty at sbcglobal.net Thu Sep 29 19:34:07 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Thu, 29 Sep 2005 14:34:07 -0500 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <200509290732.21792.guallar@easternrad.com> References: <43378749.9090705@togami.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> <200509290732.21792.guallar@easternrad.com> Message-ID: <433C41AF.7020201@sbcglobal.net> Josep L. Guallar-Esteve wrote: > On Wednesday 28 September 2005 11:21, James Kosin wrote: > >>I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good >>point. But, some of us need more than just patches to get us by. >>I know, If you really want the latest, why not update to FC4... The >>problem there is that this is a server. I shouldn't have to strip the >>system down and rebuild it every 6-months or so. > > > Exactly. This is why Fedora Core is not recomended for production server > usage. For home server, sure, works good like anty other distributution. But > for enterprise-grade server... no way. > > >>I also don't have >>the money or budget to spend lots of money on RedHat ES. > > > Then I strongly recommed you to try out CentOS. CentOS is the "free as in > beer" version of RHEL. CentOS is the result of recompiling the freely > available sourfes of RHEL. So do I. See centos at centos.org via http://lists.centos.org/mailman/listinfo/centos There's also an announce I subscribe to. I'm probably going to hop from FC2 to CentOS one day. Lots of really good folk over there. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From mic at npgx.com.au Thu Sep 29 20:02:20 2005 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 30 Sep 2005 06:02:20 +1000 Subject: Thoughts about James' Updates on Legacy list In-Reply-To: <433C41AF.7020201@sbcglobal.net> References: <43378749.9090705@togami.com> <433A1E86.3010809@togami.com> <433AB505.7080600@beta.intcomgrp.com> <200509290732.21792.guallar@easternrad.com> <433C41AF.7020201@sbcglobal.net> Message-ID: <20050929195940.M66968@npgx.com.au> > Josep L. Guallar-Esteve wrote: > > On Wednesday 28 September 2005 11:21, James Kosin wrote: > > > >>I'm not knocking RedHat, Fedora or Fedora-Legacy this is a good > >>point. But, some of us need more than just patches to get us by. > >>I know, If you really want the latest, why not update to FC4... The > >>problem there is that this is a server. I shouldn't have to strip the > >>system down and rebuild it every 6-months or so. > > > > > > Exactly. This is why Fedora Core is not recomended for production server > > usage. For home server, sure, works good like anty other distributution. But > > for enterprise-grade server... no way. > > > > > >>I also don't have > >>the money or budget to spend lots of money on RedHat ES. > > > > > > Then I strongly recommed you to try out CentOS. CentOS is the "free as in > > beer" version of RHEL. CentOS is the result of recompiling the freely > > available sourfes of RHEL. > > So do I. See centos at centos.org via > http://lists.centos.org/mailman/listinfo/centos > > There's also an announce I subscribe to. I'm probably going to hop > from FC2 to CentOS one day. > > Lots of really good folk over there. I can't agree more. Personally I made the jump to Scientific Linux (http://www.scientificlinux.org) which is just another recompiled release of RHEL. It's just much easier to have someone else manage package updates and security fixes for you, and give you back the time to get on with life :) Michael. From deisenst at gtw.net Fri Sep 30 05:14:24 2005 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 30 Sep 2005 00:14:24 -0500 (CDT) Subject: Web-Page for James' Updates. In-Reply-To: <43396AA0.1080407@beta.intcomgrp.com> Message-ID: On Tue, 27 Sep 2005, James Kosin wrote: > This may be easier than writing a long detailed email all the time. > Everyone can get / see updates via my newly created web-page at > ~ http://support.intcomgrp.com/~jkosin Hi James, I've looked at your page and like the page. I guess I am one of the few on this list who uses Fedora Core 1, but I like the idea that you're out there publishing some updated (of course, unguaranteed, but updated) packages that I can use on my FC1 install. I run FC1 because I like it, and because it's a pain to upgrade to a newer version every six months, especially with a 56kbps Internet connection. I think you've hit upon an optimal solution: much shorter mail announce- ments with pointers to your web-page. Your long announcements confused me. I would also encourage you, James, to consider also contributing some of your time to the business of the Fedora Legacy project, by occasionally diving into one of the Bugzilla bugs listed in our "to do" list and either creating new packages or QA'ing exising ones. If you need any help with that, let me know. > For now; I'm open to comments on how to modify or make the page > better. I've never been very good at creating fancy pages. I usually > like to keep the pages simple. Me too. If it's readable and usable and works, I say, "Don't fix it." Looks good to me. -David From deisenst at gtw.net Fri Sep 30 06:38:51 2005 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 30 Sep 2005 01:38:51 -0500 (CDT) Subject: Triaging/Security Classification & redhat-config-nfs; was Re: Fwd: Re: releasing updates-testing packages without VERIFY... In-Reply-To: <1127922188.b0705fe272de4@mail.ph.utexas.edu> Message-ID: On Wed, 28 Sep 2005, Eric Rostetter wrote: > > We have a nfs-config package held up for a similar reason. It was in QA with > the upstream patch, and it fixes the problem as well as any other patch. > But a rare case was found where it doesn't fix the problem. Well, why not > release it like every other vendor did (maybe even document the new case > it doesn't address). Then go back and fix the new bug, and release again. There are right now redhat-config-nfs packages (Bug #152787) that, to be published then released, need source-level ("publish") QA. I've done publish QA for the FC1 package. Eric, how about you do the RH9 publish QA and I'll do the FC2 QA so this puppy can move forward and be put to bed? > I hate seeing a perfectly good patch go through QA and then be put on hold > or held back while we try to patch additional bugs. Release a version for > each bug if we need to, so that people are protected from each bug as soon > as possible. I would rather agree, IF it were feasible. Our QA process seems to be rather slow sometimes. While time is elapsing waiting for people to do QA, new issues do arise, especially for things like kernels or web browsers. Because we seem to be so low on man-hours lately to even get the first QA step done in many instances, asking to release a new package version for each bug may unduly tie up a lot of those man hours building new packages for release to updates and writing release notes for each of those releases. But you know what? I think we have an even bigger problem. We don't have effective bug triaging in place. We need effective bug triaging in order to make clear decisions as to what really matters to be worked on quickly, and what can be put off. Good triaging and bug classification will help inform our decisions as to whether or not we've fixed enough bugs in a given package in Bugzilla, so we can complete the QA and release it ("have we covered all the critical CVEs?"). Other moderate- or low-impact bugs that have shown up in the meantime we can choose to relegate to a new Bugzilla ticket on that package. Another problem is ownership. Since so much is done by committee and consensus (not that I am knocking consensus), many times bugs just languish in Bugzilla because no one steps forward with a tack to take, or saying, "Let's get moving on this." Maybe we need to review how bugs are assigned and start assigning them to individuals ("bug chairs"?) who then own those bugs and who will take personal responsibility for seeing them through to completion (including taking time to advocate their bug(s) here on the list)? Bugs that are assigned to seem to have no owner at all, which means no one in particular has incentive to see those bugs through. Returning to the subject of triaging -- I have found the RedHat Security Response Team's webpage "Classification of Security Issues" an excellent read, at . IMHO, it would be helpful to classify each and every bug currently in the queue according to some system like this, so we can all be made aware of what bugs matter most to be fixed most quickly. As long as we *know* the severity of the CVE issues for a given software package "in the shop" at Bugzilla, we could then more clearly assess whether or not to hold up releasing it. Or whether or not to release without full VERIFY (or *any* verify). At this time, AFAIK, we have at least one bug out there that RH Security has classified as Critical Impact (Mozilla). There may be others. -David ps: It is interesting to note that, although our redhat-config-nfs bug (#152787) has packages to QA, they haven't been looked at since July, except for the lone FC1 Publish vote I gave the other day. Even more interesting -- although we offered John Dalbec's patch to Red Hat in their comparable bug report to better fix their reopened redhat-config-nfs bug (#107997, for RHEL 3), they have not jumped on it.