From notting at redhat.com Thu Jan 1 03:16:52 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 31 Dec 2003 22:16:52 -0500 Subject: RPM upgrade discussion In-Reply-To: <3FF2A661.5070408@togami.com> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> Message-ID: <20040101031652.GA7416@devserv.devel.redhat.com> Warren Togami (warren at togami.com) said: > >The new (4.2.1) behavior is more predictable, but it breaks backward > >compatibility with old packages that have broken requirements > >specifications (i.e., missing specific epochs when they're needed). If > >we want to move Red Hat 8.0 and 9 over to the new behavior, we could > >make new mozilla, etc. packages that work properly with RPM 4.2.1, > >however. > > Updates for Mozilla will most likely be needed one day, because of the > very large complexity of a behemoth like Mozilla we will surely have a > security update in the future. I think. Yes, but pushing a new RPM with this will cause problems for people installing original packages in the meantime. Bill From warren at togami.com Thu Jan 1 03:19:34 2004 From: warren at togami.com (Warren Togami) Date: Wed, 31 Dec 2003 17:19:34 -1000 Subject: RPM upgrade discussion In-Reply-To: <20040101031652.GA7416@devserv.devel.redhat.com> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> Message-ID: <3FF391C6.8040901@togami.com> Bill Nottingham wrote: > Warren Togami (warren at togami.com) said: > >>>The new (4.2.1) behavior is more predictable, but it breaks backward >>>compatibility with old packages that have broken requirements >>>specifications (i.e., missing specific epochs when they're needed). If >>>we want to move Red Hat 8.0 and 9 over to the new behavior, we could >>>make new mozilla, etc. packages that work properly with RPM 4.2.1, >>>however. >> >>Updates for Mozilla will most likely be needed one day, because of the >>very large complexity of a behemoth like Mozilla we will surely have a >>security update in the future. I think. > > > Yes, but pushing a new RPM with this will cause problems for > people installing original packages in the meantime. > > Bill Only if we enable the rpm-4.2.1 epoch behavior. The other fixes don't cause this regression in behavior. Warren From blists at nobaloney.net Thu Jan 1 03:42:33 2004 From: blists at nobaloney.net (Jeff Lasman) Date: Wed, 31 Dec 2003 19:42:33 -0800 Subject: It's January 1st... Message-ID: <200312311942.33852.blists@nobaloney.net> It's already January 1st in most of the world. And it soon will be everywhere else. Is there anything working we can point 7.3 systems to? With or without RPM or up2date (I use apt-get). Or in other words, it's time to stop arguing about what we'd like to have, and live with what we do have. Or buy the commercial service from Progeny. Jeff -- Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US Professional Internet Services & Support / Consulting / Colocation Our blists address used on lists is for list email only Phone +1 909 324-9706, or see: "http://www.nobaloney.net/contactus.html" From warren at togami.com Thu Jan 1 11:31:59 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 01:31:59 -1000 Subject: Preparing 7.2 and 7.3 now... Message-ID: <3FF4052F.4070608@togami.com> I am currently populating the 7.2 and 7.3 fedora.us repositories. I am only putting the binary RPMS and not SRPMS from Red Hat into these repositories in order to save on space and reduce the burden on fedora.us mirrors. If you really need the SRPMS from Red Hat, get them from any of the thousand existing mirrors. http://www.fedora.us/wiki/FedoraChannels As I have wrote here, RH 7.2 and 7.3 at fedora.us will have the following channels: os Base Distribution updates RH updates + Legacy updates updates-testing Legacy updates undergoing regression testing stable Very limited number of add-on packages Fedora Legacy users should use minimally os, updates, and stable channels. If you want to participate in testing of candidate updates, then also subscribe to updates-testing channel. stable channel will contain mainly support utilities from fedora.us and Legacy like apt, yum, and fedora-rpmdevtools. We can also consider adding other safe and simple server support tools only by consensus. I would suggest these packages that are already in fedora.us stable for inclusion: bonnie++ Very useful stability test for servers chkrootkit Security checking for servers ddrescue Data recovery for servers hardlink Space consolidation for mirror servers iptstate Very simple Netfilter stateful top [1] Any other suggestions for simple server support tools? I would suggest against expanding the scope beyond this for Legacy's support of these older distributions. After I am done copying packages into the repository, there is only one thing blocking the launch of Legacy for RH7.2 and RH7.3: We need maintainers for apt and/or yum clients for these older distributions. You must submit your packages to fedora.us QA just like any other package currently in the QA queue. Use keywords like "rh72, QA, stable". It seems that we agreed to NOT upgrade RPM for RH7.x, so apt and yum-1.x are what we will be using. Panu & Seth can we ask for your help here, or do you want others to do it? Let me know if you need ssh access to 7.2 or 7.3 boxes to test your clients. Damn I need to install that old distro... Warren Togami warren at togami.com [1] iptstate may be improper to add if testing shows a certain memory leak during extended operation. Debian refused to add iptstate for a long time because an older version of curses leaked memory. They never did figure out what was causing it, but suddenly that problem just went away with a newer version of curses and they accepted iptstate. I have NEVER SEEN THIS PROBLEM on any Red Hat Linux, but we should test the older curses just to be safe. From warren at togami.com Thu Jan 1 11:51:25 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 01:51:25 -1000 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF4052F.4070608@togami.com> References: <3FF4052F.4070608@togami.com> Message-ID: <3FF409BD.3040406@togami.com> Warren Togami wrote: > os Base Distribution > updates RH updates + Legacy updates > updates-testing Legacy updates undergoing regression testing > stable Very limited number of add-on packages > > Fedora Legacy users should use minimally os, updates, and stable > channels. If you want to participate in testing of candidate updates, > then also subscribe to updates-testing channel. > > stable channel will contain mainly support utilities from fedora.us and > Legacy like apt, yum, and fedora-rpmdevtools. We can also consider > adding other safe and simple server support tools only by consensus. I > would suggest these packages that are already in fedora.us stable for > inclusion: > > bonnie++ Very useful stability test for servers > chkrootkit Security checking for servers > ddrescue Data recovery for servers > hardlink Space consolidation for mirror servers > iptstate Very simple Netfilter stateful top [1] > > Any other suggestions for simple server support tools? > I would suggest against expanding the scope beyond this for Legacy's > support of these older distributions. I just realized one problem with this scheme. While "stable" works this way for RH7.2 and RH7.3 at fedora.us, we cannot have "stable" as mandatory for Legacy users on RH8, RH9 and FC1 because those repositories already contain many more packages beyond the stated scope of Legacy. For this and the reason of consistency, I am renaming Legacy's "stable" to "legacy". The "legacy" channel serves the exact same purpose across all distributions. Warren From sven at timegate.de Thu Jan 1 12:17:23 2004 From: sven at timegate.de (Sven Hoexter) Date: Thu, 1 Jan 2004 13:17:23 +0100 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF4052F.4070608@togami.com> References: <3FF4052F.4070608@togami.com> Message-ID: <20040101121723.GA2122@sven.home.hoaxter.de> On Thu, Jan 01, 2004 at 01:31:59AM -1000, Warren Togami wrote: Hi, > After I am done copying packages into the repository, there is only one > thing blocking the launch of Legacy for RH7.2 and RH7.3: We need > maintainers for apt and/or yum clients for these older distributions. > You must submit your packages to fedora.us QA just like any other > package currently in the QA queue. Use keywords like "rh72, QA, > stable". It seems that we agreed to NOT upgrade RPM for RH7.x, so apt > and yum-1.x are what we will be using. I guess most people running with RH 7.x are using apt-rpm from Matthias freshrpms package pool. People who like to be state of the art are using their own packages (like I do, ok a hand full of other people are using my packages aswell but that doesn't count ;). So if someone is interessted he can take look at my last apt-rpm rpms [1] They're working on my (last) RH 7.3 systems in conjunction with apticron to sent me mails abaut pending package upgrades. > clients. Damn I need to install that old distro... *hrhr* If they were that f*cking old there wouldn't be a discussion about EOL support ;) Happy new year, Sven [1] http://wrack.telelev.net/redhat/7.3/RPMS.main/ -- Revolution is not a dinner party, not an essay, nor a painting, nor a piece of embroidery; it cannot be advanced softly, gradually, carefully, considerately, respectfully, politely, plainly, and modestly. - Mao Zedong (Mao Tse-tung) From warren at togami.com Thu Jan 1 13:20:42 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 03:20:42 -1000 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <20040101121723.GA2122@sven.home.hoaxter.de> References: <3FF4052F.4070608@togami.com> <20040101121723.GA2122@sven.home.hoaxter.de> Message-ID: <3FF41EAA.3080803@togami.com> Sven Hoexter wrote: > >>After I am done copying packages into the repository, there is only one >>thing blocking the launch of Legacy for RH7.2 and RH7.3: We need >>maintainers for apt and/or yum clients for these older distributions. >>You must submit your packages to fedora.us QA just like any other >>package currently in the QA queue. Use keywords like "rh72, QA, >>stable". It seems that we agreed to NOT upgrade RPM for RH7.x, so apt >>and yum-1.x are what we will be using. > > I guess most people running with RH 7.x are using apt-rpm from Matthias > freshrpms package pool. People who like to be state of the art are using > their own packages (like I do, ok a hand full of other people are using > my packages aswell but that doesn't count ;). > So if someone is interessted he can take look at my last apt-rpm rpms [1] > They're working on my (last) RH 7.3 systems in conjunction with apticron > to sent me mails abaut pending package upgrades. > http://www.fedora.us/wiki/PackageSubmissionQAPolicy I do not have the time to do the work for you. You must submit it according to the policies laid out here if you are serious about wanting to become the RH7.x Legacy apt maintainer. While the "updates" of Legacy no longer conform to fedora.us naming conventions, add-ons like apt must do so in order to avoid upgrade version clashes. http://download.fedora.us/fedora/fedora/1/i386/SRPMS.testing/apt-0.5.15cnc4-0.fdr.4.1.src.rpm I am really hoping that Panu can help us with apt for RH7.x, because the we can possibly integrate the mirror choosing script functionality currently contained within this test version of apt. He has bug fixes for the mirror choosing script too. > >>clients. Damn I need to install that old distro... > > *hrhr* If they were that f*cking old there wouldn't be a discussion about > EOL support ;) All of my systems are RH9 and FC1 now... =( I am really not working on Legacy for my own health. I am putting together this infrastructure and policies so you folks have a chance of making this a viable and self sustaining project. I personally have ZERO PLANS to work on the packages, as I will not have the time or the need to use those packages. Thus everything depends on you. Yes you. In a collective sense of you. Warren From warren at togami.com Thu Jan 1 13:31:01 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 03:31:01 -1000 Subject: Legacy RPM Upgrade Guide Message-ID: <3FF42115.7010109@togami.com> http://www.fedora.us/wiki/LegacyRPMUpgrade This document is almost complete. It only needs some cleanups, the rpm packages copied into "legacy" channel and packages to download further clarified. Please suggest further improvements. Read the page. I think I have found a solution to the RPM upgrade problem. You CAN avoid upgrading RPM and still use Fedora Legacy updates. Is everyone okay with this solution? Warren From cra at WPI.EDU Thu Jan 1 17:12:47 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 1 Jan 2004 12:12:47 -0500 Subject: Legacy RPM Upgrade Guide In-Reply-To: <3FF42115.7010109@togami.com> References: <3FF42115.7010109@togami.com> Message-ID: <20040101171246.GA20572@angus.ind.WPI.EDU> On Thu, Jan 01, 2004 at 03:31:01AM -1000, Warren Togami wrote: > Read the page. I think I have found a solution to the RPM upgrade > problem. You CAN avoid upgrading RPM and still use Fedora Legacy > updates. Is everyone okay with this solution? Looks great to me. I suggest you add up2date (and maybe gnorpm) to the list of programs that should not be running. For the RPM Deadlock Recovery, I have always been told by jbj that you should run --rebuilddb, and he says it here too: http://www.rpm.org/hintskinks/repairdb/ From smilo at vcn.com Thu Jan 1 17:48:32 2004 From: smilo at vcn.com (David Marshall) Date: Thu, 1 Jan 2004 10:48:32 -0700 Subject: confirmation Message-ID: <001e01c3d08f$b30ed3e0$2655c1d1@smilo> Thank you.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.peltonen at iki.fi Thu Jan 1 18:21:11 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 01 Jan 2004 20:21:11 +0200 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF4052F.4070608@togami.com> References: <3FF4052F.4070608@togami.com> Message-ID: <3FF46517.4040200@iki.fi> Warren Togami wrote: > http://www.fedora.us/wiki/FedoraChannels I added this link to Wiki under Production Legacy notes: http://www.fedora.us/wiki/FedoraLegacy Maybe there should be a direct link to the mirror list, too? Also the page http://www.fedoralegacy.org/ should have a link to the wiki page, as it has the most current information at the moment, don't you agree? Regards, Peter From warren at togami.com Thu Jan 1 20:52:29 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 10:52:29 -1000 Subject: Legacy RPM Upgrade Guide In-Reply-To: <20040101171246.GA20572@angus.ind.WPI.EDU> References: <3FF42115.7010109@togami.com> <20040101171246.GA20572@angus.ind.WPI.EDU> Message-ID: <3FF4888D.1060202@togami.com> Charles R. Anderson wrote: > On Thu, Jan 01, 2004 at 03:31:01AM -1000, Warren Togami wrote: > > >>Read the page. I think I have found a solution to the RPM upgrade >>problem. You CAN avoid upgrading RPM and still use Fedora Legacy >>updates. Is everyone okay with this solution? > > > Looks great to me. I suggest you add up2date (and maybe gnorpm) to > the list of programs that should not be running. > > For the RPM Deadlock Recovery, I have always been told by jbj that you > should run --rebuilddb, and he says it here too: > > http://www.rpm.org/hintskinks/repairdb/ I think the --rebuilddb recommendation is outdated, and this page is by Russ Herrold and not jbj. I recall reading something by jbj saying that --rebuilddb is not needed, and this is confirmed by my own experience of NEVER NEEDING IT THROUGH RH8 - FC1. The last time I used it by necessity was RH7.3. YMMV... In any case we should check with jbj about this. Warren From green at r8.dion.ne.jp Fri Jan 2 02:03:27 2004 From: green at r8.dion.ne.jp (Green) Date: Fri, 2 Jan 2004 11:03:27 +0900 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF46517.4040200@iki.fi> References: <3FF4052F.4070608@togami.com> <3FF46517.4040200@iki.fi> Message-ID: <20040102110327.0d113bdb.green@r8.dion.ne.jp> On Thu, 01 Jan 2004 20:21:11 +0200 Peter Peltonen wrote: > Warren Togami wrote: > > http://www.fedora.us/wiki/FedoraChannels > > I added this link to Wiki under Production Legacy notes: > > http://www.fedora.us/wiki/FedoraLegacy > > Maybe there should be a direct link to the mirror list, too? > > Also the page > > http://www.fedoralegacy.org/ Hello, I am new here and this is my first posting. As I do not know about technical matters, but it semms to me that we had better inform fedora users that Legacy support is now going to start on a web site: http://www.fedoralegacy.org/ which will be the future website of Fedora Legacy in simple and to be understood easily by many. In short, like this: http://www.h7.dion.ne.jp/~greens/fedora_legacy/plan.html I think it must be better to change a layout of that top page soon. Was I helpful? Than you. Green. http://www.h7.dion.ne.jp/~greens/ From admin at cs.montana.edu Fri Jan 2 02:42:17 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 1 Jan 2004 19:42:17 -0700 (MST) Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <20040102110327.0d113bdb.green@r8.dion.ne.jp> References: <3FF4052F.4070608@togami.com><3FF46517.4040200@iki.fi> <20040102110327.0d113bdb.green@r8.dion.ne.jp> Message-ID: <33168.216.166.133.165.1073011337.squirrel@www.cs.montana.edu> I like how the page looks. Easy to read and understand. Green said: > which will be the future website of Fedora Legacy in simple > and to be understood easily by many. In short, like this: > http://www.h7.dion.ne.jp/~greens/fedora_legacy/plan.html -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From admin at cs.montana.edu Fri Jan 2 02:43:27 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 1 Jan 2004 19:43:27 -0700 (MST) Subject: RPM upgrade discussion In-Reply-To: <20040101031652.GA7416@devserv.devel.redhat.com> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> Message-ID: <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> Bill Nottingham said: > Yes, but pushing a new RPM with this will cause problems for > people installing original packages in the meantime. > > Bill Won't this also break upgrades? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From herrold at owlriver.com Fri Jan 2 03:26:39 2004 From: herrold at owlriver.com (R P Herrold) Date: Thu, 1 Jan 2004 22:26:39 -0500 (EST) Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> Message-ID: On Thu, 1 Jan 2004, Lucas Albers wrote: > Bill Nottingham said: > > > Yes, but pushing a new RPM with this will cause problems for > > people installing original packages in the meantime. > Won't this also break upgrades? Yes, probably. I feel one constraint on updates in an EOL product should arguably seek to be as minimal and general in nature, and support a given Major.Minor release as possible. [somewhat in line with the Unix principle of 'least surprise'] This was articulated in the rather nice Mark Cox piece at: http://www.redhat.com/advice/speaks_backport.html wherein he notes: > We can't please everyone, and backporting annoys some users > who always want to be upgraded to the latest and greatest > releases. However, in general, customers are more interested > in stability, and the ability to minimise the changes needed > for their QA and deployment. If a requirement of using fedora-legacy content is to also move to a version of RPM which, during its support life RH QA or RH Corporate did not see fit to issue for pre-RHL 9 (and soon, all RHL variants), there is a strong obligation for 'fedora-legacy'to state this clearly to the sysadmin using it. In the EOL context (as fedora-legacy project is), I lean to the side for minimal 'intrusion', to satisfy security requirements, but not to add functionality. There is a known path for recovery from the RPM 'stale locks' issue which does NOT require a non-security RPM 'update' -- Others may come out differently in all good intent; but except for the unresolved subtle RPM exploit path mentioned on a public list (which should properly be resolvable as the SELinux capability extensions are rolled in [which will not happen in fedora-legacy]), a change to rpm-4.2.x is just a "upgrade to the latest and greatest." No thanks. I saw also in this thread, some critique of the http://www.rpm.org/ website continuing mention of using --rebuilddb, in the process of recovery from 'stale locks' in some RHL versions. While it is an interesting datum that one person, using some of Red Hat's (and self-built variants) in an unstated number of hosts has found '--rebuilddb' unnecesary, it is also clear that several reporters on the RH hosted rpm-list _have_ so reported the utility of this approach in resolving such problems. As there is more to RPM than Red Hat's RHL variants (heck, I answered a question on an RHL 5.2 rpm variant the other day), as that site's editor I see no compelling reason to alter that site's advice. -- Russ Herrold From warren at togami.com Fri Jan 2 03:59:52 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 17:59:52 -1000 Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> Message-ID: <3FF4ECB8.7060204@togami.com> R P Herrold wrote: > > There is a known path for recovery from the RPM 'stale locks' > issue which does NOT require a non-security RPM 'update' -- > Others may come out differently in all good intent; but except > for the unresolved subtle RPM exploit path mentioned on a > public list (which should properly be resolvable as the > SELinux capability extensions are rolled in [which will not > happen in fedora-legacy]), a change to rpm-4.2.x is just a > "upgrade to the latest and greatest." No thanks. > rpm-4.2.x is NOT what Fedora Legacy is doing. http://www.fedora.us/wiki/LegacyRPMUpgrade Warren From warren at togami.com Fri Jan 2 04:06:57 2004 From: warren at togami.com (Warren Togami) Date: Thu, 01 Jan 2004 18:06:57 -1000 Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: <3FF4ECB8.7060204@togami.com> References: <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> Message-ID: <3FF4EE61.6080302@togami.com> Warren Togami wrote: > R P Herrold wrote: > >> >> There is a known path for recovery from the RPM 'stale locks' >> issue which does NOT require a non-security RPM 'update' -- To me it is laughable to expect users to tolerate this. Though you are entitled to have your own opinion. The users can decide on their own now. >> Others may come out differently in all good intent; but except >> for the unresolved subtle RPM exploit path mentioned on a >> public list (which should properly be resolvable as the >> SELinux capability extensions are rolled in [which will not >> happen in fedora-legacy]), a change to rpm-4.2.x is just a >> "upgrade to the latest and greatest." No thanks. >> > > rpm-4.2.x is NOT what Fedora Legacy is doing. > > http://www.fedora.us/wiki/LegacyRPMUpgrade Also the page states that upgrading RPM is not required to us the "updates" channel. Warren From andy.henson.fedora at zexia.co.uk Fri Jan 2 10:56:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Fri, 2 Jan 2004 10:56 +0000 (GMT Standard Time) Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF409BD.3040406@togami.com> Message-ID: It would be useful to have yum for 7.3 in the stable or legacy channel as soon as possible. It's really a prerequisite for using these channels seriously. Neither yum nor apt is currently in the http://download.fedora.us/fedora/redhat/7.3/i386/ tree. Also, I notice there's no header.info in the repositories, which yum needs. Are we supposed to be using yum for 7.3 legacy updates? Andy Henson From warren at togami.com Fri Jan 2 11:45:06 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Jan 2004 01:45:06 -1000 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: References: Message-ID: <3FF559C2.7020506@togami.com> Andy Henson wrote: > It would be useful to have yum for 7.3 in the stable or legacy channel as > soon as possible. It's really a prerequisite for using these channels > seriously. > > Neither yum nor apt is currently in the > http://download.fedora.us/fedora/redhat/7.3/i386/ tree. > > Also, I notice there's no header.info in the repositories, which yum needs. > Are we supposed to be using yum for 7.3 legacy updates? > There IS the headers directory that contains .hdr files and headers.info for the "os" and "updates" channel. Currently both RH7.2 and RH7.3 are populated, and yum + apt enabled. We need people to work on and submit apt and yum packages for RH7.2 and RH7.3 to fedora.us QA as specified here: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Until people do so, your only choice is to get apt or yum from FreshRPMS.net, and reconfigure it to use Fedora Legacy. http://www.fedora.us/pipermail/fedora-announce/2004-January/000005.html Please excuse me if the sites go down late Friday because I am dealing with a crisis here. The University only informs me tonght that the power will be out from late Friday until Monday. I am currently scrambling to get download.fedora.us moved to another server off campus and as much of the other infrastructure on different servers as possible. Luckily this mailing list is hosted at redhat.com so we can at least communicate. Hopefully I will have at least bugzilla.fedora.us, download.fedora.us and www.fedora.us moved off campus so we can continue to work on this during the weekend. Warren From Axel.Thimm at physik.fu-berlin.de Fri Jan 2 12:08:17 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 2 Jan 2004 13:08:17 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <3FF4EE61.6080302@togami.com> <3FF4ECB8.7060204@togami.com> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> Message-ID: <20040102120817.GE22959@neu.nirvana> On Thu, Jan 01, 2004 at 06:06:57PM -1000, Warren Togami wrote: > Warren Togami wrote: > >R P Herrold wrote: > > > >> > >>There is a known path for recovery from the RPM 'stale locks' > >>issue which does NOT require a non-security RPM 'update' -- > > To me it is laughable to expect users to tolerate this. Though you are > entitled to have your own opinion. The users can decide on their own now. > > >>Others may come out differently in all good intent; but except > >>for the unresolved subtle RPM exploit path mentioned on a > >>public list (which should properly be resolvable as the > >>SELinux capability extensions are rolled in [which will not > >>happen in fedora-legacy]), a change to rpm-4.2.x is just a > >>"upgrade to the latest and greatest." No thanks. > >> > > > >rpm-4.2.x is NOT what Fedora Legacy is doing. > > > >http://www.fedora.us/wiki/LegacyRPMUpgrade > > Also the page states that upgrading RPM is not required to us the > "updates" channel. So o Red Hat, Inc. and R P Herrold are laughable o FedoraLegacy is supposed to do what you wrote in the Wiki, although even the person with the Legacy Leader cap (or fedora) refrained from it. o rpm is not required as an upgrade, but people not doing it "are also unsupported by the Fedora Legacy team." by your decision. o Jeff Johnson is quoted by you to recommend to not to use rpm --rebuilddb. Jeff almost got a stroke, when I asked him about that. What is next? Users of third party repos are also expelled and unsupported? Hosting Legacy at fedora.us is probably already implying your set of policies upon it. Once again there is a pattern of 'Le Fedora-legacy, c'est moi'. I find that this discussion and false assertions are thwarting development of this project. You are driving developers away. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Fri Jan 2 13:02:38 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Jan 2004 03:02:38 -1000 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <20040102120817.GE22959@neu.nirvana> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> Message-ID: <3FF56BEE.4040400@togami.com> Axel Thimm wrote: > > o Red Hat, Inc. and R P Herrold are laughable The entity and individuals no, but regarding that particular statement it is my personal opinion that it is a teribly poor situation to even suggest that. It is bad that we went for so long with "kill rpm and erase the lock files" as the only supported solution. > o FedoraLegacy is supposed to do what you wrote in the Wiki, although > even the person with the Legacy Leader cap (or fedora) refrained > from it. What does this mean? > o rpm is not required as an upgrade, but people not doing it "are also > unsupported by the Fedora Legacy team." by your decision. It seemed like a good decision, and better than forcing everyone to upgrade to RPM. If they want to avoid upgrading RPM, then they can't use the "legacy" channel which has the package manager that depends on that upgraded version of RPM. How is this unreasonable? > o Jeff Johnson is quoted by you to recommend to not to use rpm > --rebuilddb. Jeff almost got a stroke, when I asked him about that. > I have not read anything to the contrary coming from him. The last thing I recall reading from Jeff indicated that --rebuilddb was unnecessary to deal specifically with the rpm deadlock issue. I would invite him to elucidate the situation. > What is next? Users of third party repos are also expelled and > unsupported? Slippery slope arguments are usually born out of emotional illogic. > Hosting Legacy at fedora.us is probably already implying > your set of policies upon it. Write a complete set of alternative policies and procedures, with the infrastructure and documentation to back it up. Then make it collaborative. Then let the group decide. The current proposal for Legacy development was born out of the lack of anything else being written, or even discussed. Simply dismissing something without proposing a complete alternative is not productive. > > Once again there is a pattern of 'Le Fedora-legacy, c'est moi'. I find > that this discussion and false assertions are thwarting development of > this project. Given the complete lack of initiative and direction by anyone else here, I stepped in and offered a structured and proven solution based upon the highly successful fedora.us development model. I even proposed this plan to those who said they wanted to be Legacy leaders during early December, but I got ZERO replies (other than Michael). If the majority here dislikes what I am doing, then say so. Then subsequently be prepared to step in and keep the ball rolling with your own solutions. Heck, even if you agree with the direction that I am pushing, I realistically cannot remain pushing initiatives here. My time is very short after January 5th. Unless others show more initatiative this project will die. I personally do not even USE the distributions that Legacy would support, but I worked hard on this because I wanted to give the community at least the chance. > > You are driving developers away. Given the lack of prior discussion, I wondered if they were even here to begin with. It is my hope that this proposed framework will at least give them the chance to make it succeed. Please feel free to discuss and improve the proposed framework. Warren From warren at togami.com Fri Jan 2 13:05:26 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Jan 2004 03:05:26 -1000 Subject: apt preparation for Legacy In-Reply-To: References: <3FF422A0.6010603@togami.com> Message-ID: <3FF56C96.1030002@togami.com> Panu Matilainen wrote: >>another note about apt in RH7.x, hoping for your recommendations or help >>with that package. It would be really nice if we can get the fixed >>mirror selector into RH7.x apt for Legacy. > > > I hope to get a new version of apt, destined for FC1 stable, into > fedora.us QA next week but wont be able to do much anything before that. > > >>Are there any possible issues with lua in RH7.x? > > > Not that I remember - Lua should work just fine on 7.x too. > > >>Is rpmlib working with rpm-4.0.4, or must use external? > > > Rpmlib works all the way from rpm-3.0.x to 4.2.1 and is on by default for > those older rpm's as well. > > - Panu - Great! Sounds good. I will personally take your fixed apt + rpmlib + lua mirror selector and craft the RH7.x apt for Legacy. Let me know when your package is available. Thanks Panu. Warren Togami warren at togami.com From skvidal at phy.duke.edu Fri Jan 2 13:24:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Jan 2004 08:24:21 -0500 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF559C2.7020506@togami.com> References: <3FF559C2.7020506@togami.com> Message-ID: <1073049861.17269.7.camel@binkley> On Fri, 2004-01-02 at 06:45, Warren Togami wrote: > There IS the headers directory that contains .hdr files and headers.info > for the "os" and "updates" channel. Currently both RH7.2 and RH7.3 are > populated, and yum + apt enabled. > > We need people to work on and submit apt and yum packages for RH7.2 and > RH7.3 to fedora.us QA as specified here: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > Until people do so, your only choice is to get apt or yum from > FreshRPMS.net, and reconfigure it to use Fedora Legacy. > Get yum for 7.X from: http://linux.duke.edu/yum/ Look on the download page. There is a entry labeled 1.0.X - get that one. -sv From green at r8.dion.ne.jp Fri Jan 2 14:15:44 2004 From: green at r8.dion.ne.jp (Green) Date: Fri, 2 Jan 2004 23:15:44 +0900 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <3FF56BEE.4040400@togami.com> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <3FF56BEE.4040400@togami.com> Message-ID: <20040102231544.7dcf43fa.green@r8.dion.ne.jp> On Fri, 02 Jan 2004 03:02:38 -1000 Warren Togami wrote: > Unless others show more initatiative this project will die. I > personally do not even USE the distributions that Legacy would support, > but I worked hard on this because I wanted to give the community at > least the chance. I am now using Fedora Core Release 1 for my desktop purpose. As a opinion among many of Fedora or RedHat Linux users, I expect that fedora legacy project will give a useful and reliable support fot a future use of the EOL distributions. I hope this project will procced smoothly, according to the principles and draft that have decide earlier. Thank you. Green. From andy.henson.fedora at zexia.co.uk Fri Jan 2 14:55:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Fri, 2 Jan 2004 14:55 +0000 (GMT Standard Time) Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF559C2.7020506@togami.com> Message-ID: Warren wrote: > There IS the headers directory that contains .hdr files and headers.info > for the "os" and "updates" channel. Currently both RH7.2 and RH7.3 are > populated, and yum + apt enabled. My apologies, you are quite correct. However the headers don't seem to have made it over to the London mirror. I'll use http://download.fedora.us for now. yum works fine with them. Andy Henson PS: Big thanks to Warren for all his work so far. From dawson at fnal.gov Fri Jan 2 15:07:50 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 02 Jan 2004 09:07:50 -0600 Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: References: Message-ID: <3FF58946.20004@fnal.gov> Chuck Wolber wrote: > >>1) Clear separation between the official RH/FC updates and Legacy updates. > > > Ok, I can understand that. But instead of legacy, why not flrh7.3, > flrh8.0, flrh9? > I really have no overall opinion about how they are marked, as long as they are marked in some way. But I don't think flrh is a very good mark. It took me about 3 times reading it through wondering why you would want to mark it "Fermi Linux Red Hat". flrh (besides being very vague) is really only 2 letters shorter. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From pearcec at commnav.com Fri Jan 2 15:43:44 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 2 Jan 2004 15:43:44 GMT Subject: fedora-l] Re: RPM upgrade discussion Message-ID: <4224.66.92.232.244.1073058224.commnav@home.commnav.com> Personally I think this is great. It seems to me we are cleaning up a problem Red Hat should have taken steps to correct. Maybe they decided keep it this way for reason not known to me. But then again I didn't read all the bugs entries about this. I am a little confused as to the solution. 7.x isn't going to have to upgrade. This makes sense because they are stable. I am also taking this to mean they are only able to use older version of apt and yum. Doesn't this create a restriction of the how the channels are used? I am new to apt and yum. But I plan on using one or the other. FedoraLegacy is recommending an upgrade to the resigned rpm.org package 4.1 (whatever the correct version). But if you don't they you can still use the all channels accept Legacy. Is this because it contains apt and yum with compiled against the newer version of rpm? I think this needs to be explained a little better in the RPMUpgrade Wiki page. I think new users will want to know the reasons and details why. I am willing to go with the flow. But in a lot of cases I still want to understand why. Other than that I think the RPMUpgrade Wiki page is good. I am with you on this Warren, I think it is laughable to think users would want to suffer through deadlocks. BTW: download.fedora.us doesn't appear to be functioning. I guess someone is upgrading. -- Christian Pearce http://www.commnav.com Warren Togami said: > > Warren Togami wrote: > > R P Herrold wrote: > > > >> > >> There is a known path for recovery from the RPM 'stale locks' > >> issue which does NOT require a non-security RPM 'update' -- > > To me it is laughable to expect users to tolerate this. Though you are > entitled to have your own opinion. The users can decide on their own now. > > >> Others may come out differently in all good intent; but except > >> for the unresolved subtle RPM exploit path mentioned on a > >> public list (which should properly be resolvable as the > >> SELinux capability extensions are rolled in [which will not > >> happen in fedora-legacy]), a change to rpm-4.2.x is just a > >> "upgrade to the latest and greatest." No thanks. > >> > > > > rpm-4.2.x is NOT what Fedora Legacy is doing. > > > > http://www.fedora.us/wiki/LegacyRPMUpgrade > > Also the page states that upgrading RPM is not required to us the > "updates" channel. > > Warren > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From pearcec at commnav.com Fri Jan 2 16:06:43 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 2 Jan 2004 16:06:43 GMT Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) Message-ID: <4400.66.92.232.244.1073059603.commnav@home.commnav.com> Warren Togami said: > Given the complete lack of initiative and direction by anyone else here, > I stepped in and offered a structured and proven solution based upon the > highly successful fedora.us development model. I even proposed this > plan to those who said they wanted to be Legacy leaders during early > December, but I got ZERO replies (other than Michael). > > If the majority here dislikes what I am doing, then say so. Then > subsequently be prepared to step in and keep the ball rolling with your > own solutions. > > Heck, even if you agree with the direction that I am pushing, I > realistically cannot remain pushing initiatives here. My time is very > short after January 5th. > > Unless others show more initatiative this project will die. I > personally do not even USE the distributions that Legacy would support, > but I worked hard on this because I wanted to give the community at > least the chance. > > Given the lack of prior discussion, I wondered if they were even here to > begin with. It is my hope that this proposed framework will at least > give them the chance to make it succeed. > > Please feel free to discuss and improve the proposed framework. > > Warren I am working on it. I appreciate all you have done so far. It seems to be there are very few interested developers so far. So I am going to read up on the Submission proccess. And get more involved. It seems to me at this point we have a pretty good framework of a policy and procedures defined. Not having read the submission process, I recall from memory we have package owners and QA people. What is a method for staying informed of fixes? Ad Hoc? We should also have a specific team of people to vote security fixes in or out. I don't want to see it a mailing list vote of all those involved. Considering this is going to be time crucial. Warren, You mentioned you are at Red Hat 9 and FC1 that you have not interest in RHL 7.x-8.0. Do you intend to use FedoraLegacy for Red Hat 9 and FC1 and FC2 and beyond? If so I would imagine you would take more interest in the future use of this project. Not that you haven't. You have done a lot and we appreciate it. I was just curious. Okay back to reading. -- Christian Pearce http://www.commnav.com From blists at nobaloney.net Fri Jan 2 17:22:39 2004 From: blists at nobaloney.net (Jeff Lasman) Date: Fri, 2 Jan 2004 09:22:39 -0800 Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: <4224.66.92.232.244.1073058224.commnav@home.commnav.com> References: <4224.66.92.232.244.1073058224.commnav@home.commnav.com> Message-ID: <200401020922.39563.blists@nobaloney.net> On Friday 02 January 2004 07:43 am, Christian Pearce wrote: > BTW: download.fedora.us doesn't appear to be functioning. I guess > someone is upgrading. It was announced somewhere, perhaps on this list, that power to the building it's housed in would be down today through the weekend. It was suggested at that time that you use a mirror. Jeff -- Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US Professional Internet Services & Support / Consulting / Colocation Our blists address used on lists is for list email only Phone +1 909 324-9706, or see: "http://www.nobaloney.net/contactus.html" From ms-nospam-0306 at arcor.de Fri Jan 2 19:44:45 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 2 Jan 2004 20:44:45 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <20040102120817.GE22959@neu.nirvana> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> Message-ID: <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> On Fri, 2 Jan 2004 13:08:17 +0100, Axel Thimm wrote: > On Thu, Jan 01, 2004 at 06:06:57PM -1000, Warren Togami wrote: > > Warren Togami wrote: > > >R P Herrold wrote: > > > > > >> > > >>There is a known path for recovery from the RPM 'stale locks' > > >>issue which does NOT require a non-security RPM 'update' -- > > > > To me it is laughable to expect users to tolerate this. Though you are > > entitled to have your own opinion. The users can decide on their own now. > > > > >>Others may come out differently in all good intent; but except > > >>for the unresolved subtle RPM exploit path mentioned on a > > >>public list (which should properly be resolvable as the > > >>SELinux capability extensions are rolled in [which will not > > >>happen in fedora-legacy]), a change to rpm-4.2.x is just a > > >>"upgrade to the latest and greatest." No thanks. > > >> > > > > > >rpm-4.2.x is NOT what Fedora Legacy is doing. > > > > > >http://www.fedora.us/wiki/LegacyRPMUpgrade > > > > Also the page states that upgrading RPM is not required to us the > > "updates" channel. > > So > > o Red Hat, Inc. and R P Herrold are laughable /me thinks a summary like that is not needed for subscribers of this list to understand how the previous mails in this thread are meant to be understood correctly. The "RPM stale locks" problem is a serious issue for the average user despite the "rm -f /var/lib/rpm/__db.*" work-around being available. What works for Red Hat engineers and people who know about that work-around, is not accepted by other people at all. In their opinion, such a behaviour of RPM is plain broken and "stinks, if it isn't the same in Red Hat Enterprise Linux". Those spontaneous "RPM lock ups" haven't made Red Hat Linux look good. > o Jeff Johnson is quoted by you to recommend to not to use rpm > --rebuilddb. Jeff almost got a stroke, when I asked him about that. Deja vu? I've seen him recommending, that --rebuilddb is not necessary [anymore]. FWIW, whenever I recommend "rm -f /var/lib/rpm/__db.* ; rpm -vv --rebuilddb" myself, it is because experience has it that sometimes this has helped further than removal of the tmp files. You never know what the user has done to make RPM "hang". > What is next? Users of third party repos are also expelled and > unsupported? Hosting Legacy at fedora.us is probably already implying > your set of policies upon it. It looks much more like an attempt at offering a _framework_ for Fedora Legacy, in particular input for discussion. Warren is somewhat over-ambitious IMO, because he's the "let's do it -- push it forward -- get it going" type of guy who doesn't seem to mind doing most of the preparations himself and making lots of proposals for policies. Without such a work-force, fedora.us would not have become reality. That makes a project in its early stages look as if everything is ready and gives potential consumers the impression that they can count on the project. But I have doubts that Fedora Legacy has enough human resources who can tackle upcoming problems [if any]. Instead of putting a big effort into starting an open community project, other individuals would rather sit and wait and e.g. release a self-made rpm on their private web space. > Once again there is a pattern of 'Le Fedora-legacy, c'est moi'. I find > that this discussion and false assertions are thwarting development of > this project. > > You are driving developers away. I would appreciate if any of those virtual developers would speak for themselves. Most of the proposals posted to this list have seen only acknowledgements. Being mostly a lurker on this list, I find the discussions tiresome, and it is not clear at all who will contribute what. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Fri Jan 2 20:34:42 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 2 Jan 2004 15:34:42 -0500 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> References: <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> Message-ID: <20040102203442.GC20572@angus.ind.WPI.EDU> On Fri, Jan 02, 2004 at 08:44:45PM +0100, Michael Schwendt wrote: > > o Jeff Johnson is quoted by you to recommend to not to use rpm > > --rebuilddb. Jeff almost got a stroke, when I asked him about that. > > Deja vu? I've seen him recommending, that --rebuilddb is not necessary > [anymore]. I asked jbj about this on #rpm just today. I hope he doesn't mind me quoting him: Jan 02 11:14:42 jbj there is some confusion on fedora-legacy list regard ing recovering after a hung rpm. is it really necessary or not to do a rpm --rebuilddb after deleting the lock files? Jan 02 11:16:25 http://www.fedora.us/wiki/LegacyRPMUpgrade Jan 02 11:29:14 cra_: --rebuilddb hardly ever necessary, rm -f /var/lib/rpm/__db* for exceptional events like kill -9 or segfault. Jan 02 11:29:46 otoh, --rebuilddb won't hurt Jan 02 11:31:16 cd /var/lib/rpm && /usr/lib/rpm/rpmdb_stat -CA will display slocks. perhaps that is most useeful in demystifying. Jan 02 11:31:29 s/slocks/locks/ > FWIW, whenever I recommend "rm -f /var/lib/rpm/__db.* ; rpm -vv --rebuilddb" > myself, it is because experience has it that sometimes this has helped > further than removal of the tmp files. You never know what the user > has done to make RPM "hang". I agree. While not necessary for the exact known causes of most hangs in rpm where it is necessary for kill -9, I'd recommend it to new users since it may help fix other problems, and in general it is always safe to do. I have seen cases where "rpm -qa" hangs halfway through, and this can only be fixed by --rebuilddb. If in doubt, save /var/lib/rpm to a backup directory first. Even an experienced admin appreciates not having to perform these recovery methods as part of a normal process of using rpm, which is why I have upgraded all my systems to the latest jbj-recommended releases from rpm.org. > Legacy, in particular input for discussion. Warren is somewhat > over-ambitious IMO, because he's the "let's do it -- push it forward -- > get it going" type of guy who doesn't seem to mind doing most of the > preparations himself and making lots of proposals for policies. Without > such a work-force, fedora.us would not have become reality. That makes a Once again I agree. Some people were complaining that there was nothing in place for EOL distros, while doing nothing about it. Warren stepped up and has done a lot to make this a reality. Thank you Warren. From warren at togami.com Fri Jan 2 20:51:09 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Jan 2004 10:51:09 -1000 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <20040102203442.GC20572@angus.ind.WPI.EDU> References: <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> <20040102203442.GC20572@angus.ind.WPI.EDU> Message-ID: <3FF5D9BD.9080507@togami.com> Charles R. Anderson wrote: >>FWIW, whenever I recommend "rm -f /var/lib/rpm/__db.* ; rpm -vv --rebuilddb" >>myself, it is because experience has it that sometimes this has helped >>further than removal of the tmp files. You never know what the user >>has done to make RPM "hang". > > > I agree. While not necessary for the exact known causes of most hangs > in rpm where it is necessary for kill -9, I'd recommend it to new > users since it may help fix other problems, and in general it is > always safe to do. I have seen cases where "rpm -qa" hangs halfway ^^^^^^^^^^^^^^^^^ Not necessarily. There is the imported-GPG-key-causes-rebuilddb-to-corrupt-rpm signatures in rpmdb problem. I don't know the Bugzilla # at the moment though. I know about this very well, because they blamed ME for the problem at first. =) Warren From chuckw at quantumlinux.com Fri Jan 2 21:09:43 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 2 Jan 2004 13:09:43 -0800 (PST) Subject: Fedora Legacy Launch Plan (draft 2) In-Reply-To: <3FF58946.20004@fnal.gov> Message-ID: > > Ok, I can understand that. But instead of legacy, why not flrh7.3, > > flrh8.0, flrh9? > > I really have no overall opinion about how they are marked, as long as > they are marked in some way. But I don't think flrh is a very good > mark. It took me about 3 times reading it through wondering why you > would want to mark it "Fermi Linux Red Hat". > > flrh (besides being very vague) is really only 2 letters shorter. Size isn't the issue to me. Make it as big as you want it. Keep .legacy in there, it doesn't matter. I'd just like to know by looking at the filename that package XYZ is meant for RH 9 and not RH 7.3 or whatever. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From cra at WPI.EDU Fri Jan 2 21:11:16 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 2 Jan 2004 16:11:16 -0500 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <3FF5D9BD.9080507@togami.com> References: <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> <20040102203442.GC20572@angus.ind.WPI.EDU> <3FF5D9BD.9080507@togami.com> Message-ID: <20040102211116.GD20572@angus.ind.WPI.EDU> On Fri, Jan 02, 2004 at 10:51:09AM -1000, Warren Togami wrote: > >always safe to do. I have seen cases where "rpm -qa" hangs halfway > ^^^^^^^^^^^^^^^^^ > Not necessarily. There is the > imported-GPG-key-causes-rebuilddb-to-corrupt-rpm signatures in rpmdb > problem. I don't know the Bugzilla # at the moment though. Is this it? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108032 > I know about this very well, because they blamed ME for the problem at > first. =) Doh! From ingo at auroralinux.org Sat Jan 3 10:17:01 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Sat, 3 Jan 2004 11:17:01 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) References: <3FF4ECB8.7060204@togami.com><3FF4EE61.6080302@togami.com><3FF1472D.7030606@togami.com><20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net><3FF2A661.5070408@togami.com><20040101031652.GA7416@devserv.devel.redhat.com><33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu><3FF4ECB8.7060204@togami.com><20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> Message-ID: <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> >The "RPM stale locks" problem is a serious issue for the average >user despite the "rm -f /var/lib/rpm/__db.*" work-around >being available. I don't think that many "average users" will use FedoraLegacy. They are probably on FC1, Suse, Gentoo, Debian, you-name-it by now. rh7x is legacy, isn't it? Add to that that I seem to be doing completely different things with my rpm databases. I maintain some 40 boxes running rh72 (i386 and axp) and rh73 (i386 and Aurora). I use upd2ate against a current server to keep them patched, so they run rpm at least once a day (up2date -l in cron.daily) and I haven't seen rpm deadlock since the early Aurora days. I thus (again) strongly vote that the rpm upgrade should not be mandatory for rh7x. Thanks, Ingo From ingo at auroralinux.org Sat Jan 3 10:20:39 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Sat, 3 Jan 2004 11:20:39 +0100 Subject: Fedora Legacy Launch Plan (draft 2) References: Message-ID: <00f301c3d22a$9fe59af0$022ca8c0@OPTIMUS> > Size isn't the issue to me. [...] I'd just like to know by looking at the filename > that package XYZ is meant for RH 9 and not RH 7.3 or whatever. I strongly support this. And I don't care too much if the outcome is "ugly", as long as it is unambiguous PLUS machine and human readable. Ingo From jkeating at j2solutions.net Sat Jan 3 19:19:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 3 Jan 2004 11:19:40 -0800 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <3FF56BEE.4040400@togami.com> References: <20040102120817.GE22959@neu.nirvana> <3FF56BEE.4040400@togami.com> Message-ID: <200401031119.40551.jkeating@j2solutions.net> On Friday 02 January 2004 05:02, Warren Togami wrote: > Given the complete lack of initiative and direction by anyone else > here, I stepped in and offered a structured and proven solution based > upon the highly successful fedora.us development model. I even > proposed this plan to those who said they wanted to be Legacy leaders > during early December, but I got ZERO replies (other than Michael). Hrm, I feel this was directed at me. I have to apologize for my lack of presence on the net, due to family commitments over the holidays, and being in places w/out internet access. I am back, and I am reading through all that was posted here. I have the build server sitting on a shelf at work, ready for a proper OS installation and a test run of mach. Once it's set, I'll be moving it to the colo and it will be used to produce the updates that will be pushed into fedora.us's tree. I still have not read the RPM upgrade proposal, and thus I will not make any comments one way nor the other toward it. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From lowen at pari.edu Sat Jan 3 20:22:52 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 3 Jan 2004 15:22:52 -0500 Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: <3FF4ECB8.7060204@togami.com> References: <3FF1472D.7030606@togami.com> <3FF4ECB8.7060204@togami.com> Message-ID: <200401031522.52273.lowen@pari.edu> On Thursday 01 January 2004 10:59 pm, Warren Togami wrote: > rpm-4.2.x is NOT what Fedora Legacy is doing. That's probably a good thing. I can reliably and just about on command heavily corrupt a Fedora Core 1 RPM database on one machine I have in production. It's an AMD K6-2 that otherwise is solid as a rock; but a couple of runs of {apt|synaptic|up2date|yum} and I get all sorts of odd errors. RPM doesn't hang; it spits errors. Deleting /var/lib/rpm/Pubkeys and doing an rpm --rebuild restores it long enough to run rpm -U on a dozen or so packages before it starts spitting again. I have had to pipe the Packages db through rpmdb_dump and rpmdb_load at least a dozen times, now. The only thing that reliably restores operation (for a while) is rm of Pubkeys; but that's a temporary fix. Basically, every time I run up2date (and it actually installs more than just a few updates) I have to do the recovery. This is the only machine that has this problem. The machine passes several burn-in tests of RAM, CPU, and HD. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From cspencer at cait.org Sat Jan 3 22:08:33 2004 From: cspencer at cait.org (Chris Spencer) Date: Sat, 03 Jan 2004 16:08:33 -0600 Subject: fedora-l] Re: RPM upgrade discussion In-Reply-To: <200401031522.52273.lowen@pari.edu> References: <3FF1472D.7030606@togami.com> <3FF4ECB8.7060204@togami.com> <200401031522.52273.lowen@pari.edu> Message-ID: <1073167713.4232.2.camel@cnote> Have you filed a bug report on it? I don't seem to have these types of problems...but I don't mix up2date/yum and synaptic/apt. Do you have extra repositories that you are using? freshrpms + planetccrma + fedora core etc sometimes cause issues. -Chris On Sat, 2004-01-03 at 14:22, Lamar Owen wrote: > On Thursday 01 January 2004 10:59 pm, Warren Togami wrote: > > rpm-4.2.x is NOT what Fedora Legacy is doing. > > That's probably a good thing. I can reliably and just about on command > heavily corrupt a Fedora Core 1 RPM database on one machine I have in > production. It's an AMD K6-2 that otherwise is solid as a rock; but a couple > of runs of {apt|synaptic|up2date|yum} and I get all sorts of odd errors. RPM > doesn't hang; it spits errors. Deleting /var/lib/rpm/Pubkeys and doing an > rpm --rebuild restores it long enough to run rpm -U on a dozen or so packages > before it starts spitting again. I have had to pipe the Packages db through > rpmdb_dump and rpmdb_load at least a dozen times, now. The only thing that > reliably restores operation (for a while) is rm of Pubkeys; but that's a > temporary fix. > > Basically, every time I run up2date (and it actually installs more than just a > few updates) I have to do the recovery. This is the only machine that has > this problem. > > The machine passes several burn-in tests of RAM, CPU, and HD. From chuckw at quantumlinux.com Sat Jan 3 22:13:30 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 3 Jan 2004 14:13:30 -0800 (PST) Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <200401031119.40551.jkeating@j2solutions.net> Message-ID: > Hrm, I feel this was directed at me. I have to apologize for my lack of > presence on the net, due to family commitments over the holidays, and > being in places w/out internet access. I am back, and I am reading > through all that was posted here. I have the build server sitting on a > shelf at work, ready for a proper OS installation and a test run of > mach. Once it's set, I'll be moving it to the colo and it will be used > to produce the updates that will be pushed into fedora.us's tree. I > still have not read the RPM upgrade proposal, and thus I will not make > any comments one way nor the other toward it. Jesse, I'll go up there and do the install next week if you don't mind. That way we can get it in the colo cage next weekend. Lemme know if that works for you. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From ms-nospam-0306 at arcor.de Sat Jan 3 22:21:26 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 3 Jan 2004 23:21:26 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> Message-ID: <20040103232126.515a6f5b.ms-nospam-0306@arcor.de> On Sat, 3 Jan 2004 11:17:01 +0100, Ingo T. Storm wrote: > >The "RPM stale locks" problem is a serious issue for the average > >user despite the "rm -f /var/lib/rpm/__db.*" work-around > >being available. > > I don't think that many "average users" will use FedoraLegacy. They are > probably on FC1, Suse, Gentoo, Debian, you-name-it by now. rh7x is legacy, > isn't it? I don't refer to RPM on rh7x, because I don't see any problems there. That "RPM hangs" problem was introduced with rh80, which some people want to cover with Legacy updates, too. I could or should have written s/user/admin/, because that holds true even more. But users are also affected by the upgrade rush at the end of a rh80/rh9 life cycle and many have not installed their system when the OS was released, but months later. Regardless of whether user or admin, it is beyond most people's comprehension why such an annoying problem with RPM is not fixed. On rh80, the RPM from the fedora.us "patches" repository works a lot more reliable. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Sat Jan 3 23:35:17 2004 From: warren at togami.com (Warren Togami) Date: Sat, 03 Jan 2004 13:35:17 -1000 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> References: <3FF4ECB8.7060204@togami.com><3FF4EE61.6080302@togami.com><3FF1472D.7030606@togami.com><20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net><3FF2A661.5070408@togami.com><20040101031652.GA7416@devserv.devel.redhat.com><33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu><3FF4ECB8.7060204@togami.com><20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> Message-ID: <3FF751B5.70208@togami.com> Ingo T. Storm wrote: > I thus (again) strongly vote that the rpm upgrade should not be mandatory > for rh7x. > A few days ago we agreed on not upgrading RPM on rh7.x since it is reasonably stable, yum-1.x works fine, and apt is fine too. RPM on RH8 and RH9 will be upgraded, but only if you use the "legacy" repository which also includes a few fedora.us tools. If you avoid "legacy" and stick to "updates" channel you need to setup your own tool, but that is easy enough for the target audience. Warren From warren at togami.com Sun Jan 4 00:15:21 2004 From: warren at togami.com (Warren Togami) Date: Sat, 03 Jan 2004 14:15:21 -1000 Subject: RH7.x package signing Message-ID: <3FF75B19.8090004@togami.com> This is just to clarify, RPM packages for RH7.x must be signed by rpm-4.0.4 right? Warren From warren at togami.com Sun Jan 4 00:37:37 2004 From: warren at togami.com (Warren Togami) Date: Sat, 03 Jan 2004 14:37:37 -1000 Subject: apt preparation for RH7.x Message-ID: <3FF76051.4020006@togami.com> http://bugzilla.fedora.us/show_bug.cgi?id=1174 This is Panu Matilainen's latest work-in-progress apt for Fedora Core 1. Please assist us by submiting unidiffs for changing the specfile and SOURCES/* so that this builds and works properly on RH7.x. After we have a working package, your assistance in testing functionality will be needed. Among the changes necessary: * The BuildRequires for FC1 are very different than RH7.x. Most of the components exist in RH7.x with different names. Please figure out the minimum BuildRequires set necessary for RH7.x * http://fedora.laiskiainen.org/fedora-mirrors.list Panu's apt for FC1 downloads the latest mirrors list from a static URL, then makes the administrator choose mirrors the first time you use apt-get. Please help in finding mirrors that carry the complete Legacy RH7.x repository and rebuild this list file for Legacy. * Please verify that the GPG signature verification lua works with rpm-4.0.4. * Please verify that this apt works within chroots with and without /proc mounted. If you have discussion about this package, DISCUSS HERE in the mailing list. If you have fixes to submit, then attach it to the Bugzilla report. Bugzilla keyword LEGACY was added for this and all future Legacy specific packages. Warren From barryn at pobox.com Sun Jan 4 01:58:14 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 3 Jan 2004 17:58:14 -0800 Subject: RH7.x package signing In-Reply-To: <3FF75B19.8090004@togami.com> References: <3FF75B19.8090004@togami.com> Message-ID: <20040104015814.GC2545@ip68-4-255-84.oc.oc.cox.net> On Sat, Jan 03, 2004 at 02:15:21PM -1000, Warren Togami wrote: > This is just to clarify, RPM packages for RH7.x must be signed by > rpm-4.0.4 right? I've been signing packages for RPM 4.0.4 using RPM 4.2 without any problems, FWIW... -Barry K. Nathan From rostetter at mail.utexas.edu Sun Jan 4 04:52:46 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 3 Jan 2004 22:52:46 -0600 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <3FF56BEE.4040400@togami.com> References: <3FF4ECB8.7060204@togami.com> <3FF4EE61.6080302@togami.com> <3FF1472D.7030606@togami.com> <20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net> <3FF2A661.5070408@togami.com> <20040101031652.GA7416@devserv.devel.redhat.com> <33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu> <3FF4ECB8.7060204@togami.com> <20040102120817.GE22959@neu.nirvana> <3FF56BEE.4040400@togami.com> Message-ID: <20040103225246.tp30n0gss0ssg8og@mail.ph.utexas.edu> Quoting Warren Togami : > > Once again there is a pattern of 'Le Fedora-legacy, c'est moi'. I find > > that this discussion and false assertions are thwarting development of > > this project. > > Given the complete lack of initiative and direction by anyone else here, > I stepped in and offered a structured and proven solution based upon the > highly successful fedora.us development model. Yes, and *thank you* for doing so. > Unless others show more initatiative this project will die. I > personally do not even USE the distributions that Legacy would support, > but I worked hard on this because I wanted to give the community at > least the chance. Then *really* thank you! > > You are driving developers away. > > Given the lack of prior discussion, I wondered if they were even here to > begin with. I agree that if anything you are bringing developers in, not driving them away. What was driving people away was not having anything ready to go when the EOL hit. You've at least got the ball rolling, which can only be considered a good thing. > It is my hope that this proposed framework will at least > give them the chance to make it succeed. I hope so also. > Please feel free to discuss and improve the proposed framework. > > Warren -- Eric Rostetter From notting at redhat.com Sun Jan 4 05:30:05 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 4 Jan 2004 00:30:05 -0500 Subject: RH7.x package signing In-Reply-To: <3FF75B19.8090004@togami.com> References: <3FF75B19.8090004@togami.com> Message-ID: <20040104053005.GA1729@devserv.devel.redhat.com> Warren Togami (warren at togami.com) said: > This is just to clarify, RPM packages for RH7.x must be signed by > rpm-4.0.4 right? No. We've been pushing updates signed with 4.1 or later for quite a while now. Bill From ingo at auroralinux.org Sun Jan 4 13:26:29 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Sun, 4 Jan 2004 14:26:29 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) References: <3FF4ECB8.7060204@togami.com><3FF4EE61.6080302@togami.com><3FF1472D.7030606@togami.com><20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net><3FF2A661.5070408@togami.com><20040101031652.GA7416@devserv.devel.redhat.com><33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu><3FF4ECB8.7060204@togami.com><20040102120817.GE22959@neu.nirvana> <20040102204445.2dd3864a.ms-nospam-0306@arcor.de> <00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> <3FF751B5.70208@togami.com> Message-ID: <007901c3d2c9$00bf6ab0$022ca8c0@OPTIMUS> > A few days ago we agreed on not upgrading RPM on rh7.x ok, thanks. I am sorry, I obviously haven't read the entire holiday traffic on this list with the same scrutiny. Thanks, Ingo From ingo at auroralinux.org Sun Jan 4 13:28:54 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Sun, 4 Jan 2004 14:28:54 +0100 Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) References: <3FF4ECB8.7060204@togami.com><3FF4EE61.6080302@togami.com><3FF1472D.7030606@togami.com><20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net><3FF2A661.5070408@togami.com><20040101031652.GA7416@devserv.devel.redhat.com><33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu><3FF4ECB8.7060204@togami.com><20040102120817.GE22959@neu.nirvana><20040102204445.2dd3864a.ms-nospam-0306@arcor.de><00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> <20040103232126.515a6f5b.ms-nospam-0306@arcor.de> Message-ID: <007a01c3d2c9$0125cda0$022ca8c0@OPTIMUS> >I don't refer to RPM on rh7x, because I don't see any problems >there. That "RPM hangs" problem was introduced with rh80 I apologize to you, too. I have never used rh80 or rh9 in production, went straight to EL. Of course my reasoning only applies (fully) to the really old stuff. Ingo From maxfield at one.ctelcom.net Sun Jan 4 14:08:50 2004 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Sun, 4 Jan 2004 08:08:50 -0600 (CST) Subject: Unneeded assertions (supposed to have been: RPM upgrade discussion) In-Reply-To: <007a01c3d2c9$0125cda0$022ca8c0@OPTIMUS> References: <3FF4ECB8.7060204@togami.com><3FF4EE61.6080302@togami.com><3FF1472D.7030606@togami.com><20031231093635.GA2545@ip68-4-255-84.oc.oc.cox.net><3FF2A661.5070408@togami.com><20040101031652.GA7416@devserv.devel.redhat.com><33173.216.166.133.165.1073011407.squirrel@webtest.cs.montana.edu><3FF4ECB8.7060204@togami.com><20040102120817.GE22959@neu.nirvana><20040102204445.2dd3864a.ms-nospam-0306@arcor.de><00f201c3d22a$9f791d80$022ca8c0@OPTIMUS> <20040103232126.515a6f5b.ms-nospam-0306@arcor.de> <007a01c3d2c9$0125cda0$022ca8c0@OPTIMUS> Message-ID: I found that rh80 required the upgrade from the rpm.org website. I did not change the version of rpm, just the patch level. "RPM Hangs" do not occur any more. When the RPM Hang occurs under RH80, it leaves three __db* files in a directory under /var If these files are removed and then the rpm database rebuilt, even the standard RH80 rpm can be used a few more times before it hangs again. bug On Sun, 4 Jan 2004, Ingo T. Storm wrote: > > >I don't refer to RPM on rh7x, because I don't see any problems > >there. That "RPM hangs" problem was introduced with rh80 > > I apologize to you, too. I have never used rh80 or rh9 in production, went > straight to EL. Of course my reasoning only applies (fully) to the really > old stuff. > > Ingo > From tanner at real-time.com Sun Jan 4 20:29:38 2004 From: tanner at real-time.com (Bob Tanner) Date: Sun, 4 Jan 2004 14:29:38 -0600 Subject: Please follow the KISS principle In-Reply-To: <1072832101.10379.5.camel@binkley> References: <3FF21B03.4020806@sohanet.de> <1072832101.10379.5.camel@binkley> Message-ID: <200401041429.38098@join.TCLUG.at.www.mn-linux.org> On Tuesday 30 December 2003 6:55 pm, seth vidal wrote > > after reading Warrens drafts and the answers I'm getting the impressions > > that this projects start way to complicated. Let us just follow the KISS > > principle (keep it simple stupid). As Fedora-Legacy only exists to > > handle security updates and is not intended to introduce new features to > > EOLed distributions we should really focus on the essentials. For me > > this means NO rpm upgrades. Just use the infrastructure and tools that > > Red Hat gave us with their distributions. > > I'm thinking a good way for people to accomplish things is just to do > them. Release soon, release often. :-) I think an "extreme programming" style to legacy would be much more effective. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Sun Jan 4 20:39:34 2004 From: tanner at real-time.com (Bob Tanner) Date: Sun, 4 Jan 2004 14:39:34 -0600 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF4052F.4070608@togami.com> References: <3FF4052F.4070608@togami.com> Message-ID: <200401041439.38634@join.TCLUG.at.www.mn-linux.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 01 January 2004 5:31 am, Warren Togami wrote: > After I am done copying packages into the repository, there is only one > thing blocking the launch of Legacy for RH7.2 and RH7.3: We need > maintainers for apt and/or yum clients for these older distributions. > You must submit your packages to fedora.us QA just like any other > package currently in the QA queue. Use keywords like "rh72, QA, > stable". It seems that we agreed to NOT upgrade RPM for RH7.x, so apt > and yum-1.x are what we will be using. The kde-redhat project has apt for rh73. I'll speak for Rex :-) and say we can maintain the apt version for rh73. I'll also step up and say I'll maintain apt for rh72 I've seen requests for apt for rh73, you can get it from http://kde-redhat.sf.net to start the bootstrap process. We also have a (slow) bugzilla at http://bugzilla.kde-redhat.org If I remember right, the rh73 version of apt is just a back "port" and some patches of fedora.us' apt, so when Rex feels like it, it should easily :-) pass the QA process. - -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/+HoKfPGnCSzBsogRAqErAJ9a9yUCRRtKKc7W6whvDHDgvUeDHQCgmYRo lX9iOez2K83y3r4OCF9GoEo= =P2EN -----END PGP SIGNATURE----- From tanner at real-time.com Sun Jan 4 20:41:38 2004 From: tanner at real-time.com (Bob Tanner) Date: Sun, 4 Jan 2004 14:41:38 -0600 Subject: Preparing 7.2 and 7.3 now... In-Reply-To: <3FF559C2.7020506@togami.com> References: <3FF559C2.7020506@togami.com> Message-ID: <200401041441.38018@join.TCLUG.at.www.mn-linux.org> On Friday 02 January 2004 5:45 am, Warren Togami wrote: > We need people to work on and submit apt and yum packages for RH7.2 and > RH7.3 to fedora.us QA as specified here: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > Until people do so, your only choice is to get apt or yum from > FreshRPMS.net, and reconfigure it to use Fedora Legacy. Not true, kde-redhat's fedora-subproject has a back "port" of fedora.us's apt. See http://kde-redhat.sf.net for details. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From warren at togami.com Sun Jan 4 22:32:19 2004 From: warren at togami.com (Warren Togami) Date: Sun, 04 Jan 2004 12:32:19 -1000 Subject: Busy in #fedora-legacy Message-ID: <3FF89473.7070603@togami.com> Please join us in #fedora-legacy if you want to help out with several necessary tasks. We're currently discussing apt and yum preparation and submitting patches for https://bugzilla.fedora.us/show_bug.cgi?id=1174 We need a similar Bugzilla report opened for RH7.x legacy yum. Warren From warren at togami.com Sun Jan 4 23:56:12 2004 From: warren at togami.com (Warren Togami) Date: Sun, 04 Jan 2004 13:56:12 -1000 Subject: Busy in #fedora-legacy In-Reply-To: <3FF89473.7070603@togami.com> References: <3FF89473.7070603@togami.com> Message-ID: <3FF8A81C.8040303@togami.com> Warren Togami wrote: > Please join us in #fedora-legacy if you want to help out with several > necessary tasks. We're currently discussing apt and yum preparation and > submitting patches for https://bugzilla.fedora.us/show_bug.cgi?id=1174 > We need a similar Bugzilla report opened for RH7.x legacy yum. > > Warren https://bugzilla.fedora.us/show_bug.cgi?id=1175 fedora-rpmdevtools for RH7.x.... it seems some fixing Ville, do you want to attempt to keep these sources in sync with the newer distribution fedora-rpmdevtools with conditionals, or fork it? Jef Spaleta is working on yum-1.x for Legacy at the moment. I need to lie down. Ugh... Warren From warren at togami.com Mon Jan 5 02:19:43 2004 From: warren at togami.com (Warren Togami) Date: Sun, 04 Jan 2004 16:19:43 -1000 Subject: Busy in #fedora-legacy In-Reply-To: <3FF8A81C.8040303@togami.com> References: <3FF89473.7070603@togami.com> <3FF8A81C.8040303@togami.com> Message-ID: <3FF8C9BF.2000305@togami.com> https://bugzilla.fedora.us/show_bug.cgi?id=1176 Jef Spaleta submitted yum for Fedora Legacy From sheltren at cs.ucsb.edu Mon Jan 5 03:52:27 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 04 Jan 2004 19:52:27 -0800 Subject: Busy in #fedora-legacy In-Reply-To: <3FF8C9BF.2000305@togami.com> References: <3FF89473.7070603@togami.com> <3FF8A81C.8040303@togami.com> <3FF8C9BF.2000305@togami.com> Message-ID: <1073274747.10419.46.camel@avalanche> So this is just the same yum available from the yum site packaged with a new yum.conf that points to the FL mirrors, or is there something else changed? Thanks, Jeff On Sun, 2004-01-04 at 18:19, Warren Togami wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=1176 > Jef Spaleta submitted yum for Fedora Legacy > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From skvidal at phy.duke.edu Mon Jan 5 04:11:52 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 04 Jan 2004 23:11:52 -0500 Subject: Busy in #fedora-legacy In-Reply-To: <1073274747.10419.46.camel@avalanche> References: <3FF89473.7070603@togami.com> <3FF8A81C.8040303@togami.com> <3FF8C9BF.2000305@togami.com> <1073274747.10419.46.camel@avalanche> Message-ID: <1073275912.8918.16.camel@binkley> On Sun, 2004-01-04 at 22:52, Jeff Sheltren wrote: > So this is just the same yum available from the yum site packaged with a > new yum.conf that points to the FL mirrors, or is there something else > changed? > No other changes. Though I realize now there are a number of patches applied to the 1.0.X branch that should probably show up in a release. -sv From jpdalbec at ysu.edu Mon Jan 5 13:56:56 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 05 Jan 2004 08:56:56 -0500 Subject: apt/yum configuration? Message-ID: <3FF96D28.6040600@ysu.edu> How do I configure apt and yum (from freshrpms.net) for fedora legacy? Thanks, John Dalbec From sven at timegate.de Mon Jan 5 14:06:51 2004 From: sven at timegate.de (Sven Hoexter) Date: Mon, 5 Jan 2004 15:06:51 +0100 Subject: Round 1: Local root exploit in the Kernel Message-ID: <20040105140651.GB924@sven.home.hoaxter.de> Ok guys, time to try if you are prepared: http://isec.pl/vulnerabilities/isec-0013-mremap.txt And a patch: http://lkml.org/lkml/diff/2004/1/5/74/1 Don't know if this patch is complete or not .... Have good day, Sven -- Revolution is not a dinner party, not an essay, nor a painting, nor a piece of embroidery; it cannot be advanced softly, gradually, carefully, considerately, respectfully, politely, plainly, and modestly. - Mao Zedong (Mao Tse-tung) From sven at timegate.de Mon Jan 5 14:17:08 2004 From: sven at timegate.de (Sven Hoexter) Date: Mon, 5 Jan 2004 15:17:08 +0100 Subject: Round 1: Local root exploit in the Kernel In-Reply-To: <20040105140651.GB924@sven.home.hoaxter.de> References: <20040105140651.GB924@sven.home.hoaxter.de> Message-ID: <20040105141708.GC924@sven.home.hoaxter.de> On Mon, Jan 05, 2004 at 03:06:51PM +0100, Sven Hoexter wrote: > Ok guys, > time to try if you are prepared: > http://isec.pl/vulnerabilities/isec-0013-mremap.txt > > And a patch: > http://lkml.org/lkml/diff/2004/1/5/74/1 > > Don't know if this patch is complete or not .... Hm ok RH provides fixed packages ... https://rhn.redhat.com/errata/RHSA-2003-417.html Sven -- Revolution is not a dinner party, not an essay, nor a painting, nor a piece of embroidery; it cannot be advanced softly, gradually, carefully, considerately, respectfully, politely, plainly, and modestly. - Mao Zedong (Mao Tse-tung) From Axel.Thimm at physik.fu-berlin.de Mon Jan 5 14:21:02 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 5 Jan 2004 15:21:02 +0100 Subject: fwd: [RHSA-2003:417-01] Updated kernel resolves security vulnerability Message-ID: <20040105142102.GF22558@neu.nirvana> Here is the first Legacy related security update kindly provided by Red Hat itself. ----- Forwarded message from bugzilla at redhat.com ----- Subject: [RHSA-2003:417-01] Updated kernel resolves security vulnerability From: bugzilla at redhat.com To: redhat-watch-list at redhat.com, bugtraq at securityfocus.com, full-disclosure at lists.netsys.com Cc: Date: Mon, 5 Jan 2004 07:54 -0500 --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated kernel resolves security vulnerability Advisory ID: RHSA-2003:417-01 Issue date: 2004-01-05 Updated on: 2004-01-05 Product: Red Hat Linux Keywords: Cross references: Obsoletes: CVE Names: CAN-2003-0984 CAN-2003-0985 --------------------------------------------------------------------- 1. Topic: Updated kernel packages are now available that fix a security vulnerability which may allow local users to gain root privileges. 2. Relevant releases/architectures: Red Hat Linux 7.1 - athlon, i386, i586, i686 Red Hat Linux 7.2 - athlon, i386, i586, i686 Red Hat Linux 7.3 - athlon, i386, i586, i686 Red Hat Linux 8.0 - athlon, i386, i586, i686 Red Hat Linux 9 - athlon, i386, i586, i686 3. Problem description: The Linux kernel handles the basic functions of the operating system. Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux kernel versions 2.4.23 and previous which may allow a local attacker to gain root privileges. No exploit is currently available; however, it is believed that this issue is exploitable (although not trivially.) The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0985 to this issue. All users are advised to upgrade to these errata packages, which contain a backported security patch that corrects this issue. Red Hat would like to thank Paul Starzetz from ISEC for disclosing this issue as well as Andrea Arcangeli and Solar Designer for working on the patch. These packages also contain a fix for a minor information leak in the real time clock (rtc) routines. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0984 to this issue. We have provided kernel updates for Red Hat Linux 7.1-8.0 with this advisory as these were prepared by us prior to December 31 2003. Please note that Red Hat Linux 7.1, 7.2, 7.3, and 8.0 have reached their end of life for errata support and no further errata will be issued for those distributions. 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 Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. If up2date fails to connect to Red Hat Network due to SSL Certificate Errors, you need to install a version of the up2date client with an updated certificate. The latest version of up2date is available from the Red Hat FTP site and may also be downloaded directly from the RHN website: https://rhn.redhat.com/help/latest-up2date.pxt 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 90338 - (TUX)password incorrectly parsed + patch to fix the problem 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm athlon: ftp://updates.redhat.com/7.1/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ftp://updates.redhat.com/7.1/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/kernel-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm i586: ftp://updates.redhat.com/7.1/en/os/i586/kernel-2.4.20-28.7.i586.rpm ftp://updates.redhat.com/7.1/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm i686: ftp://updates.redhat.com/7.1/en/os/i686/kernel-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.1/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.1/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm athlon: ftp://updates.redhat.com/7.2/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ftp://updates.redhat.com/7.2/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/kernel-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm i586: ftp://updates.redhat.com/7.2/en/os/i586/kernel-2.4.20-28.7.i586.rpm ftp://updates.redhat.com/7.2/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm i686: ftp://updates.redhat.com/7.2/en/os/i686/kernel-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.2/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.2/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm athlon: ftp://updates.redhat.com/7.3/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ftp://updates.redhat.com/7.3/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/kernel-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm i586: ftp://updates.redhat.com/7.3/en/os/i586/kernel-2.4.20-28.7.i586.rpm ftp://updates.redhat.com/7.3/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm i686: ftp://updates.redhat.com/7.3/en/os/i686/kernel-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.3/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm ftp://updates.redhat.com/7.3/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/kernel-2.4.20-28.8.src.rpm athlon: ftp://updates.redhat.com/8.0/en/os/athlon/kernel-2.4.20-28.8.athlon.rpm ftp://updates.redhat.com/8.0/en/os/athlon/kernel-smp-2.4.20-28.8.athlon.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/kernel-2.4.20-28.8.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/kernel-source-2.4.20-28.8.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/kernel-doc-2.4.20-28.8.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/kernel-BOOT-2.4.20-28.8.i386.rpm i586: ftp://updates.redhat.com/8.0/en/os/i586/kernel-2.4.20-28.8.i586.rpm ftp://updates.redhat.com/8.0/en/os/i586/kernel-smp-2.4.20-28.8.i586.rpm i686: ftp://updates.redhat.com/8.0/en/os/i686/kernel-2.4.20-28.8.i686.rpm ftp://updates.redhat.com/8.0/en/os/i686/kernel-smp-2.4.20-28.8.i686.rpm ftp://updates.redhat.com/8.0/en/os/i686/kernel-bigmem-2.4.20-28.8.i686.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/kernel-2.4.20-28.9.src.rpm athlon: ftp://updates.redhat.com/9/en/os/athlon/kernel-2.4.20-28.9.athlon.rpm ftp://updates.redhat.com/9/en/os/athlon/kernel-smp-2.4.20-28.9.athlon.rpm i386: ftp://updates.redhat.com/9/en/os/i386/kernel-2.4.20-28.9.i386.rpm ftp://updates.redhat.com/9/en/os/i386/kernel-source-2.4.20-28.9.i386.rpm ftp://updates.redhat.com/9/en/os/i386/kernel-doc-2.4.20-28.9.i386.rpm ftp://updates.redhat.com/9/en/os/i386/kernel-BOOT-2.4.20-28.9.i386.rpm i586: ftp://updates.redhat.com/9/en/os/i586/kernel-2.4.20-28.9.i586.rpm ftp://updates.redhat.com/9/en/os/i586/kernel-smp-2.4.20-28.9.i586.rpm i686: ftp://updates.redhat.com/9/en/os/i686/kernel-2.4.20-28.9.i686.rpm ftp://updates.redhat.com/9/en/os/i686/kernel-smp-2.4.20-28.9.i686.rpm ftp://updates.redhat.com/9/en/os/i686/kernel-bigmem-2.4.20-28.9.i686.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 6f37a0c884be50f702665dd418e7d8a5 7.1/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm 85dabb948243fcd96fed1946217b3259 7.1/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ba80fcbe3237ece886506446413d6330 7.1/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm a4b2cd2ad6acb98c045a0644add55ef8 7.1/en/os/i386/kernel-2.4.20-28.7.i386.rpm 46cbf5df2050e923343be59c26eb5714 7.1/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm 9e64a9b15edc09d4a0f75513445f4021 7.1/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm dbc9c6aa900467f4182306545d3bed81 7.1/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm 46325c861ee83b2f679b9f8563f2e441 7.1/en/os/i586/kernel-2.4.20-28.7.i586.rpm 51ede5686dc0997c76a14d523e057e67 7.1/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm ab86ca21757966e2f49d58438b26253a 7.1/en/os/i686/kernel-2.4.20-28.7.i686.rpm 78229375349f57c62f0f1837770cc3f0 7.1/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm 4321ad444747e8e3ebf6e7576b08d6db 7.1/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm 6f37a0c884be50f702665dd418e7d8a5 7.2/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm 85dabb948243fcd96fed1946217b3259 7.2/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ba80fcbe3237ece886506446413d6330 7.2/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm a4b2cd2ad6acb98c045a0644add55ef8 7.2/en/os/i386/kernel-2.4.20-28.7.i386.rpm 46cbf5df2050e923343be59c26eb5714 7.2/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm 9e64a9b15edc09d4a0f75513445f4021 7.2/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm dbc9c6aa900467f4182306545d3bed81 7.2/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm 46325c861ee83b2f679b9f8563f2e441 7.2/en/os/i586/kernel-2.4.20-28.7.i586.rpm 51ede5686dc0997c76a14d523e057e67 7.2/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm ab86ca21757966e2f49d58438b26253a 7.2/en/os/i686/kernel-2.4.20-28.7.i686.rpm 78229375349f57c62f0f1837770cc3f0 7.2/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm 4321ad444747e8e3ebf6e7576b08d6db 7.2/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm 6f37a0c884be50f702665dd418e7d8a5 7.3/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm 85dabb948243fcd96fed1946217b3259 7.3/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ba80fcbe3237ece886506446413d6330 7.3/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm a4b2cd2ad6acb98c045a0644add55ef8 7.3/en/os/i386/kernel-2.4.20-28.7.i386.rpm 46cbf5df2050e923343be59c26eb5714 7.3/en/os/i386/kernel-BOOT-2.4.20-28.7.i386.rpm 9e64a9b15edc09d4a0f75513445f4021 7.3/en/os/i386/kernel-doc-2.4.20-28.7.i386.rpm dbc9c6aa900467f4182306545d3bed81 7.3/en/os/i386/kernel-source-2.4.20-28.7.i386.rpm 46325c861ee83b2f679b9f8563f2e441 7.3/en/os/i586/kernel-2.4.20-28.7.i586.rpm 51ede5686dc0997c76a14d523e057e67 7.3/en/os/i586/kernel-smp-2.4.20-28.7.i586.rpm ab86ca21757966e2f49d58438b26253a 7.3/en/os/i686/kernel-2.4.20-28.7.i686.rpm 78229375349f57c62f0f1837770cc3f0 7.3/en/os/i686/kernel-bigmem-2.4.20-28.7.i686.rpm 4321ad444747e8e3ebf6e7576b08d6db 7.3/en/os/i686/kernel-smp-2.4.20-28.7.i686.rpm 7ff4997770e18fd8dfa94dde6ccd9f05 8.0/en/os/SRPMS/kernel-2.4.20-28.8.src.rpm 69096d7bf580f241c2774a75d19a4f6b 8.0/en/os/athlon/kernel-2.4.20-28.8.athlon.rpm 07cc69196376c7cbcad2c4a93aff0be0 8.0/en/os/athlon/kernel-smp-2.4.20-28.8.athlon.rpm a97ba9aea863b5b49f26259f105e8d8f 8.0/en/os/i386/kernel-2.4.20-28.8.i386.rpm ab4eac1f8c255a9d70808469e46e918c 8.0/en/os/i386/kernel-BOOT-2.4.20-28.8.i386.rpm 210eb290286bb696f94e9ebe5399d67e 8.0/en/os/i386/kernel-doc-2.4.20-28.8.i386.rpm 312b7e646dc4825617d3a9b485957c67 8.0/en/os/i386/kernel-source-2.4.20-28.8.i386.rpm 90ddcdf7660107c2e297bd2531b4a544 8.0/en/os/i586/kernel-2.4.20-28.8.i586.rpm 25692d7064ab7bc55a17c53ee24e9d3d 8.0/en/os/i586/kernel-smp-2.4.20-28.8.i586.rpm 91ca2b2685cf6c5e0b8d1b9043865bea 8.0/en/os/i686/kernel-2.4.20-28.8.i686.rpm 3fecc24946697e5dd0428df38cbb2198 8.0/en/os/i686/kernel-bigmem-2.4.20-28.8.i686.rpm 40d954506e1b0ad60c7f150d76872ec5 8.0/en/os/i686/kernel-smp-2.4.20-28.8.i686.rpm 5eb1ef7c29f3bd5e3afb9c41d5f688e5 9/en/os/SRPMS/kernel-2.4.20-28.9.src.rpm 954a8afbe2216769a4aaa5b0b597612f 9/en/os/athlon/kernel-2.4.20-28.9.athlon.rpm 198dfae0a67d9aa91f367e90e1a264c7 9/en/os/athlon/kernel-smp-2.4.20-28.9.athlon.rpm a398b7f0a741ab95ab0b66929c48dc95 9/en/os/i386/kernel-2.4.20-28.9.i386.rpm e394c681c64e22a94ed22dd8a510aad0 9/en/os/i386/kernel-BOOT-2.4.20-28.9.i386.rpm 8355d266e3c354e97099add60ea25331 9/en/os/i386/kernel-doc-2.4.20-28.9.i386.rpm 12ad6c3ad16ddee2ad6c3ba579005a9d 9/en/os/i386/kernel-source-2.4.20-28.9.i386.rpm 0047dac37b4f888e53b5b304524b795d 9/en/os/i586/kernel-2.4.20-28.9.i586.rpm 08a3391dcb7f5532310ce234d2570bd0 9/en/os/i586/kernel-smp-2.4.20-28.9.i586.rpm 6cdbe7002a6834dc1aa27cc5f47ba5a7 9/en/os/i686/kernel-2.4.20-28.9.i686.rpm 3788274eba272ef23704bec4cb19e4af 9/en/os/i686/kernel-bigmem-2.4.20-28.9.i686.rpm d9fe2e46b08f596e19a49ae724d2db5a 9/en/os/i686/kernel-smp-2.4.20-28.9.i686.rpm These packages are GPG signed by Red Hat for security. Our key is available from https://www.redhat.com/security/keys.html 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 md5sum with the following command: md5sum 8. References: http://www.securityfocus.com/bid/9154/discussion/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0984 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0985 9. Contact: The Red Hat security contact is . More contact details at https://www.redhat.com/solutions/security/news/contact.html Copyright 2003 Red Hat, Inc. _______________________________________________ Redhat-watch-list mailing list To unsubscribe, visit: https://www.redhat.com/mailman/listinfo/redhat-watch-list ----- End forwarded message ----- -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From green at r8.dion.ne.jp Mon Jan 5 14:29:10 2004 From: green at r8.dion.ne.jp (Green) Date: Mon, 5 Jan 2004 23:29:10 +0900 Subject: apt/yum configuration? In-Reply-To: <3FF96D28.6040600@ysu.edu> References: <3FF96D28.6040600@ysu.edu> Message-ID: <20040105232910.78b55943.green@r8.dion.ne.jp> On Mon, 05 Jan 2004 08:56:56 -0500 John Dalbec wrote: > How do I configure apt and yum (from freshrpms.net) for fedora legacy? > Thanks, > John Dalbec It seems to me that it is NOT recommended to use apt and yum from freshrpms.net for fedora repository, because of "Repository Mixing problems". Instead, use apt and yum "from fedora.us" for fedora legacy. Am I correct? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 5 14:40:04 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Jan 2004 15:40:04 +0100 Subject: apt/yum configuration? In-Reply-To: <20040105232910.78b55943.green@r8.dion.ne.jp> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> Message-ID: <20040105154004.1934792e@python.freshrpms.net> Green wrote : > On Mon, 05 Jan 2004 08:56:56 -0500 > John Dalbec wrote: > > > How do I configure apt and yum (from freshrpms.net) for fedora legacy? > > Thanks, > > John Dalbec > > It seems to me that it is NOT recommended to use apt and yum from > freshrpms.net for fedora repository, because of "Repository Mixing > problems". > > Instead, use apt and yum "from fedora.us" for fedora legacy. Am I > correct? Hum. I would have preferred to keep "Fedora Legacy" and "fedora.us" separated at least as much as "Fedora Legacy" and "freshrpms.net" :-/ Oh, well... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl Load : 1.05 1.11 1.46 From skvidal at phy.duke.edu Mon Jan 5 14:45:53 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 09:45:53 -0500 Subject: apt/yum configuration? In-Reply-To: <20040105154004.1934792e@python.freshrpms.net> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> Message-ID: <1073313953.6652.9.camel@opus> On Mon, 2004-01-05 at 09:40, Matthias Saou wrote: > Green wrote : > > > On Mon, 05 Jan 2004 08:56:56 -0500 > > John Dalbec wrote: > > > > > How do I configure apt and yum (from freshrpms.net) for fedora legacy? > > > Thanks, > > > John Dalbec > > > > It seems to me that it is NOT recommended to use apt and yum from > > freshrpms.net for fedora repository, because of "Repository Mixing > > problems". > > > > Instead, use apt and yum "from fedora.us" for fedora legacy. Am I > > correct? > > Hum. I would have preferred to keep "Fedora Legacy" and "fedora.us" > separated at least as much as "Fedora Legacy" and "freshrpms.net" :-/ > I can't speak for apt, but the yum in fedora legacy is identical to the yum at freshrpms.net except for the default config file entries. I dunno how much that's worth, but I don't think there are any real requirements on yum from fedora legacy that have anything to do with fedora.us -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 5 15:12:44 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Jan 2004 16:12:44 +0100 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <1073313953.6652.9.camel@opus> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> Message-ID: <20040105161244.6650d6d7@python.freshrpms.net> seth vidal wrote : > I can't speak for apt, but the yum in fedora legacy is identical to the > yum at freshrpms.net except for the default config file entries. > > I dunno how much that's worth, but I don't think there are any real > requirements on yum from fedora legacy that have anything to do with > fedora.us Well, partly it doesn't but partly it does (it seems to me after some weeks of absence) : It looks like it was decided to include/merge all the legacy packages into the download.fedora.us tree (btw, the link on the www.fedoralegacy.org web page is missing http://), so the recommended apt and yum packages for using "Fedora Legacy" will in fact be downloaded from fedora.us, although in the "legacy" module, but IMHO this might still be confusing to users. Please do correct me if I'm wrong. I would have really preferred to have all the packages produced by the Fedora Legacy project primarily distributed in a simple tree, similar to the existing Red Hat one, and preferably from a fedoralegacy.org host : /pub/fedoralegacy/redhat///*.rpm With eventually variations in the tree, like adding "linux" for consistency with the Red Hat trees or inserting "updates" at one point. Anyone could then easily sync the files and include them in their apt, yum or whatever modules (say at fedora.us, freshrpms.net, inside a local Red Hat Linux mirror etc.). Maybe this is done, but is seems not, as I understand fedora.us will probably become Fedora Legacy... but before that, fedora.us is going to become Fedora Extras... confused enough yet? :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl Load : 0.82 0.72 0.73 From skvidal at phy.duke.edu Mon Jan 5 15:38:52 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 10:38:52 -0500 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <20040105161244.6650d6d7@python.freshrpms.net> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> Message-ID: <1073317132.6652.25.camel@opus> > Well, partly it doesn't but partly it does (it seems to me after some weeks > of absence) : It looks like it was decided to include/merge all the legacy > packages into the download.fedora.us tree (btw, the link on the > www.fedoralegacy.org web page is missing http://), so the recommended apt > and yum packages for using "Fedora Legacy" will in fact be downloaded from > fedora.us, although in the "legacy" module, but IMHO this might still be > confusing to users. Please do correct me if I'm wrong. You see, now I'm confused :) I thought all the legacy stuff was just: http://download.fedora.us/fedora/redhat/$releasever/i386/RPMS.legacy/ So all someone needs to do is add that to their yum.conf as a baseurl and they get the packages in there. does that explain it or am I out in left field. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 5 15:55:35 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Jan 2004 16:55:35 +0100 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <1073317132.6652.25.camel@opus> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> Message-ID: <20040105165535.22994e2c@python.freshrpms.net> seth vidal wrote : > > Well, partly it doesn't but partly it does (it seems to me after some > > weeks of absence) : It looks like it was decided to include/merge all > > the legacy packages into the download.fedora.us tree (btw, the link on > > the www.fedoralegacy.org web page is missing http://), so the > > recommended apt and yum packages for using "Fedora Legacy" will in fact > > be downloaded from fedora.us, although in the "legacy" module, but IMHO > > this might still be confusing to users. Please do correct me if I'm > > wrong. > > You see, now I'm confused :) > > I thought all the legacy stuff was just: > > http://download.fedora.us/fedora/redhat/$releasever/i386/RPMS.legacy/ > > So all someone needs to do is add that to their yum.conf as a baseurl > and they get the packages in there. > > does that explain it or am I out in left field. Well, you're right, but in order to have all the Legacy packages mirrored for the various supported distributions, and without mirroring all the other fedora.us packages, things won't be as easy as they could be. >From what I had understood initially, many people (including me) expected a clean and simple way to fetch the packages and merge them with (or include them alongside) the no-longer-updated official updates, and unless I'm mistaken, it's unfortunately not currently the case. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl Load : 1.08 1.22 1.16 From skvidal at phy.duke.edu Mon Jan 5 15:59:23 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 10:59:23 -0500 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <20040105165535.22994e2c@python.freshrpms.net> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> Message-ID: <1073318363.6652.30.camel@opus> > Well, you're right, but in order to have all the Legacy packages mirrored > for the various supported distributions, and without mirroring all the > other fedora.us packages, things won't be as easy as they could be. > > >From what I had understood initially, many people (including me) expected a > clean and simple way to fetch the packages and merge them with (or include > them alongside) the no-longer-updated official updates, and unless I'm > mistaken, it's unfortunately not currently the case. I'm confused again. Can't you just rsync: download.fedora.us/fedora/redhat/*/i386/RPMS.legacy/ ? Then wouldn't you get them all? Or do you mean for ftp-downloading? -sv From jkeating at j2solutions.net Mon Jan 5 16:01:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 5 Jan 2004 08:01:51 -0800 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <20040105165535.22994e2c@python.freshrpms.net> References: <3FF96D28.6040600@ysu.edu> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> Message-ID: <200401050801.51279.jkeating@j2solutions.net> On Monday 05 January 2004 07:55, Matthias Saou wrote: > Well, you're right, but in order to have all the Legacy packages > mirrored for the various supported distributions, and without > mirroring all the other fedora.us packages, things won't be as easy > as they could be. > > From what I had understood initially, many people (including me) > expected a clean and simple way to fetch the packages and merge them > with (or include them alongside) the no-longer-updated official > updates, and unless I'm mistaken, it's unfortunately not currently > the case. It's still my intention to create a master mirror that pushes out the content in a simple tree just like you wanted. Fedora.us will serve as one of the primary download sites for end users. Warren and I will work on getting his servers populated in the right way from Legacy's master server, but for separation needs and simplicity I do want to maintain a master mirror server that has Legacy content only. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 5 16:09:09 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Jan 2004 17:09:09 +0100 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <200401050801.51279.jkeating@j2solutions.net> References: <3FF96D28.6040600@ysu.edu> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> <200401050801.51279.jkeating@j2solutions.net> Message-ID: <20040105170909.53fa6d91@python.freshrpms.net> Jesse Keating wrote : > On Monday 05 January 2004 07:55, Matthias Saou wrote: > > Well, you're right, but in order to have all the Legacy packages > > mirrored for the various supported distributions, and without > > mirroring all the other fedora.us packages, things won't be as easy > > as they could be. > > > > From what I had understood initially, many people (including me) > > expected a clean and simple way to fetch the packages and merge them > > with (or include them alongside) the no-longer-updated official > > updates, and unless I'm mistaken, it's unfortunately not currently > > the case. > > It's still my intention to create a master mirror that pushes out the > content in a simple tree just like you wanted. Fedora.us will serve as > one of the primary download sites for end users. Warren and I will > work on getting his servers populated in the right way from Legacy's > master server, but for separation needs and simplicity I do want to > maintain a master mirror server that has Legacy content only. Perfect, then :-) You can also count on ayo.freshrpms.net and its mirrors to also include Fedora Legacy packages. Seth : Sorry for getting you so confused ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl Load : 0.43 0.67 0.78 From cra at WPI.EDU Mon Jan 5 16:38:17 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 5 Jan 2004 11:38:17 -0500 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <1073318363.6652.30.camel@opus> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> <1073318363.6652.30.camel@opus> Message-ID: <20040105163817.GA6778@angus.ind.WPI.EDU> On Mon, Jan 05, 2004 at 10:59:23AM -0500, seth vidal wrote: > > Well, you're right, but in order to have all the Legacy packages mirrored > > for the various supported distributions, and without mirroring all the > > other fedora.us packages, things won't be as easy as they could be. > > > > >From what I had understood initially, many people (including me) expected a > > clean and simple way to fetch the packages and merge them with (or include > > them alongside) the no-longer-updated official updates, and unless I'm > > mistaken, it's unfortunately not currently the case. > > I'm confused again. Can't you just rsync: > > download.fedora.us/fedora/redhat/*/i386/RPMS.legacy/ RPMS.legacy will contain only auto-updating tools and their requirements related to Fedora Legacy, such as a newer RPM for RHL 8.0 and 9, apt and yum. RPMS.updates contains all existing RHL updates + future Fedora Legacy updates packages. From whooperhsd3 at earthlink.net Mon Jan 5 16:40:49 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Mon, 5 Jan 2004 11:40:49 -0500 (EST) Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <1073318363.6652.30.camel@opus> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> <1073318363.6652.30.camel@opus> Message-ID: <2608.12.29.16.103.1073320849.squirrel@12.29.16.103> seth vidal said: > >> Well, you're right, but in order to have all the Legacy packages >> mirrored >> for the various supported distributions, and without mirroring all the >> other fedora.us packages, things won't be as easy as they could be. >> >> >From what I had understood initially, many people (including me) >> expected a >> clean and simple way to fetch the packages and merge them with (or >> include >> them alongside) the no-longer-updated official updates, and unless I'm >> mistaken, it's unfortunately not currently the case. > > I'm confused again. Can't you just rsync: > > download.fedora.us/fedora/redhat/*/i386/RPMS.legacy/ > > ? > > Then wouldn't you get them all? > > Or do you mean for ftp-downloading? I think the issue is that this requires another yum.conf entry. So you have one local repo for RH Errata up to EOL, then another for Fedora Legacy Errata. IIUC what Matthias is looking for was more of a "drop Fedora Legacy Errata into the existing local RH Errata repo". -- William Hooper From Axel.Thimm at physik.fu-berlin.de Mon Jan 5 16:52:54 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 5 Jan 2004 17:52:54 +0100 Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <20040105163817.GA6778@angus.ind.WPI.EDU> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> <1073318363.6652.30.camel@opus> <20040105163817.GA6778@angus.ind.WPI.EDU> Message-ID: <20040105165254.GD27421@neu.nirvana> On Mon, Jan 05, 2004 at 11:38:17AM -0500, Charles R. Anderson wrote: > On Mon, Jan 05, 2004 at 10:59:23AM -0500, seth vidal wrote: > > > Well, you're right, but in order to have all the Legacy packages mirrored > > > for the various supported distributions, and without mirroring all the > > > other fedora.us packages, things won't be as easy as they could be. > > > > > > >From what I had understood initially, many people (including me) expected a > > > clean and simple way to fetch the packages and merge them with (or include > > > them alongside) the no-longer-updated official updates, and unless I'm > > > mistaken, it's unfortunately not currently the case. > > > > I'm confused again. Can't you just rsync: > > > > download.fedora.us/fedora/redhat/*/i386/RPMS.legacy/ > > RPMS.legacy will contain only auto-updating tools and their > requirements related to Fedora Legacy, such as a newer RPM for RHL 8.0 > and 9, apt and yum. > > RPMS.updates contains all existing RHL updates + future Fedora Legacy > updates packages. That makes very much sense. OTOH this will confuse people. `Want to have Legacy updates? Then go get "updates" and optionally you may want to use "legacy", but the latter is not needed. But if you don't use "legacy" you will be unsupported by the Fedora Legacy team. But don't worry, you can still have "updates". Hey, why are you running away?' Maybe fedora.us should become Fedora Updates instead of Fedora Extras and Fedora Legacy? Or maybe all together? Confused? Once again? ;) Anyway I's also vote for a fedoralegacy.org repo not policy inflicted by "Repository non-mixing" statements. Matthias' layout seems very reasonable and can be setup in a matter of a few minutes. Try to keep legacy independent. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jan 5 19:34:15 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 05 Jan 2004 21:34:15 +0200 Subject: Busy in #fedora-legacy In-Reply-To: <3FF8A81C.8040303@togami.com> References: <3FF89473.7070603@togami.com> <3FF8A81C.8040303@togami.com> Message-ID: <1073331254.9121.204.camel@bobcat.mine.nu> On Mon, 2004-01-05 at 01:56, Warren Togami wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=1175 > fedora-rpmdevtools for RH7.x.... it seems some fixing > Ville, do you want to attempt to keep these sources in sync with the > newer distribution fedora-rpmdevtools with conditionals, or fork it? Depends on how large changes will be required, but in general I would like to avoid a fork if manageable otherwise. I don't have a 7.x box to test/develop with (or the time right now), but I guess the changes in scripts are doable (mostly rpm-python, I believe) and if we include the "distrel checking script" which has been proposed a couple of times, the specfile could be auto-conditionalized as well. From smoogen at lanl.gov Mon Jan 5 19:34:12 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 5 Jan 2004 12:34:12 -0700 (MST) Subject: RPM upgrade discussion In-Reply-To: <20031230112238.GB13067@neu.nirvana> Message-ID: On Tue, 30 Dec 2003, Axel Thimm wrote: >If this mail is too long: You probably don't want to upgrade rpm for >doing conservative, backported (security) bugfixes. Also my >recommendation would be to use Progeny's services, or go straight to >RHEL2/3, as I doubt that in two days legacy will be offering security >rpms. > >On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote: >> As we discussed earlier, Fedora Legacy will require an upgrade of rpm as >> a requirement for all users who choose to use our repository. It is >> quite clear that we agree upon the rpm upgrade for RH8 and RH9 due to >> the major stability problems associated with those versions. > >Personally I would also upgrade rpm (and in ATrpms' legacy support I >am doing so), but for the target group of legacy I would question this >issue for the following reasons: > >o Red Hat never made rpm.org's errata official for any reasons they > may have. I suggest asking why. Probably they do not consider the > rpm upgrades stable enough. This is a strong signal not to go that > way. If it is anything like when I worked there.. it is just plain orniriness on the part of some developers. The reasons for some of the version numbers of rpm and having Jeff backport a fix to some old version always seemed to be somewhere between 'can we make Jeff have an aneurism this week?' and 'this is how it is and I dont have to explain it to anyone'. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From warren at togami.com Mon Jan 5 20:42:33 2004 From: warren at togami.com (Warren Togami) Date: Mon, 05 Jan 2004 10:42:33 -1000 Subject: apt/yum configuration? In-Reply-To: <20040105154004.1934792e@python.freshrpms.net> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> Message-ID: <3FF9CC39.6000306@togami.com> Matthias Saou wrote: > > > Hum. I would have preferred to keep "Fedora Legacy" and "fedora.us" > separated at least as much as "Fedora Legacy" and "freshrpms.net" :-/ > > Oh, well... > Matthias > Given that Fedora Legacy's goal is only security patches for the old RH distributions, it isn't unreasonable that Legacy "updates" remains compatible with Matthias FreshRPMS add-ons. You may want to leave out Legacy's "legacy" channel though because that may conflict. Warren From ms-nospam-0306 at arcor.de Mon Jan 5 20:43:57 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 5 Jan 2004 21:43:57 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 Message-ID: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> Forwarding this so more people are aware of it: [...] Begin forwarded message: Date: Mon, 5 Jan 2004 14:19:33 -0500 From: bugzilla at redhat.com Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 davej at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |WONTFIX Status|ON_QA |CLOSED ------- Additional Comments From davej at redhat.com 2004-01-05 14:19 ------- Due to an oversight, Patch5040 isn't applied. Adding a .. %patch5040 -p1 to line 1090 or so and rebuilding from the SRPM will fix this. I'll fix this for RHL9, but as RHL7/8 are now EOL, we won't be doing further updates, sorry.. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- From warren at togami.com Mon Jan 5 20:47:02 2004 From: warren at togami.com (Warren Togami) Date: Mon, 05 Jan 2004 10:47:02 -1000 Subject: Primary Legacy distribution In-Reply-To: <20040105165254.GD27421@neu.nirvana> References: <3FF96D28.6040600@ysu.edu> <20040105232910.78b55943.green@r8.dion.ne.jp> <20040105154004.1934792e@python.freshrpms.net> <1073313953.6652.9.camel@opus> <20040105161244.6650d6d7@python.freshrpms.net> <1073317132.6652.25.camel@opus> <20040105165535.22994e2c@python.freshrpms.net> <1073318363.6652.30.camel@opus> <20040105163817.GA6778@angus.ind.WPI.EDU> <20040105165254.GD27421@neu.nirvana> Message-ID: <3FF9CD46.5030207@togami.com> Axel Thimm wrote: > > That makes very much sense. > > OTOH this will confuse people. `Want to have Legacy updates? Then go > get "updates" and optionally you may want to use "legacy", but the > latter is not needed. But if you don't use "legacy" you will be > unsupported by the Fedora Legacy team. But don't worry, you can still > have "updates". Hey, why are you running away?' > > Maybe fedora.us should become Fedora Updates instead of Fedora Extras > and Fedora Legacy? Or maybe all together? > > Confused? Once again? ;) > > Anyway I's also vote for a fedoralegacy.org repo not policy inflicted > by "Repository non-mixing" statements. Matthias' layout seems very > reasonable and can be setup in a matter of a few minutes. > > Try to keep legacy independent. fedoralegacy.org has no need to warn against interoperability, as long as you avoid the "legacy" channel. "updates" can be mirrored in many different places that previously published updates, including download.fedora.us and freshrpms trees. We all win. Warren From warren at togami.com Mon Jan 5 20:51:55 2004 From: warren at togami.com (Warren Togami) Date: Mon, 05 Jan 2004 10:51:55 -1000 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> Message-ID: <3FF9CE6B.9060702@togami.com> Michael Schwendt wrote: > Forwarding this so more people are aware of it: > > [...] > > Begin forwarded message: > > Date: Mon, 5 Jan 2004 14:19:33 -0500 > From: bugzilla at redhat.com > Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 > > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > davej at redhat.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution| |WONTFIX > Status|ON_QA |CLOSED > > > > > ------- Additional Comments From davej at redhat.com 2004-01-05 14:19 ------- > Due to an oversight, Patch5040 isn't applied. > Adding a .. > > %patch5040 -p1 > > to line 1090 or so and rebuilding from the SRPM will fix this. > I'll fix this for RHL9, but as RHL7/8 are now EOL, we won't be doing > further updates, sorry.. Since this is being fixed in RH9, I vote that we should do the same for older distributions. We should wait until we see the official RH9 update and do exactly the same to the older distributions. Warren From dennis at ausil.us Mon Jan 5 21:05:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 6 Jan 2004 07:05:40 +1000 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <3FF9CE6B.9060702@togami.com> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <3FF9CE6B.9060702@togami.com> Message-ID: <200401060705.46688.dennis@ausil.us> Once upon a time Tuesday 06 January 2004 6:51 am, Warren Togami wrote: > Michael Schwendt wrote: > > Forwarding this so more people are aware of it: > Since this is being fixed in RH9, I vote that we should do the same for > older distributions. We should wait until we see the official RH9 > update and do exactly the same to the older distributions. > > Warren I agree, ? perhaps we should have a policy for this so that if redhat release a security release that will also affect us we build the package the same as Red Hat and release it. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Mon Jan 5 22:12:20 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 5 Jan 2004 14:12:20 -0800 (PST) Subject: Round 1: Local root exploit in the Kernel In-Reply-To: <20040105140651.GB924@sven.home.hoaxter.de> Message-ID: > Ok guys, time to try if you are prepared: > http://isec.pl/vulnerabilities/isec-0013-mremap.txt > > And a patch: > http://lkml.org/lkml/diff/2004/1/5/74/1 > > Don't know if this patch is complete or not .... If I am not mistaken, RedHat has released errata for this going back to RH 7.1. I would consider this a nice gesture on their part, since they didn't have to do that. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From sheltren at cs.ucsb.edu Mon Jan 5 22:13:07 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 05 Jan 2004 14:13:07 -0800 Subject: Round 1: Local root exploit in the Kernel In-Reply-To: References: Message-ID: <1073340786.14451.64.camel@derelict> Yes, he mentioned that in the next message - different subject line, I believe. -Jeff On Mon, 2004-01-05 at 14:12, Chuck Wolber wrote: > > Ok guys, time to try if you are prepared: > > http://isec.pl/vulnerabilities/isec-0013-mremap.txt > > > > And a patch: > > http://lkml.org/lkml/diff/2004/1/5/74/1 > > > > Don't know if this patch is complete or not .... > > If I am not mistaken, RedHat has released errata for this going back to RH > 7.1. I would consider this a nice gesture on their part, since they didn't > have to do that. > > -Chuck > > From chuckw at quantumlinux.com Mon Jan 5 22:16:46 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 5 Jan 2004 14:16:46 -0800 (PST) Subject: Primary Legacy distribution (was: Re: apt/yum configuration?) In-Reply-To: <1073318363.6652.30.camel@opus> Message-ID: > I'm confused again. Can't you just rsync: > > download.fedora.us/fedora/redhat/*/i386/RPMS.legacy/ > > ? > > Then wouldn't you get them all? > > Or do you mean for ftp-downloading? Is FTP enabled on download.fedora.us? It wasn't last time I checked. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From skvidal at phy.duke.edu Mon Jan 5 22:19:16 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 17:19:16 -0500 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> Message-ID: <1073341156.8527.21.camel@opus> On Mon, 2004-01-05 at 15:43, Michael Schwendt wrote: > Forwarding this so more people are aware of it: > > [...] > > Begin forwarded message: > > Date: Mon, 5 Jan 2004 14:19:33 -0500 > From: bugzilla at redhat.com > Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 > > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > davej at redhat.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution| |WONTFIX > Status|ON_QA |CLOSED > > > > > ------- Additional Comments From davej at redhat.com 2004-01-05 14:19 ------- > Due to an oversight, Patch5040 isn't applied. > Adding a .. > > %patch5040 -p1 > > to line 1090 or so and rebuilding from the SRPM will fix this. > I'll fix this for RHL9, but as RHL7/8 are now EOL, we won't be doing > further updates, sorry.. > If I can sort out the patch needed for 7.x can you test if it is fixed? I don't have anything that I can use to test this, so... But I have to build some kernels tonight anyway and I'll take a look to see if I can straighten out patch 5040. Thanks -sv From ms-nospam-0306 at arcor.de Mon Jan 5 22:25:46 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 5 Jan 2004 23:25:46 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073341156.8527.21.camel@opus> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> Message-ID: <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> On 05 Jan 2004 17:19:16 -0500, seth vidal wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > If I can sort out the patch needed for 7.x can you test if it is fixed? > I don't have anything that I can use to test this, so... > But I have to build some kernels tonight anyway and I'll take a look to > see if I can straighten out patch 5040. I've added a comment to above bugzilla ticket. I assume the rest of patch 5040 is obsolete/out-of-date (it's from 2001) and only the ip_conntrack fix at the very bottom needs to be applied separately. The "oversight" mentioned by Dave Jones is likely that he thought patch 5040 is valid (it doesn't apply) and is applied in the spec file. Hence he appended the conntrack fix at the end. I'm going to test the fix, too. -- From skvidal at phy.duke.edu Mon Jan 5 22:52:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 17:52:12 -0500 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> Message-ID: <1073343132.8527.28.camel@opus> On Mon, 2004-01-05 at 17:25, Michael Schwendt wrote: > On 05 Jan 2004 17:19:16 -0500, seth vidal wrote: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > If I can sort out the patch needed for 7.x can you test if it is fixed? > > > I don't have anything that I can use to test this, so... > > But I have to build some kernels tonight anyway and I'll take a look to > > see if I can straighten out patch 5040. > > I've added a comment to above bugzilla ticket. I assume the rest of patch > 5040 is obsolete/out-of-date (it's from 2001) and only the ip_conntrack > fix at the very bottom needs to be applied separately. > > The "oversight" mentioned by Dave Jones is likely that he thought patch > 5040 is valid (it doesn't apply) and is applied in the spec file. Hence he > appended the conntrack fix at the end. > > I'm going to test the fix, too. I looked at the patch in comment #36 - it looks close - but off by a bit Those section are (for the most part) present in 5040 - but not in the kernel. I'll see if I can combine a patch out of those to make a 5040 that applies clean. Though you're right 90% of 5040 is completely old. -sv From skvidal at phy.duke.edu Mon Jan 5 22:57:00 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 17:57:00 -0500 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073343132.8527.28.camel@opus> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> Message-ID: <1073343419.8527.33.camel@opus> On Mon, 2004-01-05 at 17:52, seth vidal wrote: > On Mon, 2004-01-05 at 17:25, Michael Schwendt wrote: > > On 05 Jan 2004 17:19:16 -0500, seth vidal wrote: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > > > If I can sort out the patch needed for 7.x can you test if it is fixed? > > > > > I don't have anything that I can use to test this, so... > > > But I have to build some kernels tonight anyway and I'll take a look to > > > see if I can straighten out patch 5040. > > > > I've added a comment to above bugzilla ticket. I assume the rest of patch > > 5040 is obsolete/out-of-date (it's from 2001) and only the ip_conntrack > > fix at the very bottom needs to be applied separately. > > > > The "oversight" mentioned by Dave Jones is likely that he thought patch > > 5040 is valid (it doesn't apply) and is applied in the spec file. Hence he > > appended the conntrack fix at the end. > > > > I'm going to test the fix, too. > > I looked at the patch in comment #36 - it looks close - but off by a bit > Those section are (for the most part) present in 5040 - but not in the > kernel. I'll see if I can combine a patch out of those to make a 5040 > that applies clean. Though you're right 90% of 5040 is completely old. > the last 3 patch sections from 5040 work. -sv From ms-nospam-0306 at arcor.de Mon Jan 5 23:01:09 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 00:01:09 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073343419.8527.33.camel@opus> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> Message-ID: <20040106000109.03b9f634.ms-nospam-0306@arcor.de> On 05 Jan 2004 17:57:00 -0500, seth vidal wrote: > > I looked at the patch in comment #36 - it looks close - but off by a bit > > Those section are (for the most part) present in 5040 - but not in the > > kernel. I'll see if I can combine a patch out of those to make a 5040 > > that applies clean. Though you're right 90% of 5040 is completely old. > > > > the last 3 patch sections from 5040 work. What was the last kernel release from Red Hat that had patch 5040 applied? The beginning of the patch adds some IRC/DCC stuff which is not in the kernel. But the ip_conntrack fix should really be made patch #911. -- From ms-nospam-0306 at arcor.de Mon Jan 5 23:02:28 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 00:02:28 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073343419.8527.33.camel@opus> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> Message-ID: <20040106000228.4ddbc49e.ms-nospam-0306@arcor.de> ------- Additional Comments From davej at redhat.com 2004-01-05 17:47 ------- Delete all the hunks apart from the final one touching ip_conntrack_core.c -- From smoogen at lanl.gov Mon Jan 5 23:06:03 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 5 Jan 2004 16:06:03 -0700 (MST) Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040106000109.03b9f634.ms-nospam-0306@arcor.de> Message-ID: Has anyone seen a connection leak with the iptables and ip_conntrack_ftp (Bug 112622). We have found that pinging a host and doing ftp from it causes the module to 'lose' the connection and eventually the kernel runs out of memory. Because of the bug in 103177, we have found that you cant remove the ip_conntrack_ftp :) to clear it up. On Tue, 6 Jan 2004, Michael Schwendt wrote: >On 05 Jan 2004 17:57:00 -0500, seth vidal wrote: > >> > I looked at the patch in comment #36 - it looks close - but off by a bit >> > Those section are (for the most part) present in 5040 - but not in the >> > kernel. I'll see if I can combine a patch out of those to make a 5040 >> > that applies clean. Though you're right 90% of 5040 is completely old. >> > >> >> the last 3 patch sections from 5040 work. > >What was the last kernel release from Red Hat that had patch 5040 >applied? > >The beginning of the patch adds some IRC/DCC stuff which is not in the >kernel. > >But the ip_conntrack fix should really be made patch #911. > > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From davej at redhat.com Mon Jan 5 23:08:39 2004 From: davej at redhat.com (Dave Jones) Date: Mon, 5 Jan 2004 23:08:39 +0000 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040106000109.03b9f634.ms-nospam-0306@arcor.de> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> <20040106000109.03b9f634.ms-nospam-0306@arcor.de> Message-ID: <20040105230839.GA12113@redhat.com> On Tue, Jan 06, 2004 at 12:01:09AM +0100, Michael Schwendt wrote: > On 05 Jan 2004 17:57:00 -0500, seth vidal wrote: > > > > I looked at the patch in comment #36 - it looks close - but off by a bit > > > Those section are (for the most part) present in 5040 - but not in the > > > kernel. I'll see if I can combine a patch out of those to make a 5040 > > > that applies clean. Though you're right 90% of 5040 is completely old. > > > > > > > the last 3 patch sections from 5040 work. > > What was the last kernel release from Red Hat that had patch 5040 > applied? > > The beginning of the patch adds some IRC/DCC stuff which is not in the > kernel. > > But the ip_conntrack fix should really be made patch #911. FWIW, I've done it that way for any future RHL9 update we do. Dave From davej at redhat.com Mon Jan 5 23:10:20 2004 From: davej at redhat.com (Dave Jones) Date: Mon, 5 Jan 2004 23:10:20 +0000 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040106000228.4ddbc49e.ms-nospam-0306@arcor.de> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> <20040106000228.4ddbc49e.ms-nospam-0306@arcor.de> Message-ID: <20040105231020.GB12113@redhat.com> On Tue, Jan 06, 2004 at 12:02:28AM +0100, Michael Schwendt wrote: > ------- Additional Comments From davej at redhat.com 2004-01-05 17:47 ------- > Delete all the hunks apart from the final one touching > ip_conntrack_core.c > My grammar really sucks tonight. To avoid confusion, you need all the hunks touching net/ipv4/netfilter/ip_conntrack_core.c , the rest of the patchfile can be discarded. Dave From skvidal at phy.duke.edu Mon Jan 5 23:17:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 05 Jan 2004 18:17:36 -0500 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040105230839.GA12113@redhat.com> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> <20040106000109.03b9f634.ms-nospam-0306@arcor.de> <20040105230839.GA12113@redhat.com> Message-ID: <1073344655.8527.38.camel@opus> > > FWIW, I've done it that way for any future RHL9 update we do. I attached the cleaned up patch to the bug. I compared it to the patch in comment 36 to see if it did the same/similar things. looks good. I'll have kernels shortly, I'll post them for someone to test to that bug and here if anyone is interested. -sv From cra at WPI.EDU Mon Jan 5 23:19:23 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 5 Jan 2004 18:19:23 -0500 Subject: Self-Introduction: Charles R. Anderson Message-ID: <20040105231923.GG6778@angus.ind.WPI.EDU> 1. Charles R. Anderson 2. USA, Worcester, MA 3. Network Engineer 4. WPI 5. Your goals in the Fedora Project * Which packages do you want to see published? . updated net-snmp w/perl support . updated dhcp packages suitable for failover support . nagios, CMU NetReg, rrdtool, cricket, mrtg . IPv6 support in more apps . network-related work with e.g. link detection, IPsec... . alsa, more multimedia apps (with IP multicast support) . kegs (Kent's Emulated GS) and other emulator tools . koules and xboing (anyone up for network koules? :) * Do you want to do QA? Yes. * Anything else special? My main interests are in packaging, QA, testing, tools/infrastructure/admin, rather than coding/debugging. However, I'd feel at home coding in Perl. I'm interested in Legacy only to support my couple of remaining 7.3 boxes for as long as they stay that way, and possibly 7.2/Alpha and Aurora SPARC as time permits. 6. Historical qualifications * What other projects have you worked on in the past? . Aurora SPARC Linux . I've been packaging ISC dhcp RPM's for three years: http://www.isc.org/products/DHCP/ . CMU NetReg: http://www.net.cmu.edu/netreg/ . LANdb: http://landb.sourceforge.net/ . Autostatus: http://www.angio.net/consult/autostatus/ * What computer languages and other skills do you know? . C, C++, Assembly, Scheme . Perl, Awk, Sed, C Shell, Bourne Shell, Expect . Networking and systems administration * Why should we trust you? <--- too blunt? That's for the community to decide... I've been a RHL user since 1996/RHL 4.0 or so. I've done a lot of RPM packaging, informally published on ftp://angus.ind.wpi.edu/pub/cra-contrib. I've participated in RHL betas and the mirror process. 7. GPG KEYID and fingerprint pub 1024D/49BB5886 2001-04-11 Charles R. Anderson Key fingerprint = EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886 sub 2048g/B0817A13 2001-04-11 From chuckw at quantumlinux.com Mon Jan 5 23:22:45 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 5 Jan 2004 15:22:45 -0800 (PST) Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073344655.8527.38.camel@opus> Message-ID: > looks good. I'll have kernels shortly, I'll post them for someone to > test to that bug and here if anyone is interested. Fire away, I'll be happy to test 'em. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From ms-nospam-0306 at arcor.de Tue Jan 6 00:12:28 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 01:12:28 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <20040105231020.GB12113@redhat.com> References: <20040105214357.73cb280a.ms-nospam-0306@arcor.de> <1073341156.8527.21.camel@opus> <20040105232546.2ecdfc66.ms-nospam-0306@arcor.de> <1073343132.8527.28.camel@opus> <1073343419.8527.33.camel@opus> <20040106000228.4ddbc49e.ms-nospam-0306@arcor.de> <20040105231020.GB12113@redhat.com> Message-ID: <20040106011228.65a03e89.ms-nospam-0306@arcor.de> On Mon, 5 Jan 2004 23:10:20 +0000, Dave Jones wrote: > On Tue, Jan 06, 2004 at 12:02:28AM +0100, Michael Schwendt wrote: > > ------- Additional Comments From davej at redhat.com 2004-01-05 17:47 ------- > > Delete all the hunks apart from the final one touching > > ip_conntrack_core.c > > > > My grammar really sucks tonight. To avoid confusion, you need all the > hunks touching net/ipv4/netfilter/ip_conntrack_core.c , the rest of > the patchfile can be discarded. To make you happy, I think your bugzilla comment can't be misunderstood. -- From cra at WPI.EDU Tue Jan 6 01:06:18 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 5 Jan 2004 20:06:18 -0500 Subject: default yum configuration for Legacy Message-ID: <20040106010618.GH6778@angus.ind.WPI.EDU> Should the yum service default to on or off? Should the yum.conf exclude kernels by default? I think auto updates should be off by default, and kernels should be excluded by default, just as it is in up2date. What are people's opinions on this? From jkeating at j2solutions.net Tue Jan 6 01:11:25 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 5 Jan 2004 17:11:25 -0800 Subject: default yum configuration for Legacy In-Reply-To: <20040106010618.GH6778@angus.ind.WPI.EDU> References: <20040106010618.GH6778@angus.ind.WPI.EDU> Message-ID: <200401051711.26716.jkeating@j2solutions.net> On Monday 05 January 2004 17:06, Charles R. Anderson wrote: > Should the yum service default to on or off? > Should the yum.conf exclude kernels by default? > > I think auto updates should be off by default, and kernels should be > excluded by default, just as it is in up2date. > > What are people's opinions on this? I am in complete agreement. Duplicate up2date. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sheltren at cs.ucsb.edu Tue Jan 6 02:08:16 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 5 Jan 2004 18:08:16 -0800 Subject: default yum configuration for Legacy In-Reply-To: <200401051711.26716.jkeating@j2solutions.net> Message-ID: <200401060159.i061xCZu028636@stamps.cs.ucsb.edu> Mark me up as in agreement as well. It's simple for people to change those options anyway... -Jeff > -----Original Message----- > From: fedora-legacy-list-admin at redhat.com > [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of > Jesse Keating > Sent: Monday, January 05, 2004 5:11 PM > To: fedora-legacy-list at redhat.com > Subject: Re: default yum configuration for Legacy > > On Monday 05 January 2004 17:06, Charles R. Anderson wrote: > > Should the yum service default to on or off? > > Should the yum.conf exclude kernels by default? > > > > I think auto updates should be off by default, and kernels > should be > > excluded by default, just as it is in up2date. > > > > What are people's opinions on this? > > I am in complete agreement. Duplicate up2date. > From rohwedde at codegrinder.com Tue Jan 6 02:06:46 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 5 Jan 2004 20:06:46 -0600 Subject: default yum configuration for Legacy In-Reply-To: <20040106010618.GH6778@angus.ind.WPI.EDU> References: <20040106010618.GH6778@angus.ind.WPI.EDU> Message-ID: <20040106020646.GG3353@codegrinder.com> Personally, I don't have a problem if yum updates the kernel by default, provided that it isn't running as a service. I presume it prompts you similarly to apt. That said, the current apt candidate will upgrade the kernel. So, if we change it in yum, we should make apt match. -jason On Mon, Jan 05, 2004 at 08:06:18PM -0500, Charles R. Anderson wrote: > Should the yum service default to on or off? > Should the yum.conf exclude kernels by default? > > I think auto updates should be off by default, and kernels should be > excluded by default, just as it is in up2date. > > What are people's opinions on this? > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ow.mun.heng at wdc.com Tue Jan 6 02:56:12 2004 From: ow.mun.heng at wdc.com (Ow Mun Heng) Date: Tue, 6 Jan 2004 10:56:12 +0800 Subject: RH8 + updated Kernel to fix do_mremap Message-ID: Hi, Does anyone knows where I can find updated kernel packages to fix this do_mremap issue in the linux kernel? This is a prod machine. I rather have rpms than build my own kernel. Cheers, .^. Mun Heng, Ow /V\ H/M Engineering /( )\ Western Digital M'sia ^^-^^ DID : 03-7870 5168 The Linux Advocate From jkeating at j2solutions.net Tue Jan 6 02:56:57 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 5 Jan 2004 18:56:57 -0800 Subject: RH8 + updated Kernel to fix do_mremap In-Reply-To: References: Message-ID: <200401051857.00895.jkeating@j2solutions.net> On Monday 05 January 2004 18:56, Ow Mun Heng wrote: > Hi, > > Does anyone knows where I can find updated kernel packages to fix > this do_mremap > issue in the linux kernel? > > This is a prod machine. I rather have rpms than build my own kernel. Try the standard RHL update trees. There were errata kernels issued over the weekend. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From whooperhsd3 at earthlink.net Tue Jan 6 03:03:00 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Mon, 5 Jan 2004 22:03:00 -0500 (EST) Subject: RH8 + updated Kernel to fix do_mremap In-Reply-To: References: Message-ID: <65170.69.68.37.57.1073358180.squirrel@69.68.37.57> Ow Mun Heng said: > Hi, > > Does anyone knows where I can find updated kernel packages to fix this > do_mremap > issue in the linux kernel? As discussed previously: https://rhn.redhat.com/errata/RHSA-2003-417.html -- William Hooper From ow.mun.heng at wdc.com Tue Jan 6 03:07:42 2004 From: ow.mun.heng at wdc.com (Ow Mun Heng) Date: Tue, 6 Jan 2004 11:07:42 +0800 Subject: RH8 + updated Kernel to fix do_mremap Message-ID: > -----Original Message----- > From: William Hooper [mailto:whooperhsd3 at earthlink.net] > Sent: Tuesday, January 06, 2004 11:03 AM > To: fedora-legacy-list at redhat.com > Subject: Re: RH8 + updated Kernel to fix do_mremap > > > > Ow Mun Heng said: > > Hi, > > > > Does anyone knows where I can find updated kernel packages > to fix this > > do_mremap > > issue in the linux kernel? > > As discussed previously: > https://rhn.redhat.com/errata/RHSA-2003-417.html >> From: Jesse Keating [mailto:jkeating at j2solutions.net] >> Try the standard RHL update trees. There were errata kernels issued >> over the weekend. Hmm.. Thanks guys.. I thought that they stopped providing updates for RH8 & Below since they EOL'ed I'll check there.. Thanks,. From whooperhsd3 at earthlink.net Tue Jan 6 03:13:20 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Mon, 5 Jan 2004 22:13:20 -0500 (EST) Subject: RH8 + updated Kernel to fix do_mremap In-Reply-To: References: Message-ID: <65434.69.68.37.57.1073358800.squirrel@69.68.37.57> Ow Mun Heng said: > > >> -----Original Message----- >> From: William Hooper [mailto:whooperhsd3 at earthlink.net] >> Sent: Tuesday, January 06, 2004 11:03 AM >> To: fedora-legacy-list at redhat.com >> Subject: Re: RH8 + updated Kernel to fix do_mremap >> >> >> >> Ow Mun Heng said: >> > Hi, >> > >> > Does anyone knows where I can find updated kernel packages >> to fix this >> > do_mremap >> > issue in the linux kernel? >> >> As discussed previously: >> https://rhn.redhat.com/errata/RHSA-2003-417.html > >>> From: Jesse Keating [mailto:jkeating at j2solutions.net] >>> Try the standard RHL update trees. There were errata kernels issued >>> over the weekend. > > Hmm.. Thanks guys.. > > I thought that they stopped providing updates for RH8 & Below since they > EOL'ed > > I'll check there.. > "We have provided kernel updates for Red Hat Linux 7.1-8.0 with this advisory as these were prepared by us prior to December 31 2003." The same thing happened right after the 6.2 EOL (a sendmail issue IIRC). No sense in just throwing the code away if it was already in the process. -- William Hooper From skvidal at phy.duke.edu Tue Jan 6 03:57:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 05 Jan 2004 22:57:50 -0500 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: References: Message-ID: <1073361470.3644.3.camel@binkley> On Mon, 2004-01-05 at 18:22, Chuck Wolber wrote: > > looks good. I'll have kernels shortly, I'll post them for someone to > > test to that bug and here if anyone is interested. > > Fire away, I'll be happy to test 'em. > /me listens to the p3-933 churn go, speedracer, go! I'll post them once they're done :) -sv From ingo at auroralinux.org Tue Jan 6 08:02:40 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Tue, 6 Jan 2004 09:02:40 +0100 Subject: default yum configuration for Legacy References: <20040106010618.GH6778@angus.ind.WPI.EDU> <200401051711.26716.jkeating@j2solutions.net> Message-ID: <022901c3d42b$90a91c30$152ca8c0@OPTIMUS> > Duplicate up2date. I agree, too. No automatic updates. Only addition might be a cron job that mails root the current candidates. That's what I do on all my systems. Ingo From skvidal at phy.duke.edu Tue Jan 6 13:57:06 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jan 2004 08:57:06 -0500 Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 Message-ID: <1073397426.3644.5.camel@binkley> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 ------- Additional Comments From skvidal at phy.duke.edu 2004-01-06 08:55 ------- http://linux.duke.edu/~skvidal/RPMS/kernel/ Those are the kernels built on 7.3 - I only built i686 and athlon. y'all go ahead and test them, see if it fixes that bug. -sv From ms-nospam-0306 at arcor.de Tue Jan 6 14:06:21 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 15:06:21 +0100 Subject: Fw: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073361470.3644.3.camel@binkley> References: <1073361470.3644.3.camel@binkley> Message-ID: <20040106150621.28315f4b.ms-nospam-0306@arcor.de> On Mon, 05 Jan 2004 22:57:50 -0500, seth vidal wrote: > On Mon, 2004-01-05 at 18:22, Chuck Wolber wrote: > > > looks good. I'll have kernels shortly, I'll post them for someone to > > > test to that bug and here if anyone is interested. > > > > Fire away, I'll be happy to test 'em. > > > > /me listens to the p3-933 churn > > go, speedracer, go! > > I'll post them once they're done :) The ip_conntrack_core patch doesn't fix it for me. As before, "service iptables start" hangs at "Unloading iptables modules:" with modprobe waiting for ip_conntrack (as the last netfilter module) to be removed. My current work-around is the one mentioned in the bug report, but it doesn't work for everyone. Other work-arounds are documented (on one of the mailing-lists, too), and going back to an older iptables package or never rmmod'ing netfilter modules are other ones. -- From ms-nospam-0306 at arcor.de Tue Jan 6 14:09:01 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 15:09:01 +0100 Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073397426.3644.5.camel@binkley> References: <1073397426.3644.5.camel@binkley> Message-ID: <20040106150901.62d40a33.ms-nospam-0306@arcor.de> On Tue, 06 Jan 2004 08:57:06 -0500, seth vidal wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > ------- Additional Comments From skvidal at phy.duke.edu 2004-01-06 08:55 ------- > http://linux.duke.edu/~skvidal/RPMS/kernel/ > > Those are the kernels built on 7.3 - I only built i686 and athlon. > > > > y'all go ahead and test them, see if it fixes that bug. Expect another reply in a few minutes. Though I doubt my own built was incorrect. -- From ms-nospam-0306 at arcor.de Tue Jan 6 14:17:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 6 Jan 2004 15:17:20 +0100 Subject: [Bug 103177] /etc/init.d/iptables stop hangs after upgrade to iptables-1.2.8-8.72.3 In-Reply-To: <1073397426.3644.5.camel@binkley> References: <1073397426.3644.5.camel@binkley> Message-ID: <20040106151720.175f0caf.ms-nospam-0306@arcor.de> On Tue, 06 Jan 2004 08:57:06 -0500, seth vidal wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 > > > ------- Additional Comments From skvidal at phy.duke.edu 2004-01-06 08:55 ------- > http://linux.duke.edu/~skvidal/RPMS/kernel/ > > Those are the kernels built on 7.3 - I only built i686 and athlon. > > > > y'all go ahead and test them, see if it fixes that bug. Additional Comment #54 From Michael Schwendt on 2004-01-06 09:13 ------- Not enough. The ip_conntrack_core patch doesn't fix it. -- From pearcec at commnav.com Tue Jan 6 19:37:17 2004 From: pearcec at commnav.com (Christian Pearce) Date: Tue, 06 Jan 2004 14:37:17 -0500 Subject: Self-Introduction: Christian Pearce Message-ID: <1073417836.17995.42.camel@insight.pearcec.com> 1. Christian Lee Pearce 2. Harrisburg, PA USA 3. Software Engineer 4. CommNav, Inc. 5. Your goals in the Fedora Project * Which packages do you want to see published? Security Updates, and Severe Bugs * Do you want to do QA? Yes * Anything else special? See gabber in Fedora Core, but that is for another time. I basically want to have useful input into the process. 6. Historical qualifications * What other projects have you worked on in the past? larrd -- http://larrd.packetpushers.com kick2date -- http://www.commnav.com/~pearcec/ SysNav -- http://sysnav.commnav.com * What computer languages and other skills do you know? Shell, C, PHP, Perl. Most System Administration skills. * Why should we trust you? <--- too blunt? www.pearcec.com -- Read about my bike accident. You just don't make stuff like this up. My key is there too. 7. GPG KEYID and fingerprint [pearcec at insight pearcec]$ gpg --fingerprint 55A4B63A pub 1024D/55A4B63A 2004-01-06 Christian Pearce Key fingerprint = 5FFA 2D43 0280 335E 2208 1C4D 765C E054 55A4 B63A sub 1024g/5C36887F 2004-01-06 Not sure if I got the PGP signing for this email correct. -- Christian Pearce http://www.commnav.com -------------- 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 rohwedde at codegrinder.com Tue Jan 6 23:50:13 2004 From: rohwedde at codegrinder.com (Jason) Date: Tue, 6 Jan 2004 17:50:13 -0600 Subject: ethereal DOS vulnerabilities Message-ID: <20040106235013.GI3353@codegrinder.com> Debian posted an advisory for ethereal the other day with quite a few patches listed. Most were covered from a previous redhat patch, except for 2. [ CAN-2003-1012, CAN-2003-1013 ]. The debian advisory is at [ http://www.debian.org/security/2004/dsa-407 ], previous redhat one is [ https://rhn.redhat.com/errata/RHSA-2003-323.html ]. I'll take a crack at it when I get a chance.. but if anyone else want to work on it.. be my guest :) -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rohwedde at codegrinder.com Wed Jan 7 04:22:13 2004 From: rohwedde at codegrinder.com (Jason) Date: Tue, 6 Jan 2004 22:22:13 -0600 Subject: screen buffer overflow Message-ID: <20040107042213.GK3353@codegrinder.com> Currently entered into the bugzilla at: https://bugzilla.fedora.us/show_bug.cgi?id=1187 I'm curious whether the community thinks this is a necessary patch? Thanks. -jason --------------------------------------------------------------------- Patched SRPMS for screen buffer overflow Details at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0972 http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 RH 7.3 https://mail.codegrinder.com/www/screen-3.9.11-4.legacy.src.rpm RH 7.2 https://mail.codegrinder.com/www/screen-3.9.9-4.legacy.src.rpm MD5SUM https://mail.codegrinder.com/www/screen-md5sums.asc The 7.3 rpms work for me.. I don't have a 7.2 box available to test that one. The default in 7.3 is to not suid the screen binary, so I think we're safe from privilege escalation (unless the user does it of their own volition). But, I am a bit concerned with the idea that someone could hijack my screen session. So, is this a patch we want to push? If so, we should patch the RH8 rpms as well. RH hasn't yet released a patch for 9, though it has a vulnerable version. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lists at unbeatenpath.net Wed Jan 7 04:32:28 2004 From: lists at unbeatenpath.net (Cameron Moore) Date: Tue, 6 Jan 2004 22:32:28 -0600 Subject: What am I missing? Message-ID: <20040106223228.A1312@unbeatenpath.net> sh# rpm -q apt apt-0.5.5cnc5-fr0.rh73.2 In /etc/apt/sources.list: rpm http://download.fedora.us fedora/redhat/7.3/i386 RPMS.updates RPMS.os sh# apt-get update ... Failed to fetch http://download.fedora.us/fedora/redhat/7.3/i386/base/pkglist.RPMS.updates 404 Not Found sh# lynx -force_html -dump -nolist \ http://download.fedora.us/fedora/redhat/7.3/i386/base/ ... [ ] pkglist.updates 05-Jan-2004 14:37 2.1M [ ] pkglist.updates.bz2 05-Jan-2004 14:37 163k You can see that apt is looking for the "RPMS" string to be in the base filenames. What's b0rken here? The mirrors, my config, or my apt version? Thanks -- Cameron Moore [ Would a fly without wings be called a walk? ] From rohwedde at codegrinder.com Wed Jan 7 04:37:31 2004 From: rohwedde at codegrinder.com (Jason) Date: Tue, 6 Jan 2004 22:37:31 -0600 Subject: What am I missing? In-Reply-To: <20040106223228.A1312@unbeatenpath.net> References: <20040106223228.A1312@unbeatenpath.net> Message-ID: <20040107043731.GL3353@codegrinder.com> Try this in your sources.list rpm http://download.fedora.us/fedora redhat/7.3/i386 os updates -jason On Tue, Jan 06, 2004 at 10:32:28PM -0600, Cameron Moore wrote: > sh# rpm -q apt > apt-0.5.5cnc5-fr0.rh73.2 > > > In /etc/apt/sources.list: > rpm http://download.fedora.us fedora/redhat/7.3/i386 RPMS.updates RPMS.os > > > sh# apt-get update > ... > Failed to fetch http://download.fedora.us/fedora/redhat/7.3/i386/base/pkglist.RPMS.updates 404 Not Found > > > sh# lynx -force_html -dump -nolist \ > http://download.fedora.us/fedora/redhat/7.3/i386/base/ > ... > [ ] pkglist.updates 05-Jan-2004 14:37 2.1M > [ ] pkglist.updates.bz2 05-Jan-2004 14:37 163k > > You can see that apt is looking for the "RPMS" string to be in the base > filenames. What's b0rken here? The mirrors, my config, or my apt > version? Thanks > -- > Cameron Moore > [ Would a fly without wings be called a walk? ] > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lists at unbeatenpath.net Wed Jan 7 04:46:14 2004 From: lists at unbeatenpath.net (Cameron Moore) Date: Tue, 6 Jan 2004 22:46:14 -0600 Subject: What am I missing? In-Reply-To: <20040107043731.GL3353@codegrinder.com>; from rohwedde@codegrinder.com on Tue, Jan 06, 2004 at 10:37:31PM -0600 References: <20040106223228.A1312@unbeatenpath.net> <20040107043731.GL3353@codegrinder.com> Message-ID: <20040106224614.A1609@unbeatenpath.net> Thanks, this fixed it. It would be helpful for the other idiots out there like myself if an explicit example was given on the FedoraChannels Wiki page. Thanks again * rohwedde at codegrinder.com (Jason) [2004.01.06 22:38]: > Try this in your sources.list > > rpm http://download.fedora.us/fedora redhat/7.3/i386 os updates > > -jason > > On Tue, Jan 06, 2004 at 10:32:28PM -0600, Cameron Moore wrote: > > sh# rpm -q apt > > apt-0.5.5cnc5-fr0.rh73.2 > > > > In /etc/apt/sources.list: > > rpm http://download.fedora.us fedora/redhat/7.3/i386 RPMS.updates RPMS.os > > > > sh# apt-get update > > ... > > Failed to fetch http://download.fedora.us/fedora/redhat/7.3/i386/base/pkglist.RPMS.updates 404 Not Found > > > > sh# lynx -force_html -dump -nolist \ > > http://download.fedora.us/fedora/redhat/7.3/i386/base/ > > ... > > [ ] pkglist.updates 05-Jan-2004 14:37 2.1M > > [ ] pkglist.updates.bz2 05-Jan-2004 14:37 163k > > > > You can see that apt is looking for the "RPMS" string to be in the base > > filenames. What's b0rken here? The mirrors, my config, or my apt > > version? Thanks -- Cameron Moore / What do you do when you see an endangered \ \ animal that eats only endangered plants? / From lists at unbeatenpath.net Wed Jan 7 04:55:53 2004 From: lists at unbeatenpath.net (Cameron Moore) Date: Tue, 6 Jan 2004 22:55:53 -0600 Subject: OT: Apt and the kernel Message-ID: <20040106225553.B1609@unbeatenpath.net> How about another dumb question? Okay, here goes... Apt never seems to notice that a new kernel package is available for updating -- I have to explicitly list the available kernel packages and install the new one. Is this a bug or a feature? In either case, is there a way to fix this annoying behavior? I've seen it happen before on a different package, but I don't recall what it was. Thanks -- Cameron Moore [ Anything that's worth having is worth working for. ] From warren at togami.com Wed Jan 7 05:48:56 2004 From: warren at togami.com (Warren Togami) Date: Tue, 06 Jan 2004 19:48:56 -1000 Subject: OT: Apt and the kernel In-Reply-To: <20040106225553.B1609@unbeatenpath.net> References: <20040106225553.B1609@unbeatenpath.net> Message-ID: <3FFB9DC8.6030507@togami.com> Cameron Moore wrote: > How about another dumb question? Okay, here goes... > > Apt never seems to notice that a new kernel package is available for > updating -- I have to explicitly list the available kernel packages and > install the new one. Is this a bug or a feature? In either case, is > there a way to fix this annoying behavior? I've seen it happen before > on a different package, but I don't recall what it was. Thanks That is older apt, and apt from FreshRPMS and other paackagers. apt from fedora.us (soon to be published for Legacy too) is totally not made to be used for automated upgrades like some people currently use yum. As a result, our apt is set to offer to upgrade to the latest kernel if it is available. As always however, it is your job to reboot later. Warren From lists at unbeatenpath.net Wed Jan 7 06:06:33 2004 From: lists at unbeatenpath.net (Cameron Moore) Date: Wed, 7 Jan 2004 00:06:33 -0600 Subject: OT: Apt and the kernel In-Reply-To: <3FFB9DC8.6030507@togami.com>; from warren@togami.com on Tue, Jan 06, 2004 at 07:48:56PM -1000 References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> Message-ID: <20040107000633.C1609@unbeatenpath.net> * warren at togami.com (Warren Togami) [2004.01.06 23:49]: > Cameron Moore wrote: > > How about another dumb question? Okay, here goes... > > > > Apt never seems to notice that a new kernel package is available for > > updating -- I have to explicitly list the available kernel packages and > > install the new one. Is this a bug or a feature? In either case, is > > there a way to fix this annoying behavior? I've seen it happen before > > on a different package, but I don't recall what it was. Thanks > > That is older apt, and apt from FreshRPMS and other paackagers. apt > from fedora.us (soon to be published for Legacy too) is totally not made > to be used for automated upgrades like some people currently use yum. > As a result, our apt is set to offer to upgrade to the latest kernel if > it is available. > > As always however, it is your job to reboot later. I'm perfectly fine with that. I don't do auto-updates, but I do have a little cron job that checks for available apt updates to make sure I don't miss a server. I mostly just want apt to be _aware_ of the upgrade -- I can do the update manually. Thanks for all your work, Warren. -- Cameron Moore [ Where do forest rangers go to "get away from it all?" ] From Axel.Thimm at physik.fu-berlin.de Wed Jan 7 07:29:06 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 7 Jan 2004 08:29:06 +0100 Subject: OT: Apt and the kernel In-Reply-To: <3FFB9DC8.6030507@togami.com> References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> Message-ID: <20040107072906.GA30593@neu.nirvana> On Tue, Jan 06, 2004 at 07:48:56PM -1000, Warren Togami wrote: > Cameron Moore wrote: > >How about another dumb question? Okay, here goes... > > > >Apt never seems to notice that a new kernel package is available for > >updating -- I have to explicitly list the available kernel packages and > >install the new one. Is this a bug or a feature? In either case, is > >there a way to fix this annoying behavior? I've seen it happen before > >on a different package, but I don't recall what it was. Thanks > > That is older apt, and apt from FreshRPMS and other paackagers. What? Where did you pick that one up? ATrpms is deploying apt 0.5.15cnc5 for quite many repos (and all RH dists for RH7.3 to FC1 BTW), is obviously the latest and still does not upgrade kernels by default, which is a matter of policy, neither bug, nor feature. Personally I am fine with forcing the user to chose a kernel, since this is probably the perfect example of not using plain stupid EVR upgrade paths. > apt from fedora.us (soon to be published for Legacy too) is totally > not made to be used for automated upgrades like some people > currently use yum. As a result, our apt is set to offer to upgrade > to the latest kernel if it is available. You mean apt from fedora.us will require interactive sessions? I don't believe Panu would permit castrating his work like that ;) -- Axel.Thimm at physik.fu-berlin.de -------------- 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 physik.fu-berlin.de Wed Jan 7 07:55:22 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 7 Jan 2004 08:55:22 +0100 Subject: Backporting policy Message-ID: <20040107075522.GB30593@neu.nirvana> Hi, I just realized that all nice legacy talks about rpm upgrades, infrastructure, repository mixing etc. have missed some very important _content related_ points, especially the workflow/policies for patching/backporting. It is quite clear to me that the profile of this group is intended to create backported fixes. An important link has already been posted here by Russ P. Herrold: http://www.redhat.com/advice/speaks_backport.html Now you can either o do it the hard way: When a security related or other problem pops up, identify the problem, and patch the version coming with the distro. This ensures that the APIs/ABIs remain in place, and that the QA still applies, if the fix is indeed small enough and the patched software QAed with the fix in mind. This is the preferred mode of operation for this forum, IMO. Backporting was the most valuable service coming from RH updates and that is what users will be looking for. o do it the easy way: Usually there will be a recent upstream version fixing the problem, grab the srpm from rawhide, QA it and stuff it into RH7.3 updates. Obviously this is fast, and better than nothing if nobody does the true work above. The latter method is something most external repos do. For instance ATrpms provides upgraded, not backported (!) versions of rpm, yum and apt for RH7.3 upwards. Again I don't think that should be legacy's mode of operation. I expect highly conservative methods here. Otherwise you could just as good submit packages to ATrpms. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Wed Jan 7 08:20:31 2004 From: warren at togami.com (Warren Togami) Date: Tue, 06 Jan 2004 22:20:31 -1000 Subject: OT: Apt and the kernel In-Reply-To: <20040107072906.GA30593@neu.nirvana> References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> <20040107072906.GA30593@neu.nirvana> Message-ID: <3FFBC14F.9050903@togami.com> Axel Thimm wrote: >>That is older apt, and apt from FreshRPMS and other paackagers. > > > What? Where did you pick that one up? ATrpms is deploying apt > 0.5.15cnc5 for quite many repos (and all RH dists for RH7.3 to FC1 > BTW), is obviously the latest and still does not upgrade kernels by > default, which is a matter of policy, neither bug, nor > feature. Personally I am fine with forcing the user to chose a kernel, > since this is probably the perfect example of not using plain stupid > EVR upgrade paths. Again you automatically assume I am poking at you. Notice how I say older AND apt from other packagers. older was meant to mean older fedora.us apt versions. > > >>apt from fedora.us (soon to be published for Legacy too) is totally >>not made to be used for automated upgrades like some people >>currently use yum. As a result, our apt is set to offer to upgrade >>to the latest kernel if it is available. > > > You mean apt from fedora.us will require interactive sessions? I don't > believe Panu would permit castrating his work like that ;) Panu is exactly the one that setup the defaults this way. Nothing stops the user from changing those defaults and making it auto-upgrade capable though... Warren From pearcec at commnav.com Wed Jan 7 13:50:00 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 7 Jan 2004 13:50:00 GMT Subject: screen buffer overflow Message-ID: <43068.209.50.130.84.1073483400.commnav@home.commnav.com> I compiled it for 7.2. It seems to work fine. I updated the bug. https://bugzilla.fedora.us/show_bug.cgi?id=1187 I am not certain if we should choose to release this as a security fix. Certainly if RedHat does for 9 we should. If other distributions do we should as well. Since we did the work at this point we should. -- Christian Pearce http://www.commnav.com rohwedde at codegrinder.com (Jason) said: > > > Currently entered into the bugzilla at: > https://bugzilla.fedora.us/show_bug.cgi?id=1187 > > I'm curious whether the community thinks this is a necessary patch? > Thanks. > > -jason > > --------------------------------------------------------------------- > > Patched SRPMS for screen buffer overflow > > Details at: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0972 > http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 > > RH 7.3 https://mail.codegrinder.com/www/screen-3.9.11-4.legacy.src.rpm > RH 7.2 https://mail.codegrinder.com/www/screen-3.9.9-4.legacy.src.rpm > MD5SUM https://mail.codegrinder.com/www/screen-md5sums.asc > > The 7.3 rpms work for me.. I don't have a 7.2 box available to test that > one. > > The default in 7.3 is to not suid the screen binary, so I think we're > safe from privilege escalation (unless the user does it of their own > volition). But, I am a bit concerned with the idea that someone could > hijack my screen session. So, is this a patch we want to push? If so, > we should patch the RH8 rpms as well. RH hasn't yet released a patch > for 9, though it has a vulnerable version. > > From pearcec at commnav.com Wed Jan 7 13:55:28 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 7 Jan 2004 13:55:28 GMT Subject: ethereal DOS vulnerabilities Message-ID: <43095.209.50.130.84.1073483728.commnav@home.commnav.com> I can give it a shot. Were do I get the patches from? Do I work from what Debian did? -- Christian Pearce http://www.commnav.com rohwedde at codegrinder.com (Jason) said: > > > Debian posted an advisory for ethereal the other day with quite a few > patches listed. Most were covered from a previous redhat patch, except > for 2. [ CAN-2003-1012, CAN-2003-1013 ]. The debian advisory is at > [ http://www.debian.org/security/2004/dsa-407 ], previous redhat one is > [ https://rhn.redhat.com/errata/RHSA-2003-323.html ]. I'll take a crack > at it when I get a chance.. but if anyone else want to work on it.. be > my guest :) > > -jason > From rohwedde at codegrinder.com Wed Jan 7 15:57:20 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 7 Jan 2004 09:57:20 -0600 Subject: screen buffer overflow In-Reply-To: <43068.209.50.130.84.1073483400.commnav@home.commnav.com> References: <43068.209.50.130.84.1073483400.commnav@home.commnav.com> Message-ID: <20040107155720.GM3353@codegrinder.com> Thanks for testing, Christian. Debian and Mandrake have released fixes for it. However Debian suid's their screen binary, so they have a much higher risk with this bug. I'm not sure about mandrake. -jason On Wed, Jan 07, 2004 at 01:50:00PM +0000, Christian Pearce wrote: > I compiled it for 7.2. It seems to work fine. I updated the bug. > > https://bugzilla.fedora.us/show_bug.cgi?id=1187 > > I am not certain if we should choose to release this as a security fix. Certainly if RedHat does for 9 we should. If other distributions do we should as well. Since we did the work at this point we should. > > -- > Christian Pearce > http://www.commnav.com > > > > rohwedde at codegrinder.com (Jason) said: > > > > > > Currently entered into the bugzilla at: > > https://bugzilla.fedora.us/show_bug.cgi?id=1187 > > > > I'm curious whether the community thinks this is a necessary patch? > > Thanks. > > > > -jason > > > > --------------------------------------------------------------------- > > > > Patched SRPMS for screen buffer overflow > > > > Details at: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0972 > > http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 > > > > RH 7.3 https://mail.codegrinder.com/www/screen-3.9.11-4.legacy.src.rpm > > RH 7.2 https://mail.codegrinder.com/www/screen-3.9.9-4.legacy.src.rpm > > MD5SUM https://mail.codegrinder.com/www/screen-md5sums.asc > > > > The 7.3 rpms work for me.. I don't have a 7.2 box available to test that > > one. > > > > The default in 7.3 is to not suid the screen binary, so I think we're > > safe from privilege escalation (unless the user does it of their own > > volition). But, I am a bit concerned with the idea that someone could > > hijack my screen session. So, is this a patch we want to push? If so, > > we should patch the RH8 rpms as well. RH hasn't yet released a patch > > for 9, though it has a vulnerable version. > > > > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lists at unbeatenpath.net Wed Jan 7 16:46:29 2004 From: lists at unbeatenpath.net (Cameron Moore) Date: Wed, 7 Jan 2004 10:46:29 -0600 Subject: OT: Apt and the kernel In-Reply-To: <20040107072906.GA30593@neu.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Wed, Jan 07, 2004 at 08:29:06AM +0100 References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> <20040107072906.GA30593@neu.nirvana> Message-ID: <20040107104629.A5290@unbeatenpath.net> * Axel.Thimm at physik.fu-berlin.de (Axel Thimm) [2004.01.07 01:30]: > On Tue, Jan 06, 2004 at 07:48:56PM -1000, Warren Togami wrote: > > Cameron Moore wrote: > > >How about another dumb question? Okay, here goes... > > > > > >Apt never seems to notice that a new kernel package is available for > > >updating -- I have to explicitly list the available kernel packages and > > >install the new one. Is this a bug or a feature? In either case, is > > >there a way to fix this annoying behavior? I've seen it happen before > > >on a different package, but I don't recall what it was. Thanks > > > > That is older apt, and apt from FreshRPMS and other paackagers. > > What? Where did you pick that one up? ATrpms is deploying apt > 0.5.15cnc5 for quite many repos (and all RH dists for RH7.3 to FC1 > BTW), is obviously the latest and still does not upgrade kernels by > default, which is a matter of policy, neither bug, nor > feature. Personally I am fine with forcing the user to chose a kernel, > since this is probably the perfect example of not using plain stupid > EVR upgrade paths. Sorry, I failed to mention what was in my previous thread: I've been using FreshRPMS which distributes apt-0.5.5cnc5. Thanks -- Cameron Moore -rw-r--r-- 1 cameron users 8 Oct 4 19:41 .signature From jkeating at j2solutions.net Wed Jan 7 17:33:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Jan 2004 09:33:07 -0800 Subject: screen buffer overflow In-Reply-To: <20040107042213.GK3353@codegrinder.com> References: <20040107042213.GK3353@codegrinder.com> Message-ID: <200401070933.12168.jkeating@j2solutions.net> On Tuesday 06 January 2004 20:22, Jason wrote: > The 7.3 rpms work for me.. I don't have a 7.2 box available to test > that one. > > The default in 7.3 is to not suid the screen binary, so I think we're > safe from privilege escalation (unless the user does it of their own > volition). But, I am a bit concerned with the idea that someone > could hijack my screen session. So, is this a patch we want to push? > If so, we should patch the RH8 rpms as well. RH hasn't yet released > a patch for 9, though it has a vulnerable version. Since I use screen daily on a 7.3 box, this is a fairly important one to me. I'd like to see it fixed for 8 as well. Hopefully I'll have a 7.2 box up to test tonight although it may have to wait for a harddrive ): Do you have a way of testing the overflow, or are we just testing functionality of screen once this patch is added? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Wed Jan 7 17:36:27 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Jan 2004 09:36:27 -0800 Subject: Backporting policy In-Reply-To: <20040107075522.GB30593@neu.nirvana> References: <20040107075522.GB30593@neu.nirvana> Message-ID: <200401070936.27229.jkeating@j2solutions.net> On Tuesday 06 January 2004 23:55, Axel Thimm wrote: > The latter method is something most external repos do. For instance > ATrpms provides upgraded, not backported (!) versions of rpm, yum and > apt for RH7.3 upwards. Again I don't think that should be legacy's > mode of operation. I expect highly conservative methods > here. Otherwise you could just as good submit packages to ATrpms. Backporting has been the goal since day 1 for previous RHL releases. FC releases is still in the air. RH will not focus so much on backports for FC updates, rather they'll go the route of new packages. How should Legacy respond to this? As for RHL releases, backporting is absolutely the goal. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pearcec at commnav.com Wed Jan 7 17:44:35 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 7 Jan 2004 17:44:35 GMT Subject: screen buffer overflow Message-ID: <43642.209.50.130.84.1073497475.commnav@home.commnav.com> Jason claimed testing the vulnerability was not trivial. I am not certain. We can come up with RedHat 8 packages. I can put one together right now. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > On Tuesday 06 January 2004 20:22, Jason wrote: > > The 7.3 rpms work for me.. I don't have a 7.2 box available to test > > that one. > > > > The default in 7.3 is to not suid the screen binary, so I think we're > > safe from privilege escalation (unless the user does it of their own > > volition). But, I am a bit concerned with the idea that someone > > could hijack my screen session. So, is this a patch we want to push? > > If so, we should patch the RH8 rpms as well. RH hasn't yet released > > a patch for 9, though it has a vulnerable version. > > Since I use screen daily on a 7.3 box, this is a fairly important one to > me. I'd like to see it fixed for 8 as well. Hopefully I'll have a 7.2 > box up to test tonight although it may have to wait for a harddrive ): > > Do you have a way of testing the overflow, or are we just testing > functionality of screen once this patch is added? > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating From pearcec at commnav.com Wed Jan 7 18:38:53 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 7 Jan 2004 18:38:53 GMT Subject: screen buffer overflow Message-ID: <43748.209.50.130.84.1073500733.commnav@home.commnav.com> I updated the screen bug with a RedHat 8.0 package. I added rh80 to the keywords. I had to add the autoconf213 to the BuildRequires line. I am working on the ethereal packages based on the RedHat 9 release. -- Christian Pearce http://www.commnav.com "Christian Pearce" said: > > Jason claimed testing the vulnerability was not trivial. I am not certain. We can come up with RedHat 8 packages. I can put one together right now. > > -- > Christian Pearce > http://www.commnav.com > > > > Jesse Keating said: > > > > On Tuesday 06 January 2004 20:22, Jason wrote: > > > The 7.3 rpms work for me.. I don't have a 7.2 box available to test > > > that one. > > > > > > The default in 7.3 is to not suid the screen binary, so I think we're > > > safe from privilege escalation (unless the user does it of their own > > > volition). But, I am a bit concerned with the idea that someone > > > could hijack my screen session. So, is this a patch we want to push? > > > If so, we should patch the RH8 rpms as well. RH hasn't yet released > > > a patch for 9, though it has a vulnerable version. > > > > Since I use screen daily on a 7.3 box, this is a fairly important one to > > me. I'd like to see it fixed for 8 as well. Hopefully I'll have a 7.2 > > box up to test tonight although it may have to wait for a harddrive ): > > > > Do you have a way of testing the overflow, or are we just testing > > functionality of screen once this patch is added? > > > > -- > > Jesse Keating RHCE MCSE (geek.j2solutions.net) > > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > > Mondo DevTeam (www.mondorescue.org) > > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > > Was I helpful? Let others know: > > http://svcs.affero.net/rm.php?r=jkeating > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rohwedde at codegrinder.com Wed Jan 7 19:16:07 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 7 Jan 2004 13:16:07 -0600 Subject: screen buffer overflow In-Reply-To: <200401070933.12168.jkeating@j2solutions.net> References: <20040107042213.GK3353@codegrinder.com> <200401070933.12168.jkeating@j2solutions.net> Message-ID: <20040107191607.GN3353@codegrinder.com> Testing requires sending about 2-3gb of escaped semicolon's to screen.. and then inserting executable code into the right location in memory to take advantage.. I haven't seen a published bit of exploit code for it. I'm fine with just functional testing, the patch is very straightforward if you'd like to take a look. -j On Wed, Jan 07, 2004 at 09:33:07AM -0800, Jesse Keating wrote: Content-Description: signed data > On Tuesday 06 January 2004 20:22, Jason wrote: > > The 7.3 rpms work for me.. I don't have a 7.2 box available to test > > that one. > > > > The default in 7.3 is to not suid the screen binary, so I think we're > > safe from privilege escalation (unless the user does it of their own > > volition). But, I am a bit concerned with the idea that someone > > could hijack my screen session. So, is this a patch we want to push? > > If so, we should patch the RH8 rpms as well. RH hasn't yet released > > a patch for 9, though it has a vulnerable version. > > Since I use screen daily on a 7.3 box, this is a fairly important one to > me. I'd like to see it fixed for 8 as well. Hopefully I'll have a 7.2 > box up to test tonight although it may have to wait for a harddrive ): > > Do you have a way of testing the overflow, or are we just testing > functionality of screen once this patch is added? > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at physik.fu-berlin.de Wed Jan 7 19:30:11 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 7 Jan 2004 20:30:11 +0100 Subject: Backporting policy In-Reply-To: <200401070936.27229.jkeating@j2solutions.net> References: <20040107075522.GB30593@neu.nirvana> <200401070936.27229.jkeating@j2solutions.net> Message-ID: <20040107193011.GA7562@neu.nirvana> On Wed, Jan 07, 2004 at 09:36:27AM -0800, Jesse Keating wrote: > Backporting has been the goal since day 1 for previous RHL releases. > FC releases is still in the air. RH will not focus so much on > backports for FC updates, rather they'll go the route of new > packages. How should Legacy respond to this? A good question. Upstream updating and guaranteeing stable API/ABIs are contraditory. FC1 is not dead yet, so I suggest to address these questions when FC1 is about to EOL. One should examine the then existing interest groups and the given available options. > As for RHL releases, backporting is absolutely the goal. Glad to hear that. -- Axel.Thimm at physik.fu-berlin.de -------------- 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 physik.fu-berlin.de Thu Jan 8 00:02:35 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Thu, 8 Jan 2004 01:02:35 +0100 Subject: OT: Apt and the kernel In-Reply-To: References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> <20040107072906.GA30593@neu.nirvana> Message-ID: <20040108000235.GI11093@neu.nirvana> On Wed, Jan 07, 2004 at 10:25:02AM +0200, Panu Matilainen wrote: > On Wed, 7 Jan 2004, Axel Thimm wrote: > > On Tue, Jan 06, 2004 at 07:48:56PM -1000, Warren Togami wrote: > > > Cameron Moore wrote: > > > >How about another dumb question? Okay, here goes... > > > > > > > >Apt never seems to notice that a new kernel package is available for > > > >updating -- I have to explicitly list the available kernel packages and > > > >install the new one. Is this a bug or a feature? In either case, is > > > >there a way to fix this annoying behavior? I've seen it happen before > > > >on a different package, but I don't recall what it was. Thanks > > > > > > That is older apt, and apt from FreshRPMS and other paackagers. > > > > What? Where did you pick that one up? ATrpms is deploying apt > > 0.5.15cnc5 for quite many repos (and all RH dists for RH7.3 to FC1 > > BTW), is obviously the latest and still does not upgrade kernels by > > default, which is a matter of policy, neither bug, nor > > feature. Personally I am fine with forcing the user to chose a kernel, > > since this is probably the perfect example of not using plain stupid > > EVR upgrade paths. > > "older apt" in context of fedora.us. The current apt in fedora.us testing > repository has a Lua script which automatically offers to "upgrade" > (==install latest version alongside) any packages in allow-duplicated. The > apt in fedora.us "always" had kernel-upgrade script taking care of just > the kernel but it wasn't turned on by default. The upgradevirt.lua > (http://laiskiainen.org/apt/lua/upgrade-virtual/) script handles not only > kernel but any allow-duplicated pkgs *and* is turned on by default in the > latest packages. Thanks, that explains it a bit better. While AllowDuplicates is not a kernel reserved entity, I personally prefer to choose kernels. For example in the upcoming transition phase form 2.4 to 2.6 I wouldn't like to have 2.6 installed on some machines. > > > apt from fedora.us (soon to be published for Legacy too) is totally > > > not made to be used for automated upgrades like some people > > > currently use yum. As a result, our apt is set to offer to upgrade > > > to the latest kernel if it is available. > > > > You mean apt from fedora.us will require interactive sessions? I don't > > believe Panu would permit castrating his work like that ;) > > I don't quite follow what Warren is saying there either :) No reason why > apt couldn't be used for automated upgrades like with yum cron job. Well, that's our Warren ;) -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pearcec at commnav.com Thu Jan 8 00:04:06 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 8 Jan 2004 00:04:06 GMT Subject: I updated ethereal and screen for RedHat 8.0 Message-ID: <44311.209.50.130.84.1073520246.commnav@home.commnav.com> I built packages. The comment in the bug should explain everything. Please QA! https://bugzilla.fedora.us/show_bug.cgi?id=1193 I never signed screen for Red Hat 8.0. I will get to that tomorrow. I have to roll. -- Christian Pearce http://www.commnav.com From cra at WPI.EDU Thu Jan 8 00:24:22 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 7 Jan 2004 19:24:22 -0500 Subject: Legacy packages in need of QA Message-ID: <20040108002422.GK12322@angus.ind.WPI.EDU> Please help us with QA for these packages so we can get them published soon. apt for 7.x https://bugzilla.fedora.us/show_bug.cgi?id=1174 yum for 7.x https://bugzilla.fedora.us/show_bug.cgi?id=1176 fedora-rpmdevtools for 7.x https://bugzilla.fedora.us/show_bug.cgi?id=1175 mpg321 security patch https://bugzilla.fedora.us/show_bug.cgi?id=1186 screen security patch https://bugzilla.fedora.us/show_bug.cgi?id=1187 ethereal security patch https://bugzilla.fedora.us/show_bug.cgi?id=1193 Here's how to get started: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Thanks. From warren at togami.com Thu Jan 8 00:31:50 2004 From: warren at togami.com (Warren Togami) Date: Wed, 07 Jan 2004 14:31:50 -1000 Subject: OT: Apt and the kernel In-Reply-To: <20040108000235.GI11093@neu.nirvana> References: <20040106225553.B1609@unbeatenpath.net> <3FFB9DC8.6030507@togami.com> <20040107072906.GA30593@neu.nirvana> <20040108000235.GI11093@neu.nirvana> Message-ID: <3FFCA4F6.4070105@togami.com> Axel Thimm wrote: >>>>apt from fedora.us (soon to be published for Legacy too) is totally >>>>not made to be used for automated upgrades like some people >>>>currently use yum. As a result, our apt is set to offer to upgrade >>>>to the latest kernel if it is available. >>> >>>You mean apt from fedora.us will require interactive sessions? I don't >>>believe Panu would permit castrating his work like that ;) >> >>I don't quite follow what Warren is saying there either :) No reason why >>apt couldn't be used for automated upgrades like with yum cron job. > > > Well, that's our Warren ;) I meant default settings. Of course it can be reconfigured to do automatic updates should the user desire it. Warren From rostetter at mail.utexas.edu Thu Jan 8 01:37:59 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 7 Jan 2004 19:37:59 -0600 Subject: Backporting policy In-Reply-To: <200401070936.27229.jkeating@j2solutions.net> References: <20040107075522.GB30593@neu.nirvana> <200401070936.27229.jkeating@j2solutions.net> Message-ID: <20040107193759.fvkgo0gocsg8s4cg@mail.ph.utexas.edu> Quoting Jesse Keating : > Backporting has been the goal since day 1 for previous RHL releases. FC Yes, and should stay that way. There are exceptions, but these should be very few... > releases is still in the air. RH will not focus so much on backports > for FC updates, rather they'll go the route of new packages. How > should Legacy respond to this? They should backport as much as possible, but at the point that it becomes too much of a burden to backport then an update would be appropriate. For RHL, the backport is paramount, even if it means a lot of work to do so. For Fedora, we should consider the amount of work to backport versus the stability of an upgrade, and pick which way to go based on the ratio of work to stability. -- Eric Rostetter From skvidal at phy.duke.edu Thu Jan 8 01:34:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 07 Jan 2004 20:34:51 -0500 Subject: Legacy packages in need of QA In-Reply-To: <20040108002422.GK12322@angus.ind.WPI.EDU> References: <20040108002422.GK12322@angus.ind.WPI.EDU> Message-ID: <1073525691.10087.9.camel@binkley> On Wed, 2004-01-07 at 19:24, Charles R. Anderson wrote: > Please help us with QA for these packages so we can get them published > soon. > > apt for 7.x > https://bugzilla.fedora.us/show_bug.cgi?id=1174 > > yum for 7.x > https://bugzilla.fedora.us/show_bug.cgi?id=1176 > > fedora-rpmdevtools for 7.x > https://bugzilla.fedora.us/show_bug.cgi?id=1175 > > mpg321 security patch > https://bugzilla.fedora.us/show_bug.cgi?id=1186 > > screen security patch > https://bugzilla.fedora.us/show_bug.cgi?id=1187 > > ethereal security patch > https://bugzilla.fedora.us/show_bug.cgi?id=1193 > > Here's how to get started: > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > If you'd like to submit them, please take the cvs packages from: http://linux.duke.edu/~skvidal/RPMS/cvs/ they are built for 7.x but the patch should work for 8.x too. I'm kinda tied up with some other things or I'd do them. Thanks -sv From ms-nospam-0306 at arcor.de Thu Jan 8 02:19:43 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 8 Jan 2004 03:19:43 +0100 Subject: Legacy packages in need of QA In-Reply-To: <20040108002422.GK12322@angus.ind.WPI.EDU> References: <20040108002422.GK12322@angus.ind.WPI.EDU> Message-ID: <20040108031943.325f01f3.ms-nospam-0306@arcor.de> On Wed, 7 Jan 2004 19:24:22 -0500, Charles R. Anderson wrote: > Please help us with QA for these packages so we can get them published > soon. > > yum for 7.x > https://bugzilla.fedora.us/show_bug.cgi?id=1176 With the previous work on this one and your own QA, these should be easy to review and approve and ideal for people who are new to the system. This one has one publish vote already. > mpg321 security patch > https://bugzilla.fedora.us/show_bug.cgi?id=1186 The patch is straight-forward to review, syntactically and semantically correct and does not introduce any compilation issues. Anyone with access to a rh72 or rh73 machine and Red Hat's last src.rpm could verify it. My question here is that this reintroduces mp3 software to the fedora.us system. How's that dealt with? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Thu Jan 8 03:46:12 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 7 Jan 2004 22:46:12 -0500 Subject: Legacy packages in need of QA In-Reply-To: <20040108031943.325f01f3.ms-nospam-0306@arcor.de> References: <20040108002422.GK12322@angus.ind.WPI.EDU> <20040108031943.325f01f3.ms-nospam-0306@arcor.de> Message-ID: <20040108034612.GL12322@angus.ind.WPI.EDU> On Thu, Jan 08, 2004 at 03:19:43AM +0100, Michael Schwendt wrote: > My question here is that this reintroduces mp3 software to the fedora.us > system. How's that dealt with? If it is a problem now, then it has been a problem all along, since any site that has 7.3 or older has mp3 software: http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.os/mpg321-0.2.9-3.i386.rpm From admin at cs.montana.edu Thu Jan 8 05:24:35 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 7 Jan 2004 22:24:35 -0700 (MST) Subject: sources.list entry for 7.3 client Message-ID: <51773.153.90.199.141.1073539475.squirrel@www.cs.montana.edu> Perhaps I missed this information. Is this correct sources.list entry for a 7.3 client using fedora-legacy? rpm http://download.fedora.us/fedora redhat/7.3/i386 os updates Mabe I am stumbling around in the dark, but we have have tier 2 mirros to use also? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From warren at togami.com Thu Jan 8 05:33:29 2004 From: warren at togami.com (Warren Togami) Date: Wed, 07 Jan 2004 19:33:29 -1000 Subject: sources.list entry for 7.3 client In-Reply-To: <51773.153.90.199.141.1073539475.squirrel@www.cs.montana.edu> References: <51773.153.90.199.141.1073539475.squirrel@www.cs.montana.edu> Message-ID: <3FFCEBA9.2040406@togami.com> Lucas Albers wrote: > Perhaps I missed this information. > Is this correct sources.list entry for a 7.3 client using fedora-legacy? > > rpm http://download.fedora.us/fedora redhat/7.3/i386 os updates > > Mabe I am stumbling around in the dark, but we have have tier 2 mirros to > use also? rpm http://download.fedora.us/fedora redhat/7.3/i386 os updates legacy http://www.fedora.us/wiki/FedoraMirrorList Many of the mirrors listed here may have the 7.2 and 7.3 repositories. Warren From cra at WPI.EDU Thu Jan 8 05:40:20 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 8 Jan 2004 00:40:20 -0500 Subject: sources.list entry for 7.3 client In-Reply-To: <51773.153.90.199.141.1073539475.squirrel@www.cs.montana.edu> References: <51773.153.90.199.141.1073539475.squirrel@www.cs.montana.edu> Message-ID: <20040108054020.GB13188@angus.ind.WPI.EDU> On Wed, Jan 07, 2004 at 10:24:35PM -0700, Lucas Albers wrote: > Perhaps I missed this information. > Is this correct sources.list entry for a 7.3 client using fedora-legacy? This package should be configured properly. Please help test it so it can be published: > apt for 7.x > https://bugzilla.fedora.us/show_bug.cgi?id=1174 There is a nifty mirror selector script in there too. From pearcec at commnav.com Thu Jan 8 13:28:04 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 8 Jan 2004 13:28:04 GMT Subject: Backporting policy Message-ID: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> Interesting. I backported ethereal yesterday, even though RHL9 was an upgrade. I can't believe they did that. I generated a patch myself from CVS. I believe everything works fine, I still need QA and testing to be done. I was originally going to just do what RedHat did. I thought the policy was to follow their lead. But I was encouraged on the IRC Channel to backport. It turned out to be easier than I thought. Personally this is problably the best way to go. People who are not moving forward with the newer releases probably don't have time to test upgrades of systems they don't want to touch. Therefore would appreciate the updates not containing newer versions. Considering newer version can introduce unwanted change. If they want the newer versions then they would already be on the newer release of Fedora Core. Does this make sense? My vote is backport backport backport. And I am willing to package and QA to back that statement up. I believe once Fedora Legacy hits a decents stride with backporting it will make sense for use to stay in the groove. Rather than shifting gears towards updating to newer versions from Fedora Core (x). Although I admit it might be nice not to have to duplicate work. I think taking a new rpm form a newer distribution and sticking it in an old will create major headaches though. But maybe that wasn't exactly what was intended. -- Christian Pearce http://www.commnav.com Eric Rostetter said: > > Quoting Jesse Keating : > > > Backporting has been the goal since day 1 for previous RHL releases. FC > > Yes, and should stay that way. There are exceptions, but these should be > very few... > > > releases is still in the air. RH will not focus so much on backports > > for FC updates, rather they'll go the route of new packages. How > > should Legacy respond to this? > > They should backport as much as possible, but at the point that it becomes > too much of a burden to backport then an update would be appropriate. For > RHL, the backport is paramount, even if it means a lot of work to do so. > For Fedora, we should consider the amount of work to backport versus the > stability of an upgrade, and pick which way to go based on the ratio of > work to stability. > > -- > Eric Rostetter > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From pearcec at commnav.com Thu Jan 8 13:50:58 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 8 Jan 2004 13:50:58 GMT Subject: Signed screen for RedHat 80 Message-ID: <44697.209.50.130.84.1073569858.commnav@home.commnav.com> I signed the src rpm I created. I updated the bug #1187. -- Christian Pearce http://www.commnav.com From cra at WPI.EDU Thu Jan 8 15:37:02 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 8 Jan 2004 10:37:02 -0500 Subject: Backporting policy In-Reply-To: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> Message-ID: <20040108153702.GD13188@angus.ind.WPI.EDU> On Thu, Jan 08, 2004 at 01:28:04PM +0000, Christian Pearce wrote: > Interesting. I backported ethereal yesterday, even though RHL9 was > an upgrade. I can't believe they did that. I generated a patch > myself from CVS. I believe everything works fine, I still need QA > and testing to be done. I think it is a myth that all Red Hat updates are backports. Ethereal has always been upgraded rather than backported: ethereal-0.9.11-0.90.1.src.rpm ethereal-0.9.13-1.90.1.src.rpm ethereal-0.9.16-0.90.1.src.rpm ethereal-0.10.0a-0.90.1.src.rpm I actually preferred this for ethereal, since I like getting the new features :) Also, API changes are not really a concern with ethereal. From lowen at pari.edu Thu Jan 8 16:23:14 2004 From: lowen at pari.edu (Lamar Owen) Date: Thu, 8 Jan 2004 11:23:14 -0500 Subject: Backporting policy In-Reply-To: <20040108153702.GD13188@angus.ind.WPI.EDU> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> Message-ID: <200401081123.14109.lowen@pari.edu> On Thursday 08 January 2004 10:37 am, Charles R. Anderson wrote: > I think it is a myth that all Red Hat updates are backports. Ethereal > has always been upgraded rather than backported: It was and is on a case-by-case basis, with the Red Hat maintainers calling the shots for their individual packages. Red Hat did massive backporting fixes for PostgreSQL, for instance, where one cannot just upgrade to the next upstream version (and it is an example of what upstream developers think about backporting patches). If a major security flaw occured in the version of PostgreSQL that shipped with Red Hat 7.3, the likelihood of getting the upstream developers to patch that version is slim to none, and Slim just left town. Backporting the fix would not be trivial and might even require the resources of a PostgreSQL Core developer (which Red Hat has in the person of Tom Lane). That update (which at the time went all the way back to RHL 6.2, which has PostgreSQL 6.5.x, which is absolutely archaic by PostgreSQL standards (we're at 7.4.1 now!)) took _months_ for Red Hat to get out. XFree86, the Kernel, and a few other packages are in the same boat where someone with the real know-how to backport fixes will be required. Or press the RHEL 2.1 update source RPMs into service (which might work OK for RHL 7.2 and 7.3 for non-kernel patches). This is why Red Hat EOL'd these older distributions: they require massive resources to backport fixes where the upstream developers have no interest. Do we really understand the implications of things like the recent kernel vulnerability? The fix is in 2.4.24, but upgrading to kernel 2.4.24 might be out of the question for RHL 7.3, for instance, due to other dependencies. But then you run in to other issues. Let's take PostgreSQL as an example again. Suppose the only way to fix the issue is by forcing a major version upgrade. That's a massive undertaking for the user anyway, depending upon the version delta, but let's ignore that for a moment. The PostgreSQL developers are not static in their use of versions of things like autoconf, lex, and bison: they do update the build requirements periodically. A major PostgreSQL update may not even compile on the targeted EOL distribution. So it might pull in massive amounts of updates for the building tools. One can easily get into circular dependencies that basically require a complete dist upgrade. Right now, I am having a pretty sizable headache keeping the latest and greatest PostgreSQL working on older stuff. We go back as far as Red Hat 6.2 at the moment, but that could change at any time. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From pearcec at commnav.com Thu Jan 8 18:52:44 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 8 Jan 2004 18:52:44 GMT Subject: Backporting policy Message-ID: <47871.209.50.130.84.1073587964.commnav@home.commnav.com> I guess this is the challenge. Sometimes moving forward will suck or be easy. And sometimes backporting with suck or be easy. And in some case they both are easy or suck at the same time. Fun. I am reminded of the Far side cartoon. The sign reads on one door, "Damned if you do." The sign reads on the other door, "Damned if you don't." There are people in line in hell and the devil says, "Come on it is either one or the other." Let's strive for a policy of backporting. If we find ourselves in a position that it is easier to move forward so be it. If we find ourselves in hell, then the first person to solve the problem wins. -- Christian Pearce http://www.commnav.com Lamar Owen said: > > On Thursday 08 January 2004 10:37 am, Charles R. Anderson wrote: > > I think it is a myth that all Red Hat updates are backports. Ethereal > > has always been upgraded rather than backported: > > It was and is on a case-by-case basis, with the Red Hat maintainers calling > the shots for their individual packages. > > Red Hat did massive backporting fixes for PostgreSQL, for instance, where one > cannot just upgrade to the next upstream version (and it is an example of > what upstream developers think about backporting patches). If a major > security flaw occured in the version of PostgreSQL that shipped with Red Hat > 7.3, the likelihood of getting the upstream developers to patch that version > is slim to none, and Slim just left town. Backporting the fix would not be > trivial and might even require the resources of a PostgreSQL Core developer > (which Red Hat has in the person of Tom Lane). That update (which at the > time went all the way back to RHL 6.2, which has PostgreSQL 6.5.x, which is > absolutely archaic by PostgreSQL standards (we're at 7.4.1 now!)) took > _months_ for Red Hat to get out. > > XFree86, the Kernel, and a few other packages are in the same boat where > someone with the real know-how to backport fixes will be required. Or press > the RHEL 2.1 update source RPMs into service (which might work OK for RHL 7.2 > and 7.3 for non-kernel patches). > > This is why Red Hat EOL'd these older distributions: they require massive > resources to backport fixes where the upstream developers have no interest. > Do we really understand the implications of things like the recent kernel > vulnerability? The fix is in 2.4.24, but upgrading to kernel 2.4.24 might be > out of the question for RHL 7.3, for instance, due to other dependencies. > > But then you run in to other issues. Let's take PostgreSQL as an example > again. Suppose the only way to fix the issue is by forcing a major version > upgrade. That's a massive undertaking for the user anyway, depending upon > the version delta, but let's ignore that for a moment. The PostgreSQL > developers are not static in their use of versions of things like autoconf, > lex, and bison: they do update the build requirements periodically. A major > PostgreSQL update may not even compile on the targeted EOL distribution. So > it might pull in massive amounts of updates for the building tools. One can > easily get into circular dependencies that basically require a complete dist > upgrade. > > Right now, I am having a pretty sizable headache keeping the latest and > greatest PostgreSQL working on older stuff. We go back as far as Red Hat 6.2 > at the moment, but that could change at any time. > -- > Lamar Owen > Director of Information Technology > Pisgah Astronomical Research Institute > 1 PARI Drive > Rosman, NC 28772 > (828)862-5554 > www.pari.edu > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From seyman at wanadoo.fr Thu Jan 8 19:41:57 2004 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Thu, 8 Jan 2004 20:41:57 +0100 Subject: Backporting policy In-Reply-To: <47871.209.50.130.84.1073587964.commnav@home.commnav.com> References: <47871.209.50.130.84.1073587964.commnav@home.commnav.com> Message-ID: <20040108194157.GA6728@orient.maison.moi> On Thu, Jan 08, 2004 at 06:52:44PM +0000, Christian Pearce wrote: > > Let's strive for a policy of backporting. If we find ourselves in a position > that it is easier to move forward so be it. If we find ourselves in hell, > then the first person to solve the problem wins. +1 Emmanuel From warren at togami.com Thu Jan 8 23:54:47 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Jan 2004 13:54:47 -1000 Subject: LEGACY keyword search Message-ID: <3FFDEDC7.9070103@togami.com> http://www.fedora.us/LEGACY I added this convenient redirect so you can see the status of Legacy development with a simple URL. From warren at togami.com Fri Jan 9 00:00:23 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Jan 2004 14:00:23 -1000 Subject: Backporting policy In-Reply-To: <20040108153702.GD13188@angus.ind.WPI.EDU> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> Message-ID: <3FFDEF17.8040504@togami.com> Charles R. Anderson wrote: > On Thu, Jan 08, 2004 at 01:28:04PM +0000, Christian Pearce wrote: > >>Interesting. I backported ethereal yesterday, even though RHL9 was >>an upgrade. I can't believe they did that. I generated a patch >>myself from CVS. I believe everything works fine, I still need QA >>and testing to be done. > > > I think it is a myth that all Red Hat updates are backports. Ethereal > has always been upgraded rather than backported: > > ethereal-0.9.11-0.90.1.src.rpm > ethereal-0.9.13-1.90.1.src.rpm > ethereal-0.9.16-0.90.1.src.rpm > ethereal-0.10.0a-0.90.1.src.rpm > > I actually preferred this for ethereal, since I like getting the new > features :) Also, API changes are not really a concern with ethereal. I think we should also consider upgrading in cases where all of the following conditions are met: 1) Absolutely zero cases where API changes would effect any distribution OR 3rd party software, because the updated package is a leaf node on the dependency tree. I suspect screen may be another leaf node. 2) Where having a common %{version} across multiple distributions would make it easier to maintain security updates, because patches need not be ported and tested multiple times. 3) Only by consensus of the list membership. Thoughts? Warren From cra at WPI.EDU Fri Jan 9 00:04:19 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 8 Jan 2004 19:04:19 -0500 Subject: Backporting policy In-Reply-To: <3FFDEF17.8040504@togami.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: <20040109000419.GR12322@angus.ind.WPI.EDU> On Thu, Jan 08, 2004 at 02:00:23PM -1000, Warren Togami wrote: > I think we should also consider upgrading in cases where all of the > following conditions are met: > 1) Absolutely zero cases where API changes would effect any distribution > OR 3rd party software, because the updated package is a leaf node on the > dependency tree. I suspect screen may be another leaf node. > 2) Where having a common %{version} across multiple distributions would > make it easier to maintain security updates, because patches need not be > ported and tested multiple times. > 3) Only by consensus of the list membership. Sounds good to me. From warren at togami.com Fri Jan 9 00:15:08 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Jan 2004 14:15:08 -1000 Subject: updates-testing --> updates policy discussion Message-ID: <3FFDF28C.6030305@togami.com> http://www.fedora.us/LEGACY Now that we have a few potential security update packages, we must discuss the publish procedure. We cannot just go ahead and build everything that people submit and place it into the updates-testing repository. I suggest that we need at least one preliminary check to make sure the package is a proper Legacy update (not a wild version upgrade), proper patching, and not malicious. I suggest that we have two levels of approval, the first being necessary for "updates-testing". While in "updates-testing" we receive GPG clearsigned feedback. Perhaps further package patching will be necessary. Then after a certain threshold of positive feedback from we approve for "updates". But it matters who the feedback is from... http://www.fedora.us/wiki/PackageSubmissionQAPolicy We need to discuss how to change this procedure for Legacy specific packages. We also need to change the definition of "trusted" for Legacy specific packages, along with the requirements for reaching the "trusted" status. Thoughts? Warren From jkeating at j2solutions.net Fri Jan 9 01:13:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Jan 2004 17:13:36 -0800 Subject: Great new webdesign! Message-ID: <200401081713.41190.jkeating@j2solutions.net> Eric Rostetter has stepped up and done a great amount of work on getting our website functional. At my request he has emulated the fedora.redhat.com layout (with their approval) and populated the site with some good initial content. We'd like to get your feedback and hopefully some content submissions so that we can continue to improve the site as we go. Please have a look at http://www.fedoralegacy.org and let us know what you think! -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From sheltren at cs.ucsb.edu Fri Jan 9 01:28:28 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 8 Jan 2004 17:28:28 -0800 (PST) Subject: Great new webdesign! In-Reply-To: <200401081713.41190.jkeating@j2solutions.net> References: <200401081713.41190.jkeating@j2solutions.net> Message-ID: Looks good! Thanks to Eric for all the work. :) The green kinda makes me think of little leprachauns though... LOL I guess now we just need to get some more content up... Stuff transferred over from the wiki and whatnot. -Jeff On Thu, 8 Jan 2004, Jesse Keating wrote: > Eric Rostetter has stepped up and done a great amount of work on getting > our website functional. At my request he has emulated the > fedora.redhat.com layout (with their approval) and populated the site > with some good initial content. We'd like to get your feedback and > hopefully some content submissions so that we can continue to improve > the site as we go. Please have a look at http://www.fedoralegacy.org > and let us know what you think! > > From drees at greenhydrant.com Fri Jan 9 01:53:48 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 8 Jan 2004 17:53:48 -0800 (PST) Subject: Backporting policy In-Reply-To: <3FFDEF17.8040504@togami.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: <2154.208.48.139.163.1073613228.squirrel@www.greenhydrant.com> On Thu, January 8, 2004 at 4:00 pm, Warren Togami wrote: > > I think we should also consider upgrading in cases where all of the > following conditions are met: > 1) Absolutely zero cases where API changes would effect any distribution > OR 3rd party software, because the updated package is a leaf node on the > dependency tree. I suspect screen may be another leaf node. > 2) Where having a common %{version} across multiple distributions would > make it easier to maintain security updates, because patches need not be > ported and tested multiple times. > 3) Only by consensus of the list membership. > > Thoughts? Makes sense to me. If it means less work and no chance of breaking things, that means it's a win-win for everyone. -Dave From jkeating at j2solutions.net Fri Jan 9 02:00:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Jan 2004 18:00:47 -0800 Subject: Backporting policy In-Reply-To: <3FFDEF17.8040504@togami.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: <200401081800.47538.jkeating@j2solutions.net> On Thursday 08 January 2004 16:00, Warren Togami wrote: > I think we should also consider upgrading in cases where all of the > following conditions are met: > 1) Absolutely zero cases where API changes would effect any > distribution OR 3rd party software, because the updated package is a > leaf node on the dependency tree. I suspect screen may be another > leaf node. 2) Where having a common %{version} across multiple > distributions would make it easier to maintain security updates, > because patches need not be ported and tested multiple times. > 3) Only by consensus of the list membership. > > Thoughts? I think this fits perfectly. I'm willing to set this forth as a policy, which reminds me. On our website, under participate, we need a section for current policies, this being one of them, the package naming being another, etc... -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From lowen at pari.edu Fri Jan 9 02:14:35 2004 From: lowen at pari.edu (Lamar Owen) Date: Thu, 8 Jan 2004 21:14:35 -0500 Subject: Backporting policy In-Reply-To: <3FFDEF17.8040504@togami.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: <200401082114.35392.lowen@pari.edu> On Thursday 08 January 2004 07:00 pm, Warren Togami wrote: > I think we should also consider upgrading in cases where all of the > following conditions are met: > 1) Absolutely zero cases where API changes would effect any distribution > OR 3rd party software, because the updated package is a leaf node on the > dependency tree. I suspect screen may be another leaf node. > 2) Where having a common %{version} across multiple distributions would > make it easier to maintain security updates, because patches need not be > ported and tested multiple times. > 3) Only by consensus of the list membership. I can agree with that, particularly the last point. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From pearcec at commnav.com Fri Jan 9 02:19:04 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 9 Jan 2004 02:19:04 GMT Subject: Backporting policy Message-ID: <3434.66.92.232.244.1073614744.commnav@home.commnav.com> I am happy with too. It is different from what I suggested, but I think this criteria is fine. So ethereal could have been upgraded. I wonder how often this will happen. And what is "consensus". I don't want security updates to drag out because people who don't like this policy in the first place are going to stand in the way. I guess the guys doing the packaging and the QA have the most say. Everyone else can pound sand. =) -- Christian Pearce http://www.commnav.com Jesse Keating said: > > On Thursday 08 January 2004 16:00, Warren Togami wrote: > > I think we should also consider upgrading in cases where all of the > > following conditions are met: > > 1) Absolutely zero cases where API changes would effect any > > distribution OR 3rd party software, because the updated package is a > > leaf node on the dependency tree. I suspect screen may be another > > leaf node. 2) Where having a common %{version} across multiple > > distributions would make it easier to maintain security updates, > > because patches need not be ported and tested multiple times. > > 3) Only by consensus of the list membership. > > > > Thoughts? > > I think this fits perfectly. I'm willing to set this forth as a policy, > which reminds me. On our website, under participate, we need a section > for current policies, this being one of them, the package naming being > another, etc... > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating From pearcec at commnav.com Fri Jan 9 02:22:43 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 9 Jan 2004 02:22:43 GMT Subject: Great new webdesign! Message-ID: <3585.66.92.232.244.1073614963.commnav@home.commnav.com> Thanks Eric. Looks clean. Who is going to be the maintainer? -- Christian Pearce http://www.commnav.com Jesse Keating said: > > Eric Rostetter has stepped up and done a great amount of work on getting > our website functional. At my request he has emulated the > fedora.redhat.com layout (with their approval) and populated the site > with some good initial content. We'd like to get your feedback and > hopefully some content submissions so that we can continue to improve > the site as we go. Please have a look at http://www.fedoralegacy.org > and let us know what you think! > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating From pearcec at commnav.com Fri Jan 9 02:28:39 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 9 Jan 2004 02:28:39 GMT Subject: VenderSec? Message-ID: <3657.66.92.232.244.1073615319.commnav@home.commnav.com> Seems important one of us gets on this list. Which also raises an issue of how to we get that information and use it without leaking. Certainly in an open mailing list forum like this people can see what we are planning to release. Yet we need to community of QA and Packagers to get the job done. Does this mean we need to form a secret society for Fedora Legacy? :P Seriously I think it would be awesome to have some lead time. As it is we are going to be slower to the draw because we need some consensus of what to do, packaging, QA process more complicated than normal do to trust issues, and the PUBLISHing. What do we have in mind? -- Christian Pearce http://www.commnav.com From rostetter at mail.utexas.edu Fri Jan 9 02:45:51 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 8 Jan 2004 20:45:51 -0600 Subject: Great new webdesign! In-Reply-To: <3585.66.92.232.244.1073614963.commnav@home.commnav.com> References: <3585.66.92.232.244.1073614963.commnav@home.commnav.com> Message-ID: <20040108204551.t5o7ew38kw4cc8ow@mail.ph.utexas.edu> Quoting Christian Pearce : > Thanks Eric. Looks clean. Who is going to be the maintainer? > > -- > Christian Pearce > http://www.commnav.com Myself and anyone else who wants to help. ;) -- Eric Rostetter From warren at togami.com Fri Jan 9 03:05:55 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Jan 2004 17:05:55 -1000 Subject: mpg321 decision needed Message-ID: <3FFE1A93.8090100@togami.com> https://bugzilla.fedora.us/show_bug.cgi?id=1186 mpg321 proposed Legacy update Due to licensing issues with anything related to MP3, after some discussions it seems that we cannot issue an update for this package. It was suggested that Legacy should publish an update notification recommending that users stop using it, or even remove the package. This is a certainty. What we must decide upon is whether we should also issue a mpg321 package update that removes MP3 functionality. This is only to force the vulnerable program to uninstall from systems. I personally am in favor of this option, but please discuss the pros & cons. A package update may be necessary because IIRC mpg321 is Required by other packages in RH7.x, meaning removing mpg321 may be an infeasible suggestion in the update notification. Please somebody check on this and report back. I personally feel that removing mpg321 or crippling its functionality in Legacy is not much of a loss, since the majority of Legacy users are servers. Maybe some businesses use Legacy for workstations, but think of a broken MP3 decoder as productivity gain? =) Warren From skvidal at phy.duke.edu Fri Jan 9 03:12:23 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jan 2004 22:12:23 -0500 Subject: mpg321 decision needed In-Reply-To: <3FFE1A93.8090100@togami.com> References: <3FFE1A93.8090100@togami.com> Message-ID: <1073617943.11868.5.camel@binkley> > A package update may be necessary because IIRC mpg321 is Required by > other packages in RH7.x, meaning removing mpg321 may be an infeasible > suggestion in the update notification. Please somebody check on this > and report back. > > I personally feel that removing mpg321 or crippling its functionality in > Legacy is not much of a loss, since the majority of Legacy users are > servers. Maybe some businesses use Legacy for workstations, but think > of a broken MP3 decoder as productivity gain? =) It's not about business it's about screwing somebody up and surprising them when the legacy repository breaks something on their system which used to work. What if this program were something to do with mail processing that suddenly became legally complicated to update? You wouldn't just break someone's mail system? So it's just mp3 playing but we shouldn't surprise people with the change. I recommend issuing a comment about mp3 players and libraries being deprecated and legal reasons make them impossible to be updated. Last I checked this particular vulnerability isn't all that nasty anyway. Let people know that there is a vulnerability and that we can't patch it. They can discover the patches/fixes for themselves. Heck, maybe some enterprising young soul will drop an anvil on that particular bug and squash it. :) -sv From cra at WPI.EDU Fri Jan 9 03:25:18 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 8 Jan 2004 22:25:18 -0500 Subject: mpg321 decision needed In-Reply-To: <1073617943.11868.5.camel@binkley> References: <3FFE1A93.8090100@togami.com> <1073617943.11868.5.camel@binkley> Message-ID: <20040109032518.GG13188@angus.ind.WPI.EDU> I don't understand how issuing an update for mpg321 is any different legally than distributing the original mpg321 from the distro in question... If we cannot make an update, then shouldn't we not be distributing the original package too? If it is really this much of a problem, how about distributing rhmask files or binary deltas as discussed in fedora-devel-list? From smoogen at lanl.gov Fri Jan 9 03:35:10 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 8 Jan 2004 20:35:10 -0700 (MST) Subject: mpg321 decision needed In-Reply-To: <20040109032518.GG13188@angus.ind.WPI.EDU> Message-ID: On Thu, 8 Jan 2004, Charles R. Anderson wrote: >I don't understand how issuing an update for mpg321 is any different >legally than distributing the original mpg321 from the distro in I think there is a 'we wont sue over old things' agreement that has been made between the patent holders and various people. That basically means that its ok to keep old broken crap out.. just dont fix it, update it, etc. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From rohwedde at codegrinder.com Fri Jan 9 04:35:19 2004 From: rohwedde at codegrinder.com (Jason) Date: Thu, 8 Jan 2004 22:35:19 -0600 Subject: mpg321 decision needed In-Reply-To: <3FFE1A93.8090100@togami.com> References: <3FFE1A93.8090100@togami.com> Message-ID: <20040109043519.GS3353@codegrinder.com> > What we must decide upon is whether we should also issue a mpg321 > package update that removes MP3 functionality. This is only to force > the vulnerable program to uninstall from systems. I personally am in > favor of this option, but please discuss the pros & cons. > > A package update may be necessary because IIRC mpg321 is Required by > other packages in RH7.x, meaning removing mpg321 may be an infeasible > suggestion in the update notification. Please somebody check on this > and report back. > > I personally feel that removing mpg321 or crippling its functionality in > Legacy is not much of a loss, since the majority of Legacy users are > servers. Maybe some businesses use Legacy for workstations, but think > of a broken MP3 decoder as productivity gain? =) It should be safe for the user to remove mpg321: [rohwedde at fungo rohwedde]$ rpm -q --whatrequires mpg123 mpg321 no package requires mpg123 no package requires mpg321 But, I certainly don't think we have the right to remove software from someone's machine.. Whether they be in some sort of legal violation or not. I think releasing a statement suggesting removal of the offending software is certainly a responsible alternative for these situations. -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Fri Jan 9 05:15:14 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 9 Jan 2004 00:15:14 -0500 Subject: mpg321 decision needed In-Reply-To: <20040109043519.GS3353@codegrinder.com> References: <3FFE1A93.8090100@togami.com> <20040109043519.GS3353@codegrinder.com> Message-ID: <20040109051514.GH13188@angus.ind.WPI.EDU> On Thu, Jan 08, 2004 at 10:35:19PM -0600, Jason wrote: > It should be safe for the user to remove mpg321: > > [rohwedde at fungo rohwedde]$ rpm -q --whatrequires mpg123 mpg321 > no package requires mpg123 > no package requires mpg321 You must not have a fully-installed system. You can check the full distro by installing rpmdb-redhat and using --redhatrequires: >rpm -q --redhatrequires mpg321 gtoaster-1.0beta5-2 plugger-4.0-6 From warren at togami.com Fri Jan 9 08:42:09 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Jan 2004 22:42:09 -1000 Subject: Update Announcement Format discussion In-Reply-To: <3FFE1A93.8090100@togami.com> References: <3FFE1A93.8090100@togami.com> Message-ID: <3FFE6961.90008@togami.com> Okay, it seems that everyone is opposed to the removal or crippling of mpg321. We should go ahead with our first security update announcement. In order to do so, we should have a security announcement template with all necessary fields that you normally find in announcements. Please suggest a formatted template that contains all the usual things you find in security announcements for packages. Don't forget md5sums, GPG keyid, URLs. We should create a legacy advisory numbering system, and standardized Subject line. Message subjects would then be something like "Fedora Legacy Advisory FL000425: libfoo format string vulnerability". Once you write the advisory template, fill in that template with sample information for the libfoo update so we can be sure our advisory format works. After we agree upon that template, then the draft for the mpg321 no-package Legacy security advisory must be written advising users about the license issue preventing update, and suggestion to remove mpg321. Then lastly someone must emerge as a leader for this project, and perhaps create a "Fedora Legacy Advisory" GPG key for signing these announcements before they go to the various mailing lists. Jesse do you know if we got those other mailing lists? I am leaving this to the group to discuss and ratify the template format, and decide who will be the announcement signer(s). My school semester begins next week Monday, so you must become self-sufficient, intiate and work on these things yourself. I hope my kick-start of the project is sufficient enough to give the group structure enough to pick it up from here. Warren From pmatilai at welho.com Fri Jan 9 10:32:29 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 9 Jan 2004 12:32:29 +0200 (EET) Subject: Backporting policy In-Reply-To: <3FFDEF17.8040504@togami.com> References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: On Thu, 8 Jan 2004, Warren Togami wrote: > Charles R. Anderson wrote: > > On Thu, Jan 08, 2004 at 01:28:04PM +0000, Christian Pearce wrote: > > > >>Interesting. I backported ethereal yesterday, even though RHL9 was > >>an upgrade. I can't believe they did that. I generated a patch > >>myself from CVS. I believe everything works fine, I still need QA > >>and testing to be done. > > > > > > I think it is a myth that all Red Hat updates are backports. Ethereal > > has always been upgraded rather than backported: > > > > ethereal-0.9.11-0.90.1.src.rpm > > ethereal-0.9.13-1.90.1.src.rpm > > ethereal-0.9.16-0.90.1.src.rpm > > ethereal-0.10.0a-0.90.1.src.rpm > > > > I actually preferred this for ethereal, since I like getting the new > > features :) Also, API changes are not really a concern with ethereal. > > I think we should also consider upgrading in cases where all of the > following conditions are met: > 1) Absolutely zero cases where API changes would effect any distribution > OR 3rd party software, because the updated package is a leaf node on the > dependency tree. I suspect screen may be another leaf node. > 2) Where having a common %{version} across multiple distributions would > make it easier to maintain security updates, because patches need not be > ported and tested multiple times. > 3) Only by consensus of the list membership. > > Thoughts? I would add to that 4) New version doesn't have incompatible configuration file format changes I suppose most end user applications can more-or-less migrate old settings to new format in such a case, which I think is ok, but if not then user settings should not break when upgrading a package. Of course it's even more important for server software and such. - Panu - From pmatilai at welho.com Fri Jan 9 10:36:13 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 9 Jan 2004 12:36:13 +0200 (EET) Subject: mpg321 decision needed In-Reply-To: <20040109043519.GS3353@codegrinder.com> References: <3FFE1A93.8090100@togami.com> <20040109043519.GS3353@codegrinder.com> Message-ID: On Thu, 8 Jan 2004, Jason wrote: > > > What we must decide upon is whether we should also issue a mpg321 > > package update that removes MP3 functionality. This is only to force > > the vulnerable program to uninstall from systems. I personally am in > > favor of this option, but please discuss the pros & cons. > > > > A package update may be necessary because IIRC mpg321 is Required by > > other packages in RH7.x, meaning removing mpg321 may be an infeasible > > suggestion in the update notification. Please somebody check on this > > and report back. > > > > I personally feel that removing mpg321 or crippling its functionality in > > Legacy is not much of a loss, since the majority of Legacy users are > > servers. Maybe some businesses use Legacy for workstations, but think > > of a broken MP3 decoder as productivity gain? =) > > It should be safe for the user to remove mpg321: > > [rohwedde at fungo rohwedde]$ rpm -q --whatrequires mpg123 mpg321 > no package requires mpg123 > no package requires mpg321 Mind you, you can't trust --whatrequires output *at all* because it doesn't look at library dependencies, only anything that has direct "Requires: ". To get full dependency info you'll need to do something like rpm -q --whatrequires `rpm -q --provides mpg123` - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jan 9 10:43:22 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 9 Jan 2004 11:43:22 +0100 Subject: mpg321 decision needed In-Reply-To: <3FFE1A93.8090100@togami.com> References: <3FFE1A93.8090100@togami.com> Message-ID: <20040109114322.51504e3b@python.freshrpms.net> Warren Togami wrote : > I personally feel that removing mpg321 or crippling its functionality in > Legacy is not much of a loss, since the majority of Legacy users are > servers. Maybe some businesses use Legacy for workstations, but think > of a broken MP3 decoder as productivity gain? =) I'm actually _using_ mpg321 in production on some RH7.3 servers, as it is required to play sound files for some of our IVR developments based on asterisk. So crippling an update _would_ bother me. I think the package should be updated, or just left as-is if the vulnerability is minor, but not "crippled" in any way. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2149.nptl Load : 0.02 0.09 0.35 From m.stolte at datadevil.demon.nl Fri Jan 9 11:06:18 2004 From: m.stolte at datadevil.demon.nl (m.stolte at datadevil.demon.nl) Date: Fri, 9 Jan 2004 12:06:18 +0100 Subject: mpg321 decision needed In-Reply-To: <20040109114322.51504e3b@python.freshrpms.net> References: <3FFE1A93.8090100@togami.com> <20040109114322.51504e3b@python.freshrpms.net> Message-ID: <1073646378.3ffe8b2ac0225@datadevil.demon.nl> Quoting Matthias Saou : > Warren Togami wrote : > > I'm actually _using_ mpg321 in production on some RH7.3 servers, as it is > required to play sound files for some of our IVR developments based on > asterisk. So crippling an update _would_ bother me. > > I think the package should be updated, or just left as-is if the > vulnerability is minor, but not "crippled" in any way. agreed, I dont anymore, but I used to maintain a similair setup for a broadcasting company. Maarten Stolte From warren at togami.com Fri Jan 9 11:23:34 2004 From: warren at togami.com (Warren Togami) Date: Fri, 09 Jan 2004 01:23:34 -1000 Subject: Backporting policy In-Reply-To: References: <44537.209.50.130.84.1073568484.commnav@home.commnav.com> <20040108153702.GD13188@angus.ind.WPI.EDU> <3FFDEF17.8040504@togami.com> Message-ID: <3FFE8F36.5010300@togami.com> Panu Matilainen wrote: >>I think we should also consider upgrading in cases where all of the >>following conditions are met: >>1) Absolutely zero cases where API changes would effect any distribution >>OR 3rd party software, because the updated package is a leaf node on the >>dependency tree. I suspect screen may be another leaf node. >>2) Where having a common %{version} across multiple distributions would >>make it easier to maintain security updates, because patches need not be >>ported and tested multiple times. >>3) Only by consensus of the list membership. >> >>Thoughts? > > > I would add to that > 4) New version doesn't have incompatible configuration file format changes > > I suppose most end user applications can more-or-less migrate old settings > to new format in such a case, which I think is ok, but if not then user > settings should not break when upgrading a package. Of course it's even > more important for server software and such. > #1 above didn't exactly cover "command line options" that might change, so that should be added to the requirements too. Warren From dawson at fnal.gov Fri Jan 9 14:14:48 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 09 Jan 2004 08:14:48 -0600 Subject: mpg321 decision needed In-Reply-To: <3FFE1A93.8090100@togami.com> References: <3FFE1A93.8090100@togami.com> Message-ID: <3FFEB758.4000802@fnal.gov> Warren Togami wrote: ... > I personally feel that removing mpg321 or crippling its functionality in > Legacy is not much of a loss, since the majority of Legacy users are > servers. Maybe some businesses use Legacy for workstations, but think > of a broken MP3 decoder as productivity gain? =) ... I have some problems with this attitude. Why? First, because many of our systems are NOT servers. We have a very high percentage of experimentors that are running 7.3 on desktops. Second, once you start walking down that path of 'servers only' then anything is fair game. KDE will go out, alot of gnome too, shoot, eventually X since you don't really need X for web or mail servers. Now, if we have license issues, that's fine. I'll just find and/or make the patches elsewhere. Though it would be good to have a list somewhere that says which one's we can't do because of this problem. If we also don't feel the security problem is bad enough to warrent the time it takes, I have no problem there either. I just don't wnat to see Fedora-legacy be for 'servers only' Thanks Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From pearcec at commnav.com Fri Jan 9 14:36:13 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 9 Jan 2004 14:36:13 GMT Subject: mpg321 decision needed Message-ID: <52234.209.50.130.84.1073658973.commnav@home.commnav.com> This is a fair argument. I think mpg321 being the issue it is makes people want to justify reasons for doing something. I believe the comment was "mostly servers", so the effect would be midigated. But I don't want to see us pulling KDE, gnome or X either, even though I don't use them as workstations. -- Christian Pearce http://www.commnav.com Troy Dawson said: > > Warren Togami wrote: > ... > > I personally feel that removing mpg321 or crippling its functionality in > > Legacy is not much of a loss, since the majority of Legacy users are > > servers. Maybe some businesses use Legacy for workstations, but think > > of a broken MP3 decoder as productivity gain? =) > ... > > I have some problems with this attitude. > Why? > First, because many of our systems are NOT servers. We have a very high > percentage of experimentors that are running 7.3 on desktops. > Second, once you start walking down that path of 'servers only' then anything > is fair game. KDE will go out, alot of gnome too, shoot, eventually X since > you don't really need X for web or mail servers. > > Now, if we have license issues, that's fine. I'll just find and/or make the > patches elsewhere. Though it would be good to have a list somewhere that says > which one's we can't do because of this problem. > If we also don't feel the security problem is bad enough to warrent the time > it takes, I have no problem there either. > > I just don't wnat to see Fedora-legacy be for 'servers only' > > Thanks > Troy > -- > __________________________________________________ > Troy Dawson dawson at fnal.gov (630)840-6468 > Fermilab ComputingDivision/CSS CSI Group > __________________________________________________ > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rdieter at math.unl.edu Fri Jan 9 14:44:32 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 9 Jan 2004 08:44:32 -0600 (CST) Subject: mpg321 decision needed In-Reply-To: <52234.209.50.130.84.1073658973.commnav@home.commnav.com> Message-ID: On Fri, 9 Jan 2004, Christian Pearce wrote: > But I don't want to see us pulling KDE, gnome or X either, even though > I don't use them as workstations. On the flip-side, that's exactly what I had originally hoped fedora-legacy *would* have offerred, making rh73 (and other soon-to-be legacy releases) a first-tier fedora.us/fedora-extras supported release (like rh90 and fc1 are now). Oh well, I guess we'll just keep doing our own thing in the KDE-RedHat project (wrt KDE and X at least). -- Rex From jkeating at j2solutions.net Sat Jan 10 07:56:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 9 Jan 2004 23:56:52 -0800 Subject: updates-testing --> updates policy discussion In-Reply-To: <3FFDF28C.6030305@togami.com> References: <3FFDF28C.6030305@togami.com> Message-ID: <200401092356.52853.jkeating@j2solutions.net> On Thursday 08 January 2004 16:15, Warren Togami wrote: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > We need to discuss how to change this procedure for Legacy specific > packages. Post message to either "fedora-legacy-announce" or "fedora-legacy-devel" about a suspected vulnerability or bugfix that you'd like to fix. Use "FedoraLegacy Package Naming Guidelines" instead of generic fedora.us guidelines Fix the numbering scheme... 1,2,3,4,1,2,3,4 ? why start over? Move the signing from before the optional rpmlint to after the option rpmlint. 2 initial keywords. "updates-testing" or "updates", and "security" or "bugfix" to indicate what type of update it is. Change "fedora-package-announce" to "fedora-legacy-announce". > We also need to change the definition of "trusted" for Legacy > specific packages, along with the requirements for reaching the > "trusted" status. > > Thoughts? Trusted could be a term given to those developers who've put forth and followed through with a certain number of security fixes in packages. I'd say untrusted == 0-5, semi-trusted == 6-9, trusted == 10=+. A package can inherit it's trusted status from the developer who puts if forth. Now where we use the term or what it really means to the end users is yet another point of discussion. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From warren at togami.com Sat Jan 10 09:46:13 2004 From: warren at togami.com (Warren Togami) Date: Fri, 09 Jan 2004 23:46:13 -1000 Subject: updates-testing --> updates policy discussion In-Reply-To: <200401092356.52853.jkeating@j2solutions.net> References: <3FFDF28C.6030305@togami.com> <200401092356.52853.jkeating@j2solutions.net> Message-ID: <3FFFC9E5.6040004@togami.com> Massive headache... Jesse Keating wrote: > On Thursday 08 January 2004 16:15, Warren Togami wrote: > >>http://www.fedora.us/wiki/PackageSubmissionQAPolicy >>We need to discuss how to change this procedure for Legacy specific >>packages. > > > Post message to either "fedora-legacy-announce" or "fedora-legacy-devel" > about a suspected vulnerability or bugfix that you'd like to fix. I agree with fedora-legacy-devel, but fedora-legacy-announce is for official announcements of the Legacy project, like security advisories only. Right? Well that's what I would expect anyhow... > > Use "FedoraLegacy Package Naming Guidelines" instead of generic > fedora.us guidelines Of course. > > Fix the numbering scheme... 1,2,3,4,1,2,3,4 ? why start over? Move the > signing from before the optional rpmlint to after the option rpmlint. > The formatting of the document isn't important in this discussion. The actual process is. > 2 initial keywords. "updates-testing" or "updates", and "security" or > "bugfix" to indicate what type of update it is. > > Change "fedora-package-announce" to "fedora-legacy-announce". > Exactly. > >>We also need to change the definition of "trusted" for Legacy >>specific packages, along with the requirements for reaching the >>"trusted" status. >> >>Thoughts? > > > Trusted could be a term given to those developers who've put forth and > followed through with a certain number of security fixes in packages. > I'd say untrusted == 0-5, semi-trusted == 6-9, trusted == 10=+. A > package can inherit it's trusted status from the developer who puts if > forth. Now where we use the term or what it really means to the end > users is yet another point of discussion. > I'm not sure how to respond here except to say I have a bad feeling about this. I am realizing that it was a bad time to ask this specific question. Giving hard numbers for thresholds of "trust" IMHO is a mistake. You cannot earn "trust" by mechanically doing a set number of tasks. It could even be dangerous to make such a policy. "Trust" is something that you earn through dedication and hard work. Trust is not something that can be given cold, quantized numbers. http://www.fedora.us/LEGACY These are the folks that gain trust. Those who spend hours doing boring work of porting patches, building and testing packages for a lazy userbase waiting for a free lunch - someone else to do the work for them. Hard work and dedication is what built the "trusted" group in the original fedora.us project, and I would suggest doing the same here. Follow the process, and review the patches. That is the only way we can get these packages published. Warren From jkeating at j2solutions.net Sat Jan 10 18:19:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 10:19:31 -0800 Subject: updates-testing --> updates policy discussion In-Reply-To: <3FFFC9E5.6040004@togami.com> References: <3FFDF28C.6030305@togami.com> <200401092356.52853.jkeating@j2solutions.net> <3FFFC9E5.6040004@togami.com> Message-ID: <200401101019.31619.jkeating@j2solutions.net> On Saturday 10 January 2004 01:46, Warren Togami wrote: > "Trust" is something that you earn through dedication and hard work. > Trust is not something that can be given cold, quantized numbers. > > http://www.fedora.us/LEGACY > > These are the folks that gain trust. Those who spend hours doing > boring work of porting patches, building and testing packages for a > lazy userbase waiting for a free lunch - someone else to do the work > for them. > > Hard work and dedication is what built the "trusted" group in the > original fedora.us project, and I would suggest doing the same here. > > Follow the process, and review the patches. That is the only way we > can get these packages published. Ok, I can follow that, but if you already had an idea for trust, I'm not sure what we're supposed to discuss. I'd like to see a leadership board of Fedora Legacy. I have a few folks in mind already, some people besides just you and I to make these decisions like who is trusted or things like that. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Sat Jan 10 18:21:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 10:21:58 -0800 Subject: updates-testing --> updates policy discussion In-Reply-To: <3FFFC9E5.6040004@togami.com> References: <3FFDF28C.6030305@togami.com> <200401092356.52853.jkeating@j2solutions.net> <3FFFC9E5.6040004@togami.com> Message-ID: <200401101021.58469.jkeating@j2solutions.net> On Saturday 10 January 2004 01:46, Warren Togami wrote: > I agree with fedora-legacy-devel, but fedora-legacy-announce is for > official announcements of the Legacy project, like security > advisories only. Right? Well that's what I would expect anyhow... Yeah good point. This is why I like discussions. Other people catch my incredibly bad ideas (; -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From whooperhsd3 at earthlink.net Sat Jan 10 19:25:47 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Sat, 10 Jan 2004 14:25:47 -0500 (EST) Subject: updates-testing --> updates policy discussion In-Reply-To: <200401092356.52853.jkeating@j2solutions.net> References: <3FFDF28C.6030305@togami.com> <200401092356.52853.jkeating@j2solutions.net> Message-ID: <64970.69.68.37.57.1073762747.squirrel@69.68.37.57> Jesse Keating said: > On Thursday 08 January 2004 16:15, Warren Togami wrote: >> http://www.fedora.us/wiki/PackageSubmissionQAPolicy >> We need to discuss how to change this procedure for Legacy specific >> packages. > > Post message to either "fedora-legacy-announce" or "fedora-legacy-devel" > about a suspected vulnerability or bugfix that you'd like to fix. Do either of these lists exist yet? I'm not sure personally sure about joining -devel (I'd probably check the gmane archive), but I would like to see -announce sooner rather than later. -- William Hooper From jkeating at j2solutions.net Sat Jan 10 19:30:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 11:30:48 -0800 Subject: updates-testing --> updates policy discussion In-Reply-To: <64970.69.68.37.57.1073762747.squirrel@69.68.37.57> References: <3FFDF28C.6030305@togami.com> <200401092356.52853.jkeating@j2solutions.net> <64970.69.68.37.57.1073762747.squirrel@69.68.37.57> Message-ID: <200401101130.48143.jkeating@j2solutions.net> On Saturday 10 January 2004 11:25, William Hooper wrote: > Do either of these lists exist yet? I'm not sure personally sure > about joining -devel (I'd probably check the gmane archive), but I > would like to see -announce sooner rather than later. They've been requested, although for right now we're going to just use -list as a place for -devel discussions. Hopefully soon they'll be live. I'll announce. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Sat Jan 10 22:18:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 14:18:47 -0800 Subject: Update Announcement Format discussion In-Reply-To: <3FFE6961.90008@togami.com> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> Message-ID: <200401101418.47102.jkeating@j2solutions.net> On Friday 09 January 2004 00:42, Warren Togami wrote: > Please suggest a formatted template that contains all the usual > things you find in security announcements for packages. Don't forget > md5sums, GPG keyid, URLs. We should create a legacy advisory > numbering system, and standardized Subject line. Message subjects > would then be something like "Fedora Legacy Advisory FL000425: libfoo > format string vulnerability". > > Once you write the advisory template, fill in that template with > sample information for the libfoo update so we can be sure our > advisory format works. > > After we agree upon that template, then the draft for the mpg321 > no-package Legacy security advisory must be written advising users > about the license issue preventing update, and suggestion to remove > mpg321. > > Then lastly someone must emerge as a leader for this project, and > perhaps create a "Fedora Legacy Advisory" GPG key for signing these > announcements before they go to the various mailing lists. Although I've been slightly busy this last couple weeks, I'm still here to try and lead this thing. With your help, I'm willing to create the GPG key, shop it around for signing and start pushing these announcements. > Jesse do you know if we got those other mailing lists? Lists have been requested, waiting for approval. Here is what I have as an example layout: Subject: [FLSA-2004:${bugzillaID}] Updated sendmail resolves security vulnerability clearsigned GPG ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated sendmail resolves security vulnerability Advisory ID: FLSA:${bugzillaID} Issue date: 2004-01-05 Updated on: 2004-01-05 Product: Red Hat Linux Keywords: Security/Bugfix Cross references: Bugzillasystem/ID Obsoletes: CVE Names: CAN-2003-0984 CAN-2003-0985 ----------------------------------------------------------------------- 1. Topic: Updated sendmail packages are now available that fix a security vulnerability which may allow local users to gain root privileges. 2. Relevant releases/architectures: Red Hat Linux 7.1 - athlon, i386, i586, i686 Red Hat Linux 7.2 - athlon, i386, i586, i686 Red Hat Linux 7.3 - athlon, i386, i586, i686 Red Hat Linux 8.0 - athlon, i386, i586, i686 Red Hat Linux 9 - athlon, i386, i586, i686 3. Problem description: Sendmail handles the functions of an MTA on Linux systems. ${PERSON} discovered a flaw in some function of sendmail versions 2.4.23 and previous which may allow a local attacker to gain root privileges. No exploit is currently available; however, it is believed that this issue is exploitable (although not trivially.) The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0985 to this issue. All users are advised to upgrade to these errata packages, which contain a backported security patch that 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 This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): ${BUGZILLA_SYSTEM} - 90338 - Security flaw found in Sendmail 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://download.fedoralegacy.org/7.1/en/os/SRPMS/sendmail-2.4.20-28.7.src.rpm athlon: ftp://download.fedoralegacy.org/7.1/en/os/athlon/sendmail-2.4.20-28.7.athlon.rpm (So on and so forth) end clearsign GPG I'd like to develop some kind of web form that only the authorized people will have access to that we can plug values into and hit submit that will send it out and keep an online copy of it somewhere within fedoralegacy.org so that folks can reference it as well as the bugzilla ID. Thoughts? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From Bernd.Bartmann at sohanet.de Sat Jan 10 23:53:07 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Sun, 11 Jan 2004 00:53:07 +0100 Subject: Update Announcement Format discussion In-Reply-To: <200401101418.47102.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> <200401101418.47102.jkeating@j2solutions.net> Message-ID: <40009063.4060206@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating schrieb: | Here is what I have as an example layout: | | Subject: [FLSA-2004:${bugzillaID}] Updated sendmail resolves security | vulnerability Some thoughts: What's the difference between "Issue Date" and "Updated on"? If another update becomes nescessary it should get a new Bugzilla entry. Cross references should also include links to the upstream, CVE, CERT, Bugtraq, Full-Disclosure, ... announcements If a service like sshd or httpd gets an update and the post-install scripts don't restart the service automatically a note should be added how to restart the service manually. The MD5SUMS and file sizes of the rpms HAVE TO BE listed. The rpm changelog should be listed. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAAJBjkQuIaHu84cIRAgazAKCUVCXQTnp+84DGsg2kxwd0ZsWcegCfaWDR Y9ApUqvfjil5vIyacft7Ihs= =Gtze -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sun Jan 11 00:05:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 16:05:59 -0800 Subject: Update Announcement Format discussion In-Reply-To: <40009063.4060206@sohanet.de> References: <3FFE1A93.8090100@togami.com> <200401101418.47102.jkeating@j2solutions.net> <40009063.4060206@sohanet.de> Message-ID: <200401101605.59654.jkeating@j2solutions.net> On Saturday 10 January 2004 15:53, Bernd Bartmann wrote: > What's the difference between "Issue Date" and "Updated on"? If > another update becomes nescessary it should get a new Bugzilla entry. Hrm, probably right. I pulled this content from RH's RSA announcements, not sure how they use the field. Perhaps we'll leave it out for now. > Cross references should also include links to the upstream, CVE, > CERT, Bugtraq, Full-Disclosure, ... announcements Yep, I didn't mean to limit the content to just what was there, it should include anything directly relevant w/out duplicating information. > If a service like sshd or httpd gets an update and the post-install > scripts don't restart the service automatically a note should be > added how to restart the service manually. Yep, that would be near the bottom under "Special Notes:" > The MD5SUMS and file sizes of the rpms HAVE TO BE listed. Absolutely. I forgot a section or 3, let me add them here: 7. Verification: MD5 sum Package Name --------------------------------------------------------------------------- 6f37a0c884be50f702665dd418e7d8a5 7.1/en/os/SRPMS/kernel-2.4.20-28.7.src.rpm 85dabb948243fcd96fed1946217b3259 7.1/en/os/athlon/kernel-2.4.20-28.7.athlon.rpm ba80fcbe3237ece886506446413d6330 7.1/en/os/athlon/kernel-smp-2.4.20-28.7.athlon.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from https://www.fedoralegacy.org/security/keys.html 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 md5sum with the following command: md5sum 8. References: http://www.securityfocus.com/bid/9154/discussion/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0984 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0985 9. Contact: The Fedora Legacy security contact is . More contact details at https://www.fedoralegacy.org/contact > The rpm changelog should be listed. Well, the last couple lines, not the whole thing (; -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From steve at math.upatras.gr Sun Jan 11 00:45:05 2004 From: steve at math.upatras.gr (Steve Stavropoulos) Date: Sun, 11 Jan 2004 02:45:05 +0200 (EET) Subject: Update Announcement Format discussion In-Reply-To: <200401101605.59654.jkeating@j2solutions.net> Message-ID: On Sat, 10 Jan 2004, Jesse Keating wrote: > On Saturday 10 January 2004 15:53, Bernd Bartmann wrote: > > What's the difference between "Issue Date" and "Updated on"? If > > another update becomes nescessary it should get a new Bugzilla entry. > > Hrm, probably right. I pulled this content from RH's RSA announcements, > not sure how they use the field. Perhaps we'll leave it out for now. > As someone who has received a lot of RHSAs, I can say that the update field gets used when the rpms from the first update have some problem, or don't actually fix the problem, or there is an additional security problem fixed in the original package which was left out. Another case would be the addition of rpms for more systems. Also, when there is an update to an advisory, this is marked at the id. For example an update to RHSA 2003:279-01 would get the id 2003:279-02 (real example). Btw, I think an incremental id would be better than putting the bugzilla id. That way we have a small number, more easily remembered. Either way, bugzilla id is still shown in the body of the message. From warren at togami.com Sun Jan 11 02:05:41 2004 From: warren at togami.com (Warren Togami) Date: Sat, 10 Jan 2004 16:05:41 -1000 Subject: Update Announcement Format discussion In-Reply-To: <200401101605.59654.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <200401101418.47102.jkeating@j2solutions.net> <40009063.4060206@sohanet.de> <200401101605.59654.jkeating@j2solutions.net> Message-ID: <4000AF75.1030008@togami.com> >>If a service like sshd or httpd gets an update and the post-install >>scripts don't restart the service automatically a note should be >>added how to restart the service manually. > > > Yep, that would be near the bottom under "Special Notes:" As part of the update QA, conditional restart should be tested to be sure the service is restarted, and ONLY IF it is already running. Warren From jkeating at j2solutions.net Sun Jan 11 02:21:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Jan 2004 18:21:02 -0800 Subject: Update Announcement Format discussion In-Reply-To: <200401101418.47102.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> <200401101418.47102.jkeating@j2solutions.net> Message-ID: <200401101821.02292.jkeating@j2solutions.net> On Saturday 10 January 2004 14:18, Jesse Keating wrote: > I'd like to develop some kind of web form that only the authorized > people will have access to that we can plug values into and hit > submit that will send it out and keep an online copy of it somewhere > within fedoralegacy.org so that folks can reference it as well as the > bugzilla ID. I just thought about this, bad idea. It would rely on something serverside to sign the message, not good. Maybe something that just takes the entire text block and submits it, that way one can clearsign the text file, then copy the contents into the form. I'll continue to think on this. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From warren at togami.com Sun Jan 11 02:42:55 2004 From: warren at togami.com (Warren Togami) Date: Sat, 10 Jan 2004 16:42:55 -1000 Subject: Update Announcement Format discussion In-Reply-To: <200401101821.02292.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> <200401101418.47102.jkeating@j2solutions.net> <200401101821.02292.jkeating@j2solutions.net> Message-ID: <4000B82F.8030900@togami.com> Jesse Keating wrote: > On Saturday 10 January 2004 14:18, Jesse Keating wrote: > >>I'd like to develop some kind of web form that only the authorized >>people will have access to that we can plug values into and hit >>submit that will send it out and keep an online copy of it somewhere >>within fedoralegacy.org so that folks can reference it as well as the >>bugzilla ID. > > > I just thought about this, bad idea. It would rely on something > serverside to sign the message, not good. Maybe something that just > takes the entire text block and submits it, that way one can clearsign > the text file, then copy the contents into the form. I'll continue to > think on this. > IMHO, don't spend tons of time in order to make quicker something that does not happen that often. We need more time actually spent on the packages themselves, because that is the important part. Warren From barryn at pobox.com Sun Jan 11 05:14:30 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 10 Jan 2004 21:14:30 -0800 Subject: Update Announcement Format discussion In-Reply-To: <200401101418.47102.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> <200401101418.47102.jkeating@j2solutions.net> Message-ID: <20040111051430.GA24976@ip68-4-255-84.oc.oc.cox.net> On Sat, Jan 10, 2004 at 02:18:47PM -0800, Jesse Keating wrote: > or to use apt: > > apt-get update > Isn't there something missing here? Shouldn't it be something like this? or to use apt: apt-get update apt-get upgrade If you just run "apt-get update" alone, it's not going to actually install anything, to the best of my knowledge. -Barry K. Nathan From pekkas at netcore.fi Sun Jan 11 05:56:17 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 11 Jan 2004 07:56:17 +0200 (EET) Subject: Update Announcement Format discussion In-Reply-To: <200401101418.47102.jkeating@j2solutions.net> Message-ID: On Sat, 10 Jan 2004, Jesse Keating wrote: > Subject: [FLSA-2004:${bugzillaID}] Updated sendmail resolves security > vulnerability I wouldn't used bugzilla-id in the header; they aren't sequential, and the users will get confused ("did I miss 15 security advisories?!?!"). I'd suggest just allocating a number on FCFS basis > Product: Red Hat Linux Not sure if there may be a trademark issue here.. Perhaps one should add a preamble "0. About Fedora Legacy", plus 1-2 sentences to describe the relation to Red Hat Linux. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Sun Jan 11 17:18:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 11 Jan 2004 09:18:14 -0800 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <200401110918.14963.jkeating@j2solutions.net> On Saturday 10 January 2004 21:56, Pekka Savola wrote: > I wouldn't used bugzilla-id in the header; they aren't sequential, > and the users will get confused ("did I miss 15 security > advisories?!?!"). Hrm point taken. I suppose we'll have to come up w/ a good numbering scheme and a way to ensure no cross numbers. > I'd suggest just allocating a number on FCFS basis > > > Product: Red Hat Linux > > Not sure if there may be a trademark issue here.. Perhaps one should > add a preamble "0. About Fedora Legacy", plus 1-2 sentences to > describe the relation to Red Hat Linux. Just because "Red Hat Linux" is trademarked, doesn't mean we can't mention it in a document. The update would in fact be for Red Hat Linux. We can have somewhere at the bottom of the thing that Red Hat Linux is a trademark of blah.... -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Sun Jan 11 17:18:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 11 Jan 2004 09:18:50 -0800 Subject: Update Announcement Format discussion In-Reply-To: <20040111051430.GA24976@ip68-4-255-84.oc.oc.cox.net> References: <3FFE1A93.8090100@togami.com> <200401101418.47102.jkeating@j2solutions.net> <20040111051430.GA24976@ip68-4-255-84.oc.oc.cox.net> Message-ID: <200401110918.50573.jkeating@j2solutions.net> On Saturday 10 January 2004 21:14, Barry K. Nathan wrote: > Isn't there something missing here? Shouldn't it be something like > this? > > or to use apt: > > apt-get update > apt-get upgrade > > If you just run "apt-get update" alone, it's not going to actually > install anything, to the best of my knowledge. Perhaps you are right. I've never really used apt before, so I'm a bit rusty. Why couldn't you just do apt-get upgrade ? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From drees at greenhydrant.com Sun Jan 11 17:35:26 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 11 Jan 2004 09:35:26 -0800 Subject: Update Announcement Format discussion In-Reply-To: <200401110918.50573.jkeating@j2solutions.net> References: <3FFE1A93.8090100@togami.com> <200401101418.47102.jkeating@j2solutions.net> <20040111051430.GA24976@ip68-4-255-84.oc.oc.cox.net> <200401110918.50573.jkeating@j2solutions.net> Message-ID: <4001895E.9010204@greenhydrant.com> Jesse Keating wrote, On 1/11/2004 9:18 AM: > On Saturday 10 January 2004 21:14, Barry K. Nathan wrote: >> >>If you just run "apt-get update" alone, it's not going to actually >>install anything, to the best of my knowledge. > > Perhaps you are right. I've never really used apt before, so I'm a bit > rusty. Why couldn't you just do apt-get upgrade ? update updates the package list from the apt-repository without actually upgrading any software, upgrade will upgrade out-of-date packages. You do need both. Contrary to yum where `yum update` is synonymous with `apt-get update ; apt-get upgrade`. -Dave From chuckw at quantumlinux.com Mon Jan 12 05:29:01 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 11 Jan 2004 21:29:01 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: <40009063.4060206@sohanet.de> Message-ID: > The rpm changelog should be listed. These can get awfully large. What about the most recent entry? Or perhaps a URL? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From chuckw at quantumlinux.com Mon Jan 12 05:44:02 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 11 Jan 2004 21:44:02 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: Message-ID: > Btw, I think an incremental id would be better than putting the > bugzilla id. That way we have a small number, more easily remembered. > Either way, bugzilla id is still shown in the body of the message. An incremental update id would be a good idea. That separates the concept of an Update announcement and a bugzilla bug. It also helps one keep track of missed announcements. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From jkeating at j2solutions.net Mon Jan 12 05:51:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 11 Jan 2004 21:51:41 -0800 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <200401112151.41238.jkeating@j2solutions.net> On Sunday 11 January 2004 21:44, Chuck Wolber wrote: > An incremental update id would be a good idea. That separates the > concept of an Update announcement and a bugzilla bug. It also helps > one keep track of missed announcements. Would anybody be willing to develop a system for this? Something held in mysql or pgsql; that has the fields and whatnot? We can use to keep track of the updates and such, and avoid update ID collision? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From warren at togami.com Mon Jan 12 07:01:58 2004 From: warren at togami.com (Warren Togami) Date: Sun, 11 Jan 2004 21:01:58 -1000 Subject: Update Announcement Format discussion In-Reply-To: <200401112151.41238.jkeating@j2solutions.net> References: <200401112151.41238.jkeating@j2solutions.net> Message-ID: <40024666.90808@togami.com> Jesse Keating wrote: > On Sunday 11 January 2004 21:44, Chuck Wolber wrote: > >>An incremental update id would be a good idea. That separates the >>concept of an Update announcement and a bugzilla bug. It also helps >>one keep track of missed announcements. > > > Would anybody be willing to develop a system for this? Something held > in mysql or pgsql; that has the fields and whatnot? We can use to keep > track of the updates and such, and avoid update ID collision? > I will say it again, I think it is foolish to discuss something like this when there is so little working going into the actual packages. Foolish I say! Bah! Nay! Dame! (Don't mind me, I'm still angry at software RAID. Long story...) Warren From pekkas at netcore.fi Mon Jan 12 07:27:46 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 12 Jan 2004 09:27:46 +0200 (EET) Subject: Update Announcement Format discussion In-Reply-To: <40024666.90808@togami.com> Message-ID: On Sun, 11 Jan 2004, Warren Togami wrote: > > Would anybody be willing to develop a system for this? Something held > > in mysql or pgsql; that has the fields and whatnot? We can use to keep > > track of the updates and such, and avoid update ID collision? > > > > I will say it again, I think it is foolish to discuss something like > this when there is so little working going into the actual packages. Agreed. We can just assign the numbers on First Come - First Served basis just before sending the announcements, 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 chuckw at quantumlinux.com Mon Jan 12 07:31:58 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 11 Jan 2004 23:31:58 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: <200401112151.41238.jkeating@j2solutions.net> Message-ID: > > An incremental update id would be a good idea. That separates the > > concept of an Update announcement and a bugzilla bug. It also helps > > one keep track of missed announcements. > > Would anybody be willing to develop a system for this? Something held > in mysql or pgsql; that has the fields and whatnot? We can use to keep > track of the updates and such, and avoid update ID collision? Sounds like fun, but what do you mean by "system"? Are you talking about a system that lets us automagically generate and archive update announcements? I think we could get something put together pretty easily. Let's hash out some req's and I'll see what I can put together. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From chuckw at quantumlinux.com Mon Jan 12 07:39:31 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 11 Jan 2004 23:39:31 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: <40024666.90808@togami.com> Message-ID: > > Would anybody be willing to develop a system for this? Something held > > in mysql or pgsql; that has the fields and whatnot? We can use to > > keep track of the updates and such, and avoid update ID collision? > > I will say it again, I think it is foolish to discuss something like > this when there is so little working going into the actual packages. What we take care of now, we'll spend less time organizing later. > (Don't mind me, I'm still angry at software RAID. Long story...) Maybe we can share stories... FWIW: I'm interested in hearing your SoftRAID story if you have the time. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From chuckw at quantumlinux.com Mon Jan 12 07:40:51 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 11 Jan 2004 23:40:51 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: Message-ID: > > I will say it again, I think it is foolish to discuss something like > > this when there is so little working going into the actual packages. > > Agreed. We can just assign the numbers on First Come - First Served > basis just before sending the announcements, right? Well that plan sure does scream "race condition"... and I'm sure as heck not going to volunteer to "hand out" numbers upon request... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier. From pekkas at netcore.fi Mon Jan 12 09:13:02 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 12 Jan 2004 11:13:02 +0200 (EET) Subject: Update Announcement Format discussion In-Reply-To: Message-ID: On Sun, 11 Jan 2004, Chuck Wolber wrote: > > Agreed. We can just assign the numbers on First Come - First Served > > basis just before sending the announcements, right? > > Well that plan sure does scream "race condition"... Yep! But it's a controlled race condition :) > and I'm sure as heck > not going to volunteer to "hand out" numbers upon request... The point would be that if the announcements are all sent (and signed) by one person, or a small group of persons, the ID number could be left empty until just a moment before the announcement is sent (and stored). No race condition then, except within the head of the one person (or a small group of persons). But if the assumption is that whoever did the backport would sent the announcement him/herself (IMHO, this sounds a bit problematic), this would obviously not work.. -- 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 warren at togami.com Mon Jan 12 09:27:04 2004 From: warren at togami.com (Warren Togami) Date: Sun, 11 Jan 2004 23:27:04 -1000 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <40026868.3040203@togami.com> Pekka Savola wrote: > On Sun, 11 Jan 2004, Chuck Wolber wrote: > >>>Agreed. We can just assign the numbers on First Come - First Served >>>basis just before sending the announcements, right? >> >>Well that plan sure does scream "race condition"... > > > Yep! But it's a controlled race condition :) > > >>and I'm sure as heck >>not going to volunteer to "hand out" numbers upon request... > > > The point would be that if the announcements are all sent (and signed) > by one person, or a small group of persons, the ID number could be > left empty until just a moment before the announcement is sent (and > stored). No race condition then, except within the head of the one > person (or a small group of persons). > > But if the assumption is that whoever did the backport would sent the > announcement him/herself (IMHO, this sounds a bit problematic), this > would obviously not work.. > The advisories need to come from a small group of leaders in the Legacy project. Given that the scope of Legacy is so small, this might as well be a single person. That person needs to be available often though. In order to help that person, the list should discuss drafts for announcements. After revisions and the list has agreed upon a certain text, then the announcement can go out. This would work for most non-critical advisories like the ones we currently have pending. For more serious advisories like an internet facing service the leadership would need to discuss it privately of course, and post the announcement when the embargo is lifted. Warren From chuckw at quantumlinux.com Mon Jan 12 10:20:45 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 12 Jan 2004 02:20:45 -0800 (PST) Subject: Update Announcement Format discussion In-Reply-To: Message-ID: > The point would be that if the announcements are all sent (and signed) > by one person, or a small group of persons, the ID number could be left > empty until just a moment before the announcement is sent (and stored). > No race condition then, except within the head of the one person (or a > small group of persons). But that's the thing I'm getting at. It's incredibly easy to create a web form that looks like a fill-in-the-blanks template. Rather than having to resort to some hacked XML format (which would never work with humans at the helm), a form template would allow us to 1) separate out the data segments so they're individually searchable, 2) ensure that everything is consistently formatted and 3) Numbering would be immutably accurate. > But if the assumption is that whoever did the backport would sent the > announcement him/herself (IMHO, this sounds a bit problematic), this > would obviously not work.. Right, and I'd say that is a bad assumption for a number of reasons, but I think we're in agreement, so I'll say-no-more... -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From warren at togami.com Mon Jan 12 10:51:32 2004 From: warren at togami.com (Warren Togami) Date: Mon, 12 Jan 2004 00:51:32 -1000 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <40027C34.2020507@togami.com> Chuck Wolber wrote: > > But that's the thing I'm getting at. It's incredibly easy to create a web > form that looks like a fill-in-the-blanks template. Rather than having to > resort to some hacked XML format (which would never work with humans at > the helm), a form template would allow us to 1) separate out the data > segments so they're individually searchable, 2) ensure that everything > is consistently formatted and 3) Numbering would be immutably accurate. > There are several reasons why this is a bad idea: 1) Advisories just don't happen so often to necessitate this. 2) http://www.fedora.us/LEGACY Higher priority to actually work on the packages, which have been stalled there for several days. 3) This is a HUGE security risk. You should never have an important signing key like advisory or package signing on any Internet accessible host, especially with the security risk of something like PHP or perl and apache. The signing key for packages and advisories should be on a secured host with no public services, used for NO OTHER PURPOSE. (i.e. fedora.us signing does not happen at www.fedora.us.) Warren From rohwedde at codegrinder.com Mon Jan 12 15:52:21 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 12 Jan 2004 09:52:21 -0600 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <20040112155221.GU3353@codegrinder.com> On Mon, Jan 12, 2004 at 02:20:45AM -0800, Chuck Wolber wrote: > > But that's the thing I'm getting at. It's incredibly easy to create a web > form that looks like a fill-in-the-blanks template. Rather than having to > resort to some hacked XML format (which would never work with humans at > the helm), a form template would allow us to 1) separate out the data > segments so they're individually searchable, 2) ensure that everything > is consistently formatted and 3) Numbering would be immutably accurate. > It may be easy to do, but it's rather pointless if we never have anyone QA, the packages in the bugzilla so that they can be released. That said, I think it's a good idea once we get rolling. But if I had a choice where a few hours of work were spent, it'd be in QA or patching. for any lurkers with free time :) http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://fedora.us/LEGACY -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Mon Jan 12 16:45:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 08:45:47 -0800 Subject: vuln needs investigation and need a new form Message-ID: <200401120845.47479.jkeating@j2solutions.net> So, I just saw this morning that RH issued an update for CVS, and in the information there was this line: A flaw was found in versions of CVS prior to 1.11.10 where a malformed module request could cause the CVS server to attempt to create files or directories at the root level of the file system. However, normal file system permissions would prevent the creation of these misplaced directories. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0977 to this issue. Since RHL 8/7.x presumably have a CVS version that is prior to 1.11.10, we need to investigate and possibly backport the fix. Any volunteers ? This brings me to my next point, should we have a standard form for requesting updates? We've pretty much standardized the announcing updates (I'll upload a final version to the website today for final approval), but we should probably have something for requesting them as well. Seth Vidal and I worked on a format for fedora-devel, so that could be modified for legacy use. http://linux.duke.edu/~skvidal/misc/fedora-request-template.txt Until I get the time to revamp this, if anybody on the list would like to go through it and fix it up for legacy use, I'd appreciate it. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From rohwedde at codegrinder.com Mon Jan 12 16:53:18 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 12 Jan 2004 10:53:18 -0600 Subject: vuln needs investigation and need a new form In-Reply-To: <200401120845.47479.jkeating@j2solutions.net> References: <200401120845.47479.jkeating@j2solutions.net> Message-ID: <20040112165318.GV3353@codegrinder.com> On Mon, Jan 12, 2004 at 08:45:47AM -0800, Jesse Keating wrote: > So, I just saw this morning that RH issued an update for CVS, and in the > information there was this line: > > A flaw was found in versions of CVS prior to 1.11.10 where a malformed > module request could cause the CVS server to attempt to create files or > directories at the root level of the file system. However, normal file > system permissions would prevent the creation of these misplaced > directories. The Common Vulnerabilities and Exposures project > (cve.mitre.org) has assigned the name CAN-2003-0977 to this issue. > > Since RHL 8/7.x presumably have a CVS version that is prior to 1.11.10, > we need to investigate and possibly backport the fix. Any volunteers ? > Seth posted a src.rpm to the list a week or so ago for cvs to fix a more serious root exploit vuln. I was in the process of verifying it to submit to the bugzilla, so I can check this out as well and patch it in. -j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Mon Jan 12 17:14:28 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 09:14:28 -0800 Subject: vuln needs investigation and need a new form In-Reply-To: <20040112165318.GV3353@codegrinder.com> References: <200401120845.47479.jkeating@j2solutions.net> <20040112165318.GV3353@codegrinder.com> Message-ID: <200401120914.28200.jkeating@j2solutions.net> On Monday 12 January 2004 08:53, Jason wrote: > Seth posted a src.rpm to the list a week or so ago for cvs to fix a > more serious root exploit vuln. I was in the process of verifying it > to submit to the bugzilla, so I can check this out as well and patch > it in. You know what? I wonder if this is the same vuln.... I could be just cracked in the head. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Mon Jan 12 17:20:00 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 12 Jan 2004 11:20:00 -0600 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> Quoting Chuck Wolber : > > The rpm changelog should be listed. > > These can get awfully large. What about the most recent entry? Or perhaps > a URL? I agree. Either a url to the changelog, or just the changelog from the last version to the new version, or both. But not the entire changelog. -- Eric Rostetter From jkeating at j2solutions.net Mon Jan 12 17:19:12 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 09:19:12 -0800 Subject: Update Announcement Format discussion In-Reply-To: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> References: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> Message-ID: <200401120919.12782.jkeating@j2solutions.net> On Monday 12 January 2004 09:20, Eric Rostetter wrote: > I agree. Either a url to the changelog, or just the changelog from > the last version to the new version, or both. But not the entire > changelo For now, just the last entry. In the future, when I have the software I'm dreaming up to make a webpage module out of a directory tree of RPMs, flush with data such as description and such, we may be able to point to this for the changelog in full. But for now, just the relevant parts. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rohwedde at codegrinder.com Mon Jan 12 17:29:44 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 12 Jan 2004 11:29:44 -0600 Subject: vuln needs investigation and need a new form In-Reply-To: <200401120914.28200.jkeating@j2solutions.net> References: <200401120845.47479.jkeating@j2solutions.net> <20040112165318.GV3353@codegrinder.com> <200401120914.28200.jkeating@j2solutions.net> Message-ID: <20040112172944.GW3353@codegrinder.com> On Mon, Jan 12, 2004 at 09:14:28AM -0800, Jesse Keating wrote: Content-Description: signed data > On Monday 12 January 2004 08:53, Jason wrote: > > Seth posted a src.rpm to the list a week or so ago for cvs to fix a > > more serious root exploit vuln. I was in the process of verifying it > > to submit to the bugzilla, so I can check this out as well and patch > > it in. > > You know what? I wonder if this is the same vuln.... I could be just > cracked in the head. It's not .. one is a directory creation problem.. and one is a broken switch_to_user routine, allowing switching to the root user. -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Mon Jan 12 18:09:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 12 Jan 2004 13:09:01 -0500 Subject: vuln needs investigation and need a new form In-Reply-To: <20040112172944.GW3353@codegrinder.com> References: <200401120845.47479.jkeating@j2solutions.net> <20040112165318.GV3353@codegrinder.com> <200401120914.28200.jkeating@j2solutions.net> <20040112172944.GW3353@codegrinder.com> Message-ID: <1073930941.5109.29.camel@opus> On Mon, 2004-01-12 at 12:29, Jason wrote: > On Mon, Jan 12, 2004 at 09:14:28AM -0800, Jesse Keating wrote: > Content-Description: signed data > > On Monday 12 January 2004 08:53, Jason wrote: > > > Seth posted a src.rpm to the list a week or so ago for cvs to fix a > > > more serious root exploit vuln. I was in the process of verifying it > > > to submit to the bugzilla, so I can check this out as well and patch > > > it in. > > > > You know what? I wonder if this is the same vuln.... I could be just > > cracked in the head. > > It's not .. one is a directory creation problem.. and one is a broken > switch_to_user routine, allowing switching to the root user. the second one is the one I patched in those rpms the first one looks simple enough, though. I just checked out the patch to rhl 9 - it's straightforward. -sv From jkeating at j2solutions.net Mon Jan 12 18:08:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 10:08:18 -0800 Subject: Update Announcement Format discussion In-Reply-To: References: Message-ID: <200401121008.21756.jkeating@j2solutions.net> On Sunday 11 January 2004 23:31, Chuck Wolber wrote: > Sounds like fun, but what do you mean by "system"? Are you talking > about a system that lets us automagically generate and archive update > announcements? I think we could get something put together pretty > easily. Let's hash out some req's and I'll see what I can put > together. Sounds good. I'll think today about some of the fields we'll need to keep track of and such. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Mon Jan 12 18:11:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 10:11:02 -0800 Subject: Update Announcement Format discussion In-Reply-To: <40027C34.2020507@togami.com> References: <40027C34.2020507@togami.com> Message-ID: <200401121011.02867.jkeating@j2solutions.net> On Monday 12 January 2004 02:51, Warren Togami wrote: > There are several reasons why this is a bad idea: > > 1) Advisories just don't happen so often to necessitate this. Maybe not, but it helps to streamline the process and further ensure uniformity in the announcements. > 2) http://www.fedora.us/LEGACY > Higher priority to actually work on the packages, which have been > stalled there for several days. There are people in the community that do not have the resources/capabilities to perform the QA on packages, yet still wish to contribute to the project. We should not block work from being done by some people, just because there is more "important" work to be done by others. > 3) This is a HUGE security risk. You should never have an important > signing key like advisory or package signing on any Internet > accessible host, especially with the security risk of something like > PHP or perl and apache. The signing key for packages and advisories > should be on a secured host with no public services, used for NO > OTHER PURPOSE. > > (i.e. fedora.us signing does not happen at www.fedora.us.) Which is why this form does not sign the content, rather sends it back to the user or signer in a complete text form, so that the signer can then sign the content and publish it. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From skvidal at phy.duke.edu Mon Jan 12 18:34:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 12 Jan 2004 13:34:42 -0500 Subject: vuln needs investigation and need a new form In-Reply-To: <20040112172944.GW3353@codegrinder.com> References: <200401120845.47479.jkeating@j2solutions.net> <20040112165318.GV3353@codegrinder.com> <200401120914.28200.jkeating@j2solutions.net> <20040112172944.GW3353@codegrinder.com> Message-ID: <1073932482.5109.37.camel@opus> On Mon, 2004-01-12 at 12:29, Jason wrote: > On Mon, Jan 12, 2004 at 09:14:28AM -0800, Jesse Keating wrote: > Content-Description: signed data > > On Monday 12 January 2004 08:53, Jason wrote: > > > Seth posted a src.rpm to the list a week or so ago for cvs to fix a > > > more serious root exploit vuln. I was in the process of verifying it > > > to submit to the bugzilla, so I can check this out as well and patch > > > it in. > > > > You know what? I wonder if this is the same vuln.... I could be just > > cracked in the head. > > It's not .. one is a directory creation problem.. and one is a broken > switch_to_user routine, allowing switching to the root user. > killed the old patch, applied the one from the rh9 errata, now both bugs have been treated. posted at: http://linux.duke.edu/~skvidal/RPMS/cvs/ -sv From jpdalbec at ysu.edu Mon Jan 12 18:45:27 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 12 Jan 2004 13:45:27 -0500 Subject: glibc-kernheaders Message-ID: <4002EB47.2020208@ysu.edu> This package seems to be missing from the repository. John From aleksey at nogin.org Mon Jan 12 20:39:33 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Mon, 12 Jan 2004 12:39:33 -0800 Subject: rpm2html crashes in 8.0 and rpm from legacy stable Message-ID: <40030605.4040203@nogin.org> Hi, I just installed rpm-4.1.1-1.8x from the Fedora Legacy stable repository and now rpm2html crashes (used to work fine before the upgrade) :-( Is this a known issue? The only thing I've found is http://bugzilla.fedora.us/show_bug.cgi?id=38, which is CLOSED WONTFIX :-( Obviously, breaking rpm2html conflicts with the "add-ons believed to be stable and wont interfere with other software" intent of the "stable" channel, so hopefully there is a way of fixing this. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From warren at togami.com Mon Jan 12 20:40:47 2004 From: warren at togami.com (Warren Togami) Date: Mon, 12 Jan 2004 10:40:47 -1000 Subject: glibc-kernheaders In-Reply-To: <4002EB47.2020208@ysu.edu> References: <4002EB47.2020208@ysu.edu> Message-ID: <4003064F.4000001@togami.com> John Dalbec wrote: > This package seems to be missing from the repository. > John > No, it appears to be there. What repository are you talking about? Warren From warren at togami.com Mon Jan 12 20:46:46 2004 From: warren at togami.com (Warren Togami) Date: Mon, 12 Jan 2004 10:46:46 -1000 Subject: rpm2html crashes in 8.0 and rpm from legacy stable In-Reply-To: <40030605.4040203@nogin.org> References: <40030605.4040203@nogin.org> Message-ID: <400307B6.1090405@togami.com> Aleksey Nogin wrote: > Hi, > > I just installed rpm-4.1.1-1.8x from the Fedora Legacy stable repository > and now rpm2html crashes (used to work fine before the upgrade) :-( Is > this a known issue? The only thing I've found is > http://bugzilla.fedora.us/show_bug.cgi?id=38, which is CLOSED WONTFIX :-( > > Obviously, breaking rpm2html conflicts with the "add-ons believed to be > stable and wont interfere with other software" intent of the "stable" > channel, so hopefully there is a way of fixing this. > After reading that Bugzilla report, I am afraid to say that you are just unsupported. Nobody bothered to forward port rpm2html to use the newer RPM API's. Furthermore rpm2html is not part of the base distribution. Given that many popular sites still use rpm2html, please ask around to see if anybody did that work. ftp://ftp.rpm.org/pub/rpm/dist/librpm404/ I have a hunch... does rpm2html use the rpm-4.0.4 API? Have you tried installing librpm404? Warren From smoogen at lanl.gov Mon Jan 12 21:49:33 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 12 Jan 2004 14:49:33 -0700 Subject: OT: OEM problems with aic79xx drivers Message-ID: <1073944173.25755.22.camel@smoogen1.lanl.gov> Well after spending more time than I should trying to shoehorn the latest AIC79xx driver into the last 2.4.20 kernel.. and remembering that Doug Ledford had hair before he started working on the driver... I decided it was time to look for help. Currently I have given up trying to get the 2.4.20- kernel to work with the latest aic79xx drivers.. so I went with a 2.4.24 kernel and just made a few changes to the kernel. The kernel compiled fine, and seemed to run ok, but 'crashed' horribly when I tried to do any large file transfers across the bus (dd if=/dev/zero of=/var/foo bs=1024 count=1GB) The crash is a repeatable set of scsi dumps of Jan 12 08:57:29 builder kernel: TSCB 0x86 Jan 12 08:57:29 builder kernel: qinstart = 7301 qinfifonext = 7379 Jan 12 08:57:29 builder kernel: QINFIFO: 0x84 0x83 0x82 0x8b 0x8a 0x89 0x88 0x87 0x8f 0x8e 0x8d 0x8c 0x90 0x95 0x94 0x93 0x92 0x91 0x9a 0x99 0x98 0x97 0x96 0x9f 0x9e 0x9d 0x9c 0x9b 0xa4 0xa3 0xa2 0xa1 0xa0 0xa9 0xa8 0xa7 0xa6 0xa5 0xae 0xad 0xac 0xab 0xaa 0xaf 0xb3 0xb2 0xb1 0xb0 0xb8 0xb7 0xb6 0xb5 0xb4 0xbd 0xbc 0xbb 0xba 0xb9 0xbf 0xbe 0xc2 0xc1 0xc0 0xc7 0xc6 0xc5 0xc4 0xc3 0xcc 0xcb 0xca 0xc9 0xc8 0xcf 0xce 0xcd 0xd1 0xd0 Jan 12 08:57:29 builder kernel: WAITING_TID_QUEUES: Jan 12 08:57:29 builder kernel: 1 ( 0x80 0x86 0x85 ) Jan 12 08:57:29 builder kernel: Pending list: then a long list of FIFO items. I blocked that problem by going into the SCSI BIOS and turning off packetization. That of course makes the 320 mb/s into 160mb/s drives. Part of the reason for this push on my part is that our 7.x machines have SuperMicro motherboards with aic7902 cards built on and we have been seeing slow disk corruptions over time. I have yet to find anyone else seeing this problem.. so am having to figure out what makes our systems unique. The problem doesnt show up on a bonnie++ check, but our 30 imap servers have consistently killed a drive a week since we brought them online last august. So if anyone else runs into this problem supporting 7.x machines.. here is what I am trying to do to see if it fixes the problem: 1) Turn off packetization 2) Compiling a standard kernel with a SCB lenght of 32 versus teh default of 253. 3) Waving a magic chicken foot at the machines. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From xose at wanadoo.es Mon Jan 12 22:00:22 2004 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 12 Jan 2004 23:00:22 +0100 Subject: OT: OEM problems with aic79xx drivers References: <1073944173.25755.22.camel@smoogen1.lanl.gov> Message-ID: <400318F6.6000609@wanadoo.es> Stephen Smoogen wrote: > Well after spending more time than I should trying to shoehorn the > latest AIC79xx driver into the last 2.4.20 kernel.. and remembering that > Doug Ledford had hair before he started working on the driver... I > decided it was time to look for help. try it in the aic7xxx ml: http://lists.freebsd.org/mailman/listinfo/aic7xxx From smoogen at lanl.gov Mon Jan 12 22:11:14 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 12 Jan 2004 15:11:14 -0700 Subject: OT: OEM problems with aic79xx drivers In-Reply-To: <400318F6.6000609@wanadoo.es> References: <1073944173.25755.22.camel@smoogen1.lanl.gov> <400318F6.6000609@wanadoo.es> Message-ID: <1073945473.25755.25.camel@smoogen1.lanl.gov> On Mon, 2004-01-12 at 15:00, Xose Vazquez Perez wrote: > Stephen Smoogen wrote: > > > Well after spending more time than I should trying to shoehorn the > > latest AIC79xx driver into the last 2.4.20 kernel.. and remembering that > > Doug Ledford had hair before he started working on the driver... I > > decided it was time to look for help. > > try it in the aic7xxx ml: http://lists.freebsd.org/mailman/listinfo/aic7xxx Sure.. point out the obvious :P. Sorry.. I cant believe I didnt do the right thing the first time. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From pearcec at commnav.com Mon Jan 12 22:13:53 2004 From: pearcec at commnav.com (Christian Pearce) Date: Mon, 12 Jan 2004 22:13:53 GMT Subject: cvs packages for RedHat 8.0 and cvs QAd... Message-ID: <57601.209.50.130.84.1073945633.commnav@home.commnav.com> I added a src rpm for RHL 8.0 for cvs. I also QAd the cvs packages for RHL 7.2 and RHL 7.3. Hope this helps please let me know if I did something wrong. -- Christian Pearce http://www.commnav.com From cra at WPI.EDU Mon Jan 12 23:37:05 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 12 Jan 2004 18:37:05 -0500 Subject: rpm2html crashes in 8.0 and rpm from legacy stable In-Reply-To: <400307B6.1090405@togami.com> References: <40030605.4040203@nogin.org> <400307B6.1090405@togami.com> Message-ID: <20040112233705.GH27289@angus.ind.WPI.EDU> On Mon, Jan 12, 2004 at 10:46:46AM -1000, Warren Togami wrote: > After reading that Bugzilla report, I am afraid to say that you are just > unsupported. Nobody bothered to forward port rpm2html to use the newer > RPM API's. Furthermore rpm2html is not part of the base distribution. Appears to be part of the distro: redhat/linux/8.0/en/os/i386/RedHat/RPMS/rpm2html-1.7-8.i386.rpm redhat/linux/8.0/en/os/i386/SRPMS/rpm2html-1.7-8.src.rpm > Given that many popular sites still use rpm2html, please ask around to > see if anybody did that work. > > ftp://ftp.rpm.org/pub/rpm/dist/librpm404/ > I have a hunch... does rpm2html use the rpm-4.0.4 API? Have you tried > installing librpm404? It doesn't appear to: rpm -qp --requires redhat/linux/8.0/en/os/i386/RedHat/RPMS/rpm2html-1.7-8.i386.rpm rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libdb.so.2 libm.so.6 libpopt.so.0 librpm-4.1.so librpmdb-4.1.so librpmio-4.1.so libxml2.so.2 libz.so.1 Unfortunately, I don't have an 8.0 system to work on this... From smoogen at lanl.gov Mon Jan 12 23:47:51 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 12 Jan 2004 16:47:51 -0700 Subject: OT: OEM problems with aic79xx drivers In-Reply-To: <1073945473.25755.25.camel@smoogen1.lanl.gov> References: <1073944173.25755.22.camel@smoogen1.lanl.gov> <400318F6.6000609@wanadoo.es> <1073945473.25755.25.camel@smoogen1.lanl.gov> Message-ID: <1073951271.25755.28.camel@smoogen1.lanl.gov> On Mon, 2004-01-12 at 15:11, Stephen Smoogen wrote: > On Mon, 2004-01-12 at 15:00, Xose Vazquez Perez wrote: > > Stephen Smoogen wrote: > > > > > Well after spending more time than I should trying to shoehorn the > > > latest AIC79xx driver into the last 2.4.20 kernel.. and remembering that > > > Doug Ledford had hair before he started working on the driver... I > > > decided it was time to look for help. > > > > try it in the aic7xxx ml: http://lists.freebsd.org/mailman/listinfo/aic7xxx > > Sure.. point out the obvious :P. Sorry.. I cant believe I didnt do the > right thing the first time. My apologies again. I spent 3 days googling and didnt see this obvious item.. went to it, read and figured out that the main problems are: 1) When compiling the module limit the SCB to 32 versus 256 2) The hardware is sensitive to cabling, backplanes, and terminators. This seems to have been the root of the problem. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From warren at togami.com Tue Jan 13 01:29:41 2004 From: warren at togami.com (Warren Togami) Date: Mon, 12 Jan 2004 15:29:41 -1000 Subject: rpm2html crashes in 8.0 and rpm from legacy stable In-Reply-To: <20040112233705.GH27289@angus.ind.WPI.EDU> References: <40030605.4040203@nogin.org> <400307B6.1090405@togami.com> <20040112233705.GH27289@angus.ind.WPI.EDU> Message-ID: <40034A05.9080105@togami.com> Charles R. Anderson wrote: > On Mon, Jan 12, 2004 at 10:46:46AM -1000, Warren Togami wrote: > >>After reading that Bugzilla report, I am afraid to say that you are just >>unsupported. Nobody bothered to forward port rpm2html to use the newer >>RPM API's. Furthermore rpm2html is not part of the base distribution. > > > Appears to be part of the distro: > > redhat/linux/8.0/en/os/i386/RedHat/RPMS/rpm2html-1.7-8.i386.rpm > redhat/linux/8.0/en/os/i386/SRPMS/rpm2html-1.7-8.src.rpm > My mistake... hmmm this is a regression, but there are simple ways to workaround this problem. I'll try find you an easy way, or fix rpm2html, or both. Warren From aleksey at nogin.org Tue Jan 13 04:04:21 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Mon, 12 Jan 2004 20:04:21 -0800 Subject: rpm2html crashes in 8.0 and rpm from legacy stable In-Reply-To: <40034A05.9080105@togami.com> References: <40030605.4040203@nogin.org> <400307B6.1090405@togami.com> <20040112233705.GH27289@angus.ind.WPI.EDU> <40034A05.9080105@togami.com> Message-ID: <40036E45.8020900@nogin.org> On 12.01.2004 17:29, Warren Togami wrote: > My mistake... hmmm this is a regression, but there are simple ways to > workaround this problem. I tried: a) Using rpm2html-1.7-8 from Red Hat Linux 8.0 b) Using ftp://rpmfind.net/pub/rpm2html/rpm2html-1.8.1-1.i386.rpm c) Rebuilding ftp://rpmfind.net/pub/rpm2html/rpm2html-1.8.1-1.src.rpm on Red Hat Linux 8.0 + Fedora Legacy 8.0 (e.g. rpm-devel-4.1.1-1.8x) d) Rebuilding ftp://rpmfind.net/pub/rpm2html/rpm2html-1.8.2-2.src.rpm on Red Hat Linux 8.0 + Fedora Legacy 8.0 (e.g. rpm-devel-4.1.1-1.8x) e) Using rpm2html-1.8.1 binaries I've build earlier in Oct'03 (on Red Hat Linux 8.0 + up2date) that worked fine until I upgraded rpm to 4.1.1 from Fedora Legacy In all 5 cases, it crashes :-( (a), (d) and (e) all crash when reading http://rpmbin.nogin.org/MetaPRL/fedora-1/omake-0.7.9-1.fedora1.i386.rpm > I'll try find you an easy way, or fix > rpm2html, or both. Thanks! -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From aleksey at nogin.org Tue Jan 13 05:27:23 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Mon, 12 Jan 2004 21:27:23 -0800 Subject: Solution found [Was: rpm2html crashes in 8.0 and rpm from legacy stable] In-Reply-To: <40034A05.9080105@togami.com> References: <40030605.4040203@nogin.org> <400307B6.1090405@togami.com> <20040112233705.GH27289@angus.ind.WPI.EDU> <40034A05.9080105@togami.com> Message-ID: <400381BB.1030904@nogin.org> On 12.01.2004 17:29, Warren Togami wrote: > My mistake... hmmm this is a regression, but there are simple ways to > workaround this problem. I'll try find you an easy way, or fix > rpm2html, or both. Interesting - I realized that the existing spec file for rpm2html included a call to an "autogen.sh" script in %pre, which in turn called configure, as well as a separate configure call in %build. After I removed the second configure call (moving its arguments to the autogen. sh script, which passes them back to configure), rpm2html stopped crashing! See http://rpm.nogin.org/regularly_built/rh80/rpm2html-1.8.2-3.rh8.0.i386.html for source and binary RPMs. P.S. I would suggest adding a working rpm2html to the "stable" channel of Fedora Legacy 8.0 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From warren at togami.com Tue Jan 13 05:34:34 2004 From: warren at togami.com (Warren Togami) Date: Mon, 12 Jan 2004 19:34:34 -1000 Subject: Solution found [Was: rpm2html crashes in 8.0 and rpm from legacy stable] In-Reply-To: <400381BB.1030904@nogin.org> References: <40030605.4040203@nogin.org> <400307B6.1090405@togami.com> <20040112233705.GH27289@angus.ind.WPI.EDU> <40034A05.9080105@togami.com> <400381BB.1030904@nogin.org> Message-ID: <4003836A.6030600@togami.com> Aleksey Nogin wrote: > On 12.01.2004 17:29, Warren Togami wrote: > >> My mistake... hmmm this is a regression, but there are simple ways to >> workaround this problem. I'll try find you an easy way, or fix >> rpm2html, or both. > > > Interesting - I realized that the existing spec file for rpm2html > included a call to an "autogen.sh" script in %pre, which in turn called > configure, as well as a separate configure call in %build. After I > removed the second configure call (moving its arguments to the autogen. > sh script, which passes them back to configure), rpm2html stopped crashing! > > See > http://rpm.nogin.org/regularly_built/rh80/rpm2html-1.8.2-3.rh8.0.i386.html > for source and binary RPMs. > > P.S. I would suggest adding a working rpm2html to the "stable" channel > of Fedora Legacy 8.0 > Umm, "stable" channel does not have the rpm-4.1.1 upgrade. Only patches-stable and legacy contain those. I suppose we could issue a fixed rpm2html package in the legacy channel but only if nobody objects. Warren From jkeating at j2solutions.net Tue Jan 13 05:35:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Jan 2004 21:35:13 -0800 Subject: Solution found [Was: rpm2html crashes in 8.0 and rpm from legacy stable] In-Reply-To: <400381BB.1030904@nogin.org> References: <40030605.4040203@nogin.org> <40034A05.9080105@togami.com> <400381BB.1030904@nogin.org> Message-ID: <200401122135.13670.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 January 2004 21:27, Aleksey Nogin wrote: > Interesting - I realized that the existing spec file for rpm2html > included a call to an "autogen.sh" script in %pre, which in turn > called configure, as well as a separate configure call in %build. > After I removed the second configure call (moving its arguments to > the autogen. sh script, which passes them back to configure), > rpm2html stopped crashing! > > See > http://rpm.nogin.org/regularly_built/rh80/rpm2html-1.8.2-3.rh8.0.i386 >.html for source and binary RPMs. > > P.S. I would suggest adding a working rpm2html to the "stable" > channel of Fedora Legacy 8.0 Is only 8.0 effected? What about 7.3? Either way, is there anybody willing to sponser this package, and then QA it? - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAA4OR4v2HLvE71NURArTgAJ4+n83EXzovGz8bqOspmznWnuKJrQCfYqjd Z2jflE53TwjGIbAwVF1kZwE= =uy9h -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Tue Jan 13 07:52:59 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 13 Jan 2004 08:52:59 +0100 Subject: Solution found [Was: rpm2html crashes in 8.0 and rpm from legacy stable] In-Reply-To: <200401122135.13670.jkeating@j2solutions.net> References: <40030605.4040203@nogin.org> <40034A05.9080105@togami.com> <400381BB.1030904@nogin.org> <200401122135.13670.jkeating@j2solutions.net> Message-ID: <20040113085259.12266525.ms-nospam-0306@arcor.de> On Mon, 12 Jan 2004 21:35:13 -0800, Jesse Keating wrote: > On Monday 12 January 2004 21:27, Aleksey Nogin wrote: > > Interesting - I realized that the existing spec file for rpm2html > > included a call to an "autogen.sh" script in %pre, which in turn > > called configure, as well as a separate configure call in %build. > > After I removed the second configure call (moving its arguments to > > the autogen. sh script, which passes them back to configure), > > rpm2html stopped crashing! > > > > See > > http://rpm.nogin.org/regularly_built/rh80/rpm2html-1.8.2-3.rh8.0.i386 > >.html for source and binary RPMs. > > > > P.S. I would suggest adding a working rpm2html to the "stable" > > channel of Fedora Legacy 8.0 > > Is only 8.0 effected? What about 7.3? Either way, is there anybody > willing to sponser this package, and then QA it? It ought to be investigated what the autogen/configure change results in. Comparing config.h (if it exists) might help. It shouldn't be a trial and error build that works by accident. autogen usually only recreates autoconf/automake files, such as configure script, m4 macros and makefile templates. -- From andy.henson.fedora at zexia.co.uk Tue Jan 13 09:54:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Tue, 13 Jan 2004 09:54 +0000 (GMT Standard Time) Subject: vuln needs investigation and need a new form In-Reply-To: <1073932482.5109.37.camel@opus> Message-ID: Is this the -8.7.duke.2 one? Should this be renamed -9.7x.legacy for Fedora Legacy use? Do we have a bugzilla number for it? Andy From warren at togami.com Tue Jan 13 10:02:01 2004 From: warren at togami.com (Warren Togami) Date: Tue, 13 Jan 2004 00:02:01 -1000 Subject: vuln needs investigation and need a new form In-Reply-To: References: Message-ID: <4003C219.6070407@togami.com> Andy Henson wrote: > Is this the -8.7.duke.2 one? > > Should this be renamed -9.7x.legacy for Fedora Legacy use? > > Do we have a bugzilla number for it? > > Andy > > Probably yes, but if you care enough about it, then do it yourself. Otherwise it may never be done. Make sure you read the processes and see the other current submissions as examples first. http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/LEGACY From warren at togami.com Tue Jan 13 10:16:39 2004 From: warren at togami.com (Warren Togami) Date: Tue, 13 Jan 2004 00:16:39 -1000 Subject: Solution found [Was: rpm2html crashes in 8.0 and rpm from legacy stable] In-Reply-To: <200401122135.13670.jkeating@j2solutions.net> References: <40030605.4040203@nogin.org> <40034A05.9080105@togami.com> <400381BB.1030904@nogin.org> <200401122135.13670.jkeating@j2solutions.net> Message-ID: <4003C587.2000603@togami.com> Jesse Keating wrote: > > Is only 8.0 effected? What about 7.3? Either way, is there anybody > willing to sponser this package, and then QA it? > http://bugzilla.fedora.us/show_bug.cgi?id=38 Warren From andy.henson.fedora at zexia.co.uk Tue Jan 13 10:55:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Tue, 13 Jan 2004 10:55 +0000 (GMT Standard Time) Subject: Update for CVS (was Re: vuln needs investigation and need a new form) In-Reply-To: <4003C219.6070407@togami.com> Message-ID: Thanks, Warren. Answering my own question... the bugzilla number is 1207. https://bugzilla.fedora.us/show_bug.cgi?id=1207 It looks as if Jason and Christian have got there first. I'll test. Andy From m.a.young at durham.ac.uk Tue Jan 13 17:12:09 2004 From: m.a.young at durham.ac.uk (M A Young) Date: Tue, 13 Jan 2004 17:12:09 +0000 (GMT) Subject: OT: OEM problems with aic79xx drivers In-Reply-To: <1073944173.25755.22.camel@smoogen1.lanl.gov> References: <1073944173.25755.22.camel@smoogen1.lanl.gov> Message-ID: On Mon, 12 Jan 2004, Stephen Smoogen wrote: > Well after spending more time than I should trying to shoehorn the > latest AIC79xx driver into the last 2.4.20 kernel.. and remembering that > Doug Ledford had hair before he started working on the driver... I > decided it was time to look for help. > > So if anyone else runs into this problem supporting 7.x machines.. here > is what I am trying to do to see if it fixes the problem: > > 1) Turn off packetization > 2) Compiling a standard kernel with a SCB lenght of 32 versus teh > default of 253. > 3) Waving a magic chicken foot at the machines. I reckon 2 is your best bet, indeed recent Fedora/Redhat kernels use SCB length 32, and it is the default for mainline kernels. (It might be possible to force this value in the initrd somewhere even it isn't set in the kernel). The other thing to try is to get the latest source from http://people.freebsd.org/~gibbs/linux/ But setting CONFIG_AIC7{X,9}XX_CMDS_PER_DEVICE to 32 is still a good idea. Michael Young From jpdalbec at ysu.edu Tue Jan 13 18:36:04 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 13 Jan 2004 13:36:04 -0500 Subject: glibc-kernheaders In-Reply-To: <20040113170004.17935.64360.Mailman@listman.back-rdu.redhat.com> References: <20040113170004.17935.64360.Mailman@listman.back-rdu.redhat.com> Message-ID: <40043A94.3010004@ysu.edu> > Date: Mon, 12 Jan 2004 10:40:47 -1000 > From: Warren Togami > To: fedora-legacy-list at redhat.com > Subject: Re: glibc-kernheaders > Reply-To: fedora-legacy-list at redhat.com > > John Dalbec wrote: > >>> This package seems to be missing from the repository. >>> John >>> > > > No, it appears to be there. What repository are you talking about? > > Warren Oops. I wrote a script to give me a plain-text listing of the RPM files in the repository. To skip the "headers" directories I threw in a "grep -v headers". Naturally this also skipped over the glibc-kernheaders packages. Sorry for the noise, John From ville.skytta at iki.fi Tue Jan 13 20:25:13 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Jan 2004 22:25:13 +0200 Subject: Update Announcement Format discussion In-Reply-To: <200401120919.12782.jkeating@j2solutions.net> References: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> <200401120919.12782.jkeating@j2solutions.net> Message-ID: <1074025513.14983.81.camel@bobcat.mine.nu> On Mon, 2004-01-12 at 19:19, Jesse Keating wrote: > For now, just the last entry. In the future, when I have the software > I'm dreaming up to make a webpage module out of a directory tree of > RPMs, flush with data such as description and such, we may be able to > point to this for the changelog in full. But for now, just the > relevant parts. Fancix already does quite a bit of that... dynamically. It's in alpha state currently: http://sf.net/projects/fancix/, and RPMs + deps from http://cachalot.mine.nu/ and fedora.us repos. From skvidal at phy.duke.edu Tue Jan 13 20:30:11 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 13 Jan 2004 15:30:11 -0500 Subject: Update Announcement Format discussion In-Reply-To: <1074025513.14983.81.camel@bobcat.mine.nu> References: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> <200401120919.12782.jkeating@j2solutions.net> <1074025513.14983.81.camel@bobcat.mine.nu> Message-ID: <1074025811.9525.27.camel@opus> On Tue, 2004-01-13 at 15:25, Ville Skytt?? wrote: > On Mon, 2004-01-12 at 19:19, Jesse Keating wrote: > > > For now, just the last entry. In the future, when I have the software > > I'm dreaming up to make a webpage module out of a directory tree of > > RPMs, flush with data such as description and such, we may be able to > > point to this for the changelog in full. But for now, just the > > relevant parts. > > > Fancix already does quite a bit of that... dynamically. It's in alpha > state currently: http://sf.net/projects/fancix/, and RPMs + deps from > http://cachalot.mine.nu/ and fedora.us repos. > > Ville, We should talk about: http://linux.duke.edu/metadata - specifically the generate/createrepo program that makes xml out of a hierarchy of rpms. IT could make fancix be a little less abusive to a server when looking through lots of files. -sv From ville.skytta at iki.fi Tue Jan 13 20:42:28 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Jan 2004 22:42:28 +0200 Subject: Update Announcement Format discussion In-Reply-To: <1074025811.9525.27.camel@opus> References: <20040112112000.w9w0s0s4wwkkcwgc@mail.ph.utexas.edu> <200401120919.12782.jkeating@j2solutions.net> <1074025513.14983.81.camel@bobcat.mine.nu> <1074025811.9525.27.camel@opus> Message-ID: <1074026548.14983.95.camel@bobcat.mine.nu> On Tue, 2004-01-13 at 22:30, seth vidal wrote: > We should talk about: http://linux.duke.edu/metadata - specifically the > generate/createrepo program that makes xml out of a hierarchy of rpms. That sounds interesting, unfortunately I haven't had time to take a look into the metadata stuff at all (yet). > IT could make fancix be a little less abusive to a server when looking > through lots of files. Sure, but I think that may be a bit out of scope for Fancix, although probably better suitable for the purposes discussed here. Fancix was created specifically for the purpose of (well, learning Python and...) doing things dynamically. The itch I wanted to scratch was to do dynamic stuff, like on-the-fly extracting files from inside tarballs, zips, rpms (not implemented yet for rpms - anyone know a Python cpio library?) etc. From warren at togami.com Wed Jan 14 12:11:49 2004 From: warren at togami.com (Warren Togami) Date: Wed, 14 Jan 2004 02:11:49 -1000 Subject: Website documentation and LEGACY package queue Message-ID: <40053205.1000106@togami.com> I am currently well beyond the burn out point, so you cannot count me to continue to push Legacy forward. I will only continue mainly in an advisory position, replicating the build server and signing infrastructure to Jesse Keatings and PogoLinux sponsored server to be hosted at QuantumLinux. Other than that, I will try to post mainly about the large needs of the project and ways in which you can help, until it is no longer needed. http://www.fedoralegacy.org/ Think about what a user seeking help from the EOL disaster would think when they see the page. For one, the Legacy Launch Plan (draft 2) is very old by this point. Another thing is the complete lack of mention of the existing published yum for RH7.x. Overall some parts like the launch plan need to be rewritten & replaced entirely, perhaps with a project overview type thing. The rest of the site needs a lot more explanation about how things work, and what the user needs to do, but unfortunately that cannot come without the packages being worked on, QA'ed and published. http://www.fedora.us/LEGACY Do your best to work within the existing fedora.us policies, and discuss here about ways to further modify those rules for legacy. I will update the fedora.us documentation to match the saner ideas in the discussion. I will help by building whatever is approved, and sometimes approving packages myself. I personally have the capability to QA and test packages on RH8 only, but due to limited time I will only do a select few. (Like CVS is probably the most serious right now.) Bye for now... Warren From pearcec at commnav.com Wed Jan 14 14:14:19 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 14 Jan 2004 14:14:19 GMT Subject: Website documentation and LEGACY package queue Message-ID: <59293.209.50.130.84.1074089659.commnav@home.commnav.com> On Jan 14, 2004, Warren Togami wrote: > > I am currently well beyond the burn out point, so you cannot count me to > continue to push Legacy forward. I will only continue mainly in an > advisory position, replicating the build server and signing > infrastructure to Jesse Keatings and PogoLinux sponsored server to be > hosted at QuantumLinux. Other than that, I will try to post mainly > about the large needs of the project and ways in which you can help, > until it is no longer needed. Thanks. > http://www.fedoralegacy.org/ > > Think about what a user seeking help from the EOL disaster would think > when they see the page. For one, the Legacy Launch Plan (draft 2) is > very old by this point. Another thing is the complete lack of mention > of the existing published yum for RH7.x. Overall some parts like the > launch plan need to be rewritten & replaced entirely, perhaps with a > project overview type thing. I think at this point the "Plan" should just become what are policy is. Right? I will take some time today and try to review the site and come up with a laundry list of items. Then work on some of what I can. > The rest of the site needs a lot more explanation about how things work, > and what the user needs to do, but unfortunately that cannot come > without the packages being worked on, QA'ed and published. > > http://www.fedora.us/LEGACY > > Do your best to work within the existing fedora.us policies, and discuss > here about ways to further modify those rules for legacy. I will update > the fedora.us documentation to match the saner ideas in the > discussion. I will help by building whatever is approved, and sometimes > approving packages myself. I personally have the capability to QA and > test packages on RH8 only, but due to limited time I will only do a > select few. (Like CVS is probably the most serious right now.) Thanks for your help. -- Christian Pearce http://www.commnav.com From pearcec at commnav.com Wed Jan 14 14:38:43 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 14 Jan 2004 14:38:43 GMT Subject: RHSA-2004-006: kdepim released by Red Hat Message-ID: <59442.209.50.130.84.1074091123.commnav@home.commnav.com> https://rhn.redhat.com/errata/RHSA-2004-006.html Add another one to the stack. Does anyone have a good hole out there? I feel like bury my head in the sand. I am currently reviewing the site for update. Is anyone out there a good writer? I can attempt to write but I am usually not easy to understand. I am willing to do some first drafts. -- Christian Pearce http://www.commnav.com From rohwedde at codegrinder.com Wed Jan 14 16:47:16 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 14 Jan 2004 10:47:16 -0600 Subject: RHSA-2004-006: kdepim released by Red Hat In-Reply-To: <59442.209.50.130.84.1074091123.commnav@home.commnav.com> References: <59442.209.50.130.84.1074091123.commnav@home.commnav.com> Message-ID: <20040114164716.GA3353@codegrinder.com> It doesn't look like RH7.x or RH8.0 would be affected. From http://www.kde.org/info/security/advisory-20040114-1.txt >1. Systems affected: > >All versions of kdepim as distributed with KDE versions 3.1.0 >through 3.1.4 inclusive. That said it might be worth someone's time to look at the patch linked in that doc and see if it applies to 3.0.x which is in RH7 and 8 I probably won't have time to dedicate to that today. -jason On Wed, Jan 14, 2004 at 02:38:43PM +0000, Christian Pearce wrote: > https://rhn.redhat.com/errata/RHSA-2004-006.html > > Add another one to the stack. Does anyone have a good hole out there? I feel like bury my head in the sand. > > I am currently reviewing the site for update. Is anyone out there a good writer? I can attempt to write but I am usually not easy to understand. I am willing to do some first drafts. > -- > Christian Pearce > http://www.commnav.com > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Wed Jan 14 16:48:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Jan 2004 11:48:44 -0500 Subject: RHSA-2004-006: kdepim released by Red Hat In-Reply-To: <20040114164716.GA3353@codegrinder.com> References: <59442.209.50.130.84.1074091123.commnav@home.commnav.com> <20040114164716.GA3353@codegrinder.com> Message-ID: <1074098924.2998.49.camel@binkley> On Wed, 2004-01-14 at 11:47, Jason wrote: > It doesn't look like RH7.x or RH8.0 would be affected. From > http://www.kde.org/info/security/advisory-20040114-1.txt > > >1. Systems affected: > > > >All versions of kdepim as distributed with KDE versions 3.1.0 > >through 3.1.4 inclusive. > > That said it might be worth someone's time to look at the patch linked > in that doc and see if it applies to 3.0.x which is in RH7 and 8 > > I probably won't have time to dedicate to that today. I'm going to have to look at the patch anyway - I'll take a stab at it later today or tonight. if anyone gets to it first let me know. -sv From Bernd.Bartmann at sohanet.de Wed Jan 14 17:03:13 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Wed, 14 Jan 2004 18:03:13 +0100 Subject: Red Hat released new elm package for RHAS 2.1 Message-ID: <40057651.5080902@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also released updated elm packages for RHAS 2.1 that fix a buffer overflow vulnerability in the 'frm' command. Please have a look at: https://rhn.redhat.com/errata/RHSA-2004-009.html elm is included in RHL 7.2 and 7.3 but not in 8.0. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFABXZRkQuIaHu84cIRAhImAJ9EQYtFnQH9Oz63cH12MJ8IDpS2mgCePsKn LxKpUbit8lqvhXmJpqsDvTU= =vVdp -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Wed Jan 14 18:41:33 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Jan 2004 13:41:33 -0500 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <40057651.5080902@sohanet.de> References: <40057651.5080902@sohanet.de> Message-ID: <1074105693.2998.53.camel@binkley> On Wed, 2004-01-14 at 12:03, Bernd Bartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also > released updated elm packages for RHAS 2.1 that fix a buffer overflow > vulnerability in the 'frm' command. Please have a look at: > > https://rhn.redhat.com/errata/RHSA-2004-009.html > If there are admins out there who have users using elm or users who are using it who would like fix up a package and submit I'm sure it would be just fine. Personally, I don't have any of those users and I don't have the sparetime to spend on applications I don't use. -sv From Craig.Miskell at agresearch.co.nz Wed Jan 14 18:54:52 2004 From: Craig.Miskell at agresearch.co.nz (Miskell, Craig) Date: Thu, 15 Jan 2004 07:54:52 +1300 Subject: RHSA-2004-006: kdepim released by Red Hat Message-ID: -----Original Message----- > From: Christian Pearce [mailto:pearcec at commnav.com] > Sent: Thursday, 15 January 2004 3:39 a.m. > To: fedora-legacy-list at redhat.com > Subject: RHSA-2004-006: kdepim released by Red Hat > I am currently reviewing the site for update. Is anyone out > there a good writer? I can attempt to write but I am usually > not easy to understand. I am willing to do some first drafts. I have the same problem, but I find I'm pretty good at reviewing what other people write and clarifying it ;-). Send stuff my way and I'll help out. Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From jonny.strom at netikka.fi Wed Jan 14 19:07:38 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 14 Jan 2004 21:07:38 +0200 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <1074105693.2998.53.camel@binkley> References: <40057651.5080902@sohanet.de> <1074105693.2998.53.camel@binkley> Message-ID: <4005937A.4030006@netikka.fi> seth vidal wrote: > On Wed, 2004-01-14 at 12:03, Bernd Bartmann wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Hi all, >> >>FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also >>released updated elm packages for RHAS 2.1 that fix a buffer overflow >>vulnerability in the 'frm' command. Please have a look at: >> >>https://rhn.redhat.com/errata/RHSA-2004-009.html >> > > > If there are admins out there who have users using elm or users who are > using it who would like fix up a package and submit I'm sure it would be > just fine. Personally, I don't have any of those users and I don't have > the sparetime to spend on applications I don't use. > > Hi all I trying to get a patch for this issue I mail back when I have some more results. Cheers Johnny -sv > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rohwedde at codegrinder.com Wed Jan 14 19:17:15 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 14 Jan 2004 13:17:15 -0600 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <4005937A.4030006@netikka.fi> References: <40057651.5080902@sohanet.de> <1074105693.2998.53.camel@binkley> <4005937A.4030006@netikka.fi> Message-ID: <20040114191715.GC3353@codegrinder.com> On Wed, Jan 14, 2004 at 09:07:38PM +0200, Johnny Strom wrote: > seth vidal wrote: > >On Wed, 2004-01-14 at 12:03, Bernd Bartmann wrote: > > > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >>Hi all, > >> > >>FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also > >>released updated elm packages for RHAS 2.1 that fix a buffer overflow > >>vulnerability in the 'frm' command. Please have a look at: > >> > >>https://rhn.redhat.com/errata/RHSA-2004-009.html > >> > > > > > >If there are admins out there who have users using elm or users who are > >using it who would like fix up a package and submit I'm sure it would be > >just fine. Personally, I don't have any of those users and I don't have > >the sparetime to spend on applications I don't use. > > > > > > Hi all > > > I trying to get a patch for this issue I mail back when I have some more > results. > > > Cheers Johnny RHAS 2.1 rpm's should be pretty close to 7.x. You should be able to get the src.rpm from ftp://updates.redhat.com:/enterprise/2.1AS/en/os/SRPMS and check against our sources to see if the patch they use is applicable. -j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpdalbec at ysu.edu Wed Jan 14 19:50:04 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 14 Jan 2004 14:50:04 -0500 Subject: fedora-legacy-list digest, Vol 1 #51 - 10 msgs In-Reply-To: <20040114170002.11389.35322.Mailman@listman.back-rdu.redhat.com> References: <20040114170002.11389.35322.Mailman@listman.back-rdu.redhat.com> Message-ID: <40059D6C.2010206@ysu.edu> Is there a way to see a listing of the "stack"? John > Date: Wed, 14 Jan 2004 14:38:43 GMT > Subject: RHSA-2004-006: kdepim released by Red Hat > From: "Christian Pearce" > To: fedora-legacy-list at redhat.com > Reply-To: fedora-legacy-list at redhat.com > > https://rhn.redhat.com/errata/RHSA-2004-006.html > > Add another one to the stack. Does anyone have a good hole out there? I feel like bury my head in the sand. > > I am currently reviewing the site for update. Is anyone out there a good writer? I can attempt to write but I am usually not easy to understand. I am willing to do some first drafts. > -- > Christian Pearce > http://www.commnav.com From rohwedde at codegrinder.com Wed Jan 14 20:25:14 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 14 Jan 2004 14:25:14 -0600 Subject: fedora-legacy-list digest, Vol 1 #51 - 10 msgs In-Reply-To: <40059D6C.2010206@ysu.edu> References: <20040114170002.11389.35322.Mailman@listman.back-rdu.redhat.com> <40059D6C.2010206@ysu.edu> Message-ID: <20040114202514.GF3353@codegrinder.com> http://fedora.us/LEGACY for issues that currently have bugs assigned to them. -jason On Wed, Jan 14, 2004 at 02:50:04PM -0500, John Dalbec wrote: > Is there a way to see a listing of the "stack"? > John > > >Date: Wed, 14 Jan 2004 14:38:43 GMT > >Subject: RHSA-2004-006: kdepim released by Red Hat > >From: "Christian Pearce" > >To: fedora-legacy-list at redhat.com > >Reply-To: fedora-legacy-list at redhat.com > > > >https://rhn.redhat.com/errata/RHSA-2004-006.html > > > >Add another one to the stack. Does anyone have a good hole out there? I > >feel like bury my head in the sand. > > > >I am currently reviewing the site for update. Is anyone out there a good > >writer? I can attempt to write but I am usually not easy to understand. > >I am willing to do some first drafts. > >-- > >Christian Pearce > >http://www.commnav.com > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michal at harddata.com Wed Jan 14 20:28:10 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 14 Jan 2004 13:28:10 -0700 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <20040114191715.GC3353@codegrinder.com>; from rohwedde@codegrinder.com on Wed, Jan 14, 2004 at 01:17:15PM -0600 References: <40057651.5080902@sohanet.de> <1074105693.2998.53.camel@binkley> <4005937A.4030006@netikka.fi> <20040114191715.GC3353@codegrinder.com> Message-ID: <20040114132810.B17022@mail.harddata.com> On Wed, Jan 14, 2004 at 01:17:15PM -0600, Jason wrote: > On Wed, Jan 14, 2004 at 09:07:38PM +0200, Johnny Strom wrote: > > > > I trying to get a patch for this issue I mail back when I have some more > > results. > > > > > > Cheers Johnny > > RHAS 2.1 rpm's should be pretty close to 7.x. You should be able to get > the src.rpm from ftp://updates.redhat.com:/enterprise/2.1AS/en/os/SRPMS This particular package just rebuilds on 7.3 with rpmbuild --rebuild elm-2.5.6-4.src.rpm The original is elm-2.5.6-2. Michal From pearcec at commnav.com Wed Jan 14 20:38:21 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 14 Jan 2004 20:38:21 GMT Subject: Red Hat released new elm package for RHAS 2.1 Message-ID: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> Seth brings up an interesting issue. If we don't have people interested in fixing a package, then it will still be vulnerable. Should we keep track of this in bugzilla? Just create a bug and tag it NOOWNER. Or something like that? This way we don't give people the idea that everything is fixed security wise if you use FedoraLegacy. Just a thought. -- Christian Pearce http://www.commnav.com seth vidal said: > > On Wed, 2004-01-14 at 12:03, Bernd Bartmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi all, > > > > FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also > > released updated elm packages for RHAS 2.1 that fix a buffer overflow > > vulnerability in the 'frm' command. Please have a look at: > > > > https://rhn.redhat.com/errata/RHSA-2004-009.html > > > > If there are admins out there who have users using elm or users who are > using it who would like fix up a package and submit I'm sure it would be > just fine. Personally, I don't have any of those users and I don't have > the sparetime to spend on applications I don't use. > > -sv > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rohwedde at codegrinder.com Wed Jan 14 20:42:50 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 14 Jan 2004 14:42:50 -0600 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> Message-ID: <20040114204250.GG3353@codegrinder.com> That would probably be good.. we could use the NEEDSWORK tag which I think already exists. And, I think there should certainly be the goal to patch everything that needs it.. even if a few people end up as clean up crew. -jason On Wed, Jan 14, 2004 at 08:38:21PM +0000, Christian Pearce wrote: > Seth brings up an interesting issue. If we don't have people interested in fixing a package, then it will still be vulnerable. Should we keep track of this in bugzilla? Just create a bug and tag it NOOWNER. Or something like that? This way we don't give people the idea that everything is fixed security wise if you use FedoraLegacy. > > Just a thought. > > -- > Christian Pearce > http://www.commnav.com > > > > seth vidal said: > > > > On Wed, 2004-01-14 at 12:03, Bernd Bartmann wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hi all, > > > > > > FYI: Besides the kdepim, cvs and httpd update for RHES3 Red Hat also > > > released updated elm packages for RHAS 2.1 that fix a buffer overflow > > > vulnerability in the 'frm' command. Please have a look at: > > > > > > https://rhn.redhat.com/errata/RHSA-2004-009.html > > > > > > > If there are admins out there who have users using elm or users who are > > using it who would like fix up a package and submit I'm sure it would be > > just fine. Personally, I don't have any of those users and I don't have > > the sparetime to spend on applications I don't use. > > > > -sv > > > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonny.strom at netikka.fi Wed Jan 14 20:44:19 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 14 Jan 2004 22:44:19 +0200 Subject: Patch for elm. Message-ID: <4005AA23.6020502@netikka.fi> Hi All I just got this from the maintainer of elm. I will build RH 7.3 rpm's as next step. Cheers Johnny -------- Original Message -------- Subject: Re: Hello Date: Wed, 14 Jan 2004 14:49:06 -0500 (EST) From: wfp5p AT cthulhu.itc.Virginia.EDU (Bill Pemberton) To: jonny.strom AT netikka.fi (Johnny Strom) Johnny Strom writes: > > And Redhat had an uppdate for it: > https://rhn.redhat.com/errata/RHSA-2004-009.html > > > So my question is there some patch for this issue? > becouse I can't find any more information than this. > Ok, it's a real easy fix (here's the Red Hat fix): --- elm2.5.6_/utils/from.c.bfrovf 2004-01-08 11:28:44.000000000 +0100 +++ elm2.5.6_/utils/from.c 2004-01-08 11:30:55.000000000 +0100 @@ -464,7 +464,8 @@ fast_header_cmp(buffer,"Re", (char *)NULL)) { if (subject[0] == '\0') { remove_header_keyword(buffer); - strcpy(subject, buffer); + strncpy(subject, buffer, sizeof(subject)-1); + subject[sizeof(subject)-1] = '\0'; } } else if (fast_header_cmp(buffer,"From", (char *)NULL)) I'll probably release an elm 2.5.7 sometime in the near future that will include this fix. From jonny.strom at netikka.fi Wed Jan 14 21:36:53 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Wed, 14 Jan 2004 23:36:53 +0200 Subject: RPM's for elm. In-Reply-To: <4005AA23.6020502@netikka.fi> References: <4005AA23.6020502@netikka.fi> Message-ID: <4005B675.9090208@netikka.fi> Hi all Now I have patched, compiled elm rpm's and tested elm and it seems to be ok. I have made a small page where my fedora contributions can be downloaded from. Right now so can I only help out with RH 7.3 but later so can I also help out with RH 9. Here is the page: http://www.linuxvaasa.com/~johnny/fedora_legacy/rh73/ And btw if someone wants test out the latest Gnomemeeting versions so am I also doing rpms for the CVS version, they can be found here: http://www.linuxvaasa.com/~johnny/ Thanks! Johnny From warren at togami.com Wed Jan 14 21:38:38 2004 From: warren at togami.com (Warren Togami) Date: Wed, 14 Jan 2004 11:38:38 -1000 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> Message-ID: <4005B6DE.9000602@togami.com> Christian Pearce wrote: > Seth brings up an interesting issue. If we don't have people > interested in fixing a package, then it will still be vulnerable. > Should we keep track of this in bugzilla? Just create a bug and tag > it NOOWNER. Or something like that? This way we don't give people > the idea that everything is fixed security wise if you use > FedoraLegacy. > > Just a thought. > Please file the report with LEGACY keyword. Perhaps "NOPACKAGE" within the bug title until an actual package is posted at a later date. Warren From jjneely at pams.ncsu.edu Wed Jan 14 21:50:36 2004 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 14 Jan 2004 16:50:36 -0500 Subject: Website, and review of Warren's proposal In-Reply-To: <200312291432.17748.jkeating@j2solutions.net> References: <200312291432.17748.jkeating@j2solutions.net> Message-ID: <20040114215036.GF4545@anduril.pams.ncsu.edu> Looks like we have some down DNS servers? I can resolve fedoralegacy.org or www.fedoralegacy.org. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jkeating at j2solutions.net Wed Jan 14 22:05:14 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 14 Jan 2004 14:05:14 -0800 Subject: Website, and review of Warren's proposal In-Reply-To: <20040114215036.GF4545@anduril.pams.ncsu.edu> References: <200312291432.17748.jkeating@j2solutions.net> <20040114215036.GF4545@anduril.pams.ncsu.edu> Message-ID: <200401141405.18274.jkeating@j2solutions.net> On Wednesday 14 January 2004 13:50, Jack Neely wrote: > Looks like we have some down DNS servers? I can resolve > fedoralegacy.org or www.fedoralegacy.org. Both the primary and secondary DNS servers for that domain are up and responding.... -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From shugal at gmx.de Wed Jan 14 22:18:03 2004 From: shugal at gmx.de (Martin Stricker) Date: Wed, 14 Jan 2004 23:18:03 +0100 Subject: Website, and review of Warren's proposal References: <200312291432.17748.jkeating@j2solutions.net> <20040114215036.GF4545@anduril.pams.ncsu.edu> Message-ID: <4005C01B.F424C1D7@gmx.de> Jack Neely wrote: > > Looks like we have some down DNS servers? I can resolve > fedoralegacy.org or www.fedoralegacy.org. Works for me, resolves to 198.64.189.121. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Linux Migration Project: http://www.linux-migration.org/ Red Hat Linux 9 for low memory: http://www.rule-project.org/ Registered Linux user #210635: http://counter.li.org/ From jonny.strom at netikka.fi Thu Jan 15 00:27:10 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 15 Jan 2004 02:27:10 +0200 Subject: tcpdump vulnerabilities. Message-ID: <4005DE5E.6000301@netikka.fi> Hi again. There seems to be some tcpdump vulnerabilities: https://rhn.redhat.com/errata/RHSA-2004-007.html I will have a look at it tomorrow and see if I can make a patch and rpm's for RH73. Cheers Johnny From mind at bi.lt Thu Jan 15 05:46:35 2004 From: mind at bi.lt (Mindaugas Riauba) Date: Thu, 15 Jan 2004 07:46:35 +0200 Subject: Legacy RPMs Message-ID: <00c501c3db2a$f3239290$f20214ac@bite.lt> Hello, Maybe a bit stupid question but where to download updated RPMs for RedHat 7.3? In: http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/ it looks like there is only RedHat updates. I need only to download RPMs because for update I'm already using Current up2date server. Thanks, Mindaugas From skvidal at phy.duke.edu Thu Jan 15 06:44:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Jan 2004 01:44:48 -0500 Subject: RHSA-2004-006: kdepim released by Red Hat In-Reply-To: <1074098924.2998.49.camel@binkley> References: <59442.209.50.130.84.1074091123.commnav@home.commnav.com> <20040114164716.GA3353@codegrinder.com> <1074098924.2998.49.camel@binkley> Message-ID: <1074149088.8118.55.camel@binkley> On Wed, 2004-01-14 at 11:48, seth vidal wrote: > On Wed, 2004-01-14 at 11:47, Jason wrote: > > It doesn't look like RH7.x or RH8.0 would be affected. From > > http://www.kde.org/info/security/advisory-20040114-1.txt > > > > >1. Systems affected: > > > > > >All versions of kdepim as distributed with KDE versions 3.1.0 > > >through 3.1.4 inclusive. > > > > That said it might be worth someone's time to look at the patch linked > > in that doc and see if it applies to 3.0.x which is in RH7 and 8 > > > > I probably won't have time to dedicate to that today. > > I'm going to have to look at the patch anyway - I'll take a stab at it > later today or tonight. > > if anyone gets to it first let me know. The security notice from kde specifically cited versions from 3.1.0 to 3.1.4. I think 7.X and 8 are safe. I also checked the cve-mitre report, ditto. 3.1.0-3.1.4. -sv From skvidal at phy.duke.edu Thu Jan 15 06:47:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Jan 2004 01:47:01 -0500 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <20040114204250.GG3353@codegrinder.com> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> <20040114204250.GG3353@codegrinder.com> Message-ID: <1074149220.8118.57.camel@binkley> On Wed, 2004-01-14 at 15:42, Jason wrote: > That would probably be good.. we could use the NEEDSWORK tag which I > think already exists. And, I think there should certainly be the goal > to patch everything that needs it.. even if a few people end up as clean > up crew. Another idea I'd like to offer for consideration, what if I'd like to be added to every bug tagging 7.x for a security need? Is there a way in bugzilla to have that happen automatically? -sv From drees at greenhydrant.com Thu Jan 15 07:06:49 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 14 Jan 2004 23:06:49 -0800 Subject: Legacy RPMs In-Reply-To: <00c501c3db2a$f3239290$f20214ac@bite.lt> References: <00c501c3db2a$f3239290$f20214ac@bite.lt> Message-ID: <40063C09.9070009@greenhydrant.com> Mindaugas Riauba wrote, On 1/14/2004 9:46 PM: > > Maybe a bit stupid question but where to download updated > RPMs for RedHat 7.3? In: > http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/ > it looks like there is only RedHat updates. When Fedora Legacy RPMs get released, they will be moved to the directory you mention. > I need only to download RPMs because for update I'm already using > Current up2date server. Right now there haven't been any Legacy update releases, but if you sort the directory listing by date you will see the latest ones at the top. http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/?M=D -Dave From drees at greenhydrant.com Thu Jan 15 07:18:41 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 14 Jan 2004 23:18:41 -0800 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <1074149220.8118.57.camel@binkley> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> <20040114204250.GG3353@codegrinder.com> <1074149220.8118.57.camel@binkley> Message-ID: <40063ED1.2050704@greenhydrant.com> seth vidal wrote, On 1/14/2004 10:47 PM: > > Another idea I'd like to offer for consideration, > > what if I'd like to be added to every bug tagging 7.x for a security > need? Is there a way in bugzilla to have that happen automatically? From my knowledge of bugzilla, you can have a default owner of bugs, but there isn't a way to automatically CC you on new bugs. Your best bet is to save a query which lists legacy bugs for 7.x which you aren't already CC'd on and run it periodiclly. There might be a way to do it that I'm not aware of as the Jakarta-Tomcat guys have get an email update when any Tomcat bugs are updated sent to their dev list (http://nagoya.apache.org/bugzilla/) Maybe they've got some custom enhancements to their version of bugzilla. Or more likely, it could be because the default owner of each Tomcat component is the Tomcat dev list. -Dave From peter.peltonen at iki.fi Thu Jan 15 08:28:16 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 15 Jan 2004 10:28:16 +0200 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <40063ED1.2050704@greenhydrant.com> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> <20040114204250.GG3353@codegrinder.com> <1074149220.8118.57.camel@binkley> <40063ED1.2050704@greenhydrant.com> Message-ID: <40064F20.2070405@iki.fi> David Rees wrote: > There might be a way to do it that I'm not aware of as the > Jakarta-Tomcat guys have get an email update when any Tomcat bugs are > updated sent to their dev list (http://nagoya.apache.org/bugzilla/) > Maybe they've got some custom enhancements to their version of bugzilla. > Or more likely, it could be because the default owner of each Tomcat > component is the Tomcat dev list. I've seen this happen on blackbox-list too. IMHO It would be a useful feature to have new bugzilla entries be sent to the list. Regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From warren at togami.com Thu Jan 15 09:36:40 2004 From: warren at togami.com (Warren Togami) Date: Wed, 14 Jan 2004 23:36:40 -1000 Subject: Red Hat released new elm package for RHAS 2.1 In-Reply-To: <40064F20.2070405@iki.fi> References: <60076.209.50.130.84.1074112701.commnav@home.commnav.com> <20040114204250.GG3353@codegrinder.com> <1074149220.8118.57.camel@binkley> <40063ED1.2050704@greenhydrant.com> <40064F20.2070405@iki.fi> Message-ID: <40065F28.8070801@togami.com> Peter Peltonen wrote: > David Rees wrote: > >> There might be a way to do it that I'm not aware of as the >> Jakarta-Tomcat guys have get an email update when any Tomcat bugs are >> updated sent to their dev list (http://nagoya.apache.org/bugzilla/) >> Maybe they've got some custom enhancements to their version of >> bugzilla. Or more likely, it could be because the default owner of >> each Tomcat component is the Tomcat dev list. > > > I've seen this happen on blackbox-list too. IMHO It would be a useful > feature to have new bugzilla entries be sent to the list. I don't have time to setup anything like this. Also notifications may become annoying if they are to this list. Warren From cspencer at cait.org Thu Jan 15 14:56:57 2004 From: cspencer at cait.org (Chris Spencer) Date: Thu, 15 Jan 2004 08:56:57 -0600 Subject: Thoughts on legacy... Message-ID: <1074178617.14967.71.camel@chriss2.cait.org> I wanted to post some comments to this list from someone who is part of producing the full releases and legacy on them. Comments below. -Chris >When will people understand that a community project needs more than a >"one man gang" who just tries to push it forward? Warren Togami's problem >is, he can make a project look as if it is alive and happy when in fact it >is in serious lack of contributors. Well, at fedora.us, for instance, it >is not a problem if some 50+ packages for educational programming >languages [and other stuff with a very special target group] seem to stay >in the queue forever. But with Fedora Legacy, the project should have >tried to be ready 1-2 months ago already and know exactly how to get an >update published. E.g. the fedora.us build system is used and won't be >happy about missing build dependencies (Red Hat's build system is >different). Instead, much time has been spent on discussing poor press >releases or web site layout stuff. However, if you check the fedora legacy >list, a few people are trying to deal with the recent flood of security >issues. But the general tendency is, if no one shows interest in a >particular package and a bit of work on it, there won't be updates for >it. A recent suggestion has been to track such packages in bugzilla as >"unmaintained". > >As a side-note, there's also the risk that as soon as someone offers a fix >for a package at some place without submitting it as an official Fedora >Legacy update, subscribers of fedora-legacy-list might find that >satisfactory and no one might do the additional work of getting the >package approved and published. I think that this shows that producing and supporting a Linux distribution is not a simple project on its own for a small number of non-paid people. The OSs are pre-existing of course os that part is done. Many people I've seen in IRC and/or email lists mention that they would volunteer to work on a legacy support project for EOL releases, however I haven't personally seen very many people actually step forward to do real work, or contribute to the necessary infrastructural and organizational efforts that would be required in order for such a Fedora Legacy project to truely be successful. Unpaid volunteers are hard to come by. I cerainly wish any Fedora Legacy project, and its members much success in trying to support EOL products, but it is a huge undertaking, and will require not one or two, but a great number of dedicated volunteers putting in a large number of man hours of work to put together all of the infrastructure and organizational bits, and to do the work of backporting or creating fixes for legacy rpms and building and testing them on all platforms that the project wishes to support. It's not a small task any way you look at it. To get started, the organizational bits need to be in place first, and some mechanism for quality control needs to be developed and manned. Then people need to volunteer for specific packages, and be willing to also be assigned to do something. That's the only way I can see such a huge effort succeeding, and that's enough work right there just to support a single OS release alone, rather than all EOL products. Security bugs are the biggest problem, as they hit you when you least expect it, and have tonnes of existing work on your plate, be it job, school, other projects, etc. yet you need to drop what you're doing, and fix some possibly obscure complex security issue of which you may have a patch fed to you, or may need to debug and figure it out yourself, and make sure you're not breaking anything while you're trying to whip up the fixes quickly and get them tested (by someone else ALWAYS). So, it is a very huge project to undertake for anyone at all IMHO. Since it's all volunteer work, and all volunteer work has non-monetary motivators by definition, perhaps that is a good place to start looking to build the project. What are the motivations for someone to join and/or contribute? Come up with some realistic motivations, and post them to the site, and advertise getting involved. Get the infrastructure together, and have a leader who has the time to spare to be the leader. That's the best advice I can try to provide for now anyway. I'll do my part by keeping XFree86 4.3.0 building on RHL 8.0 and newer, and 4.1.0 building on 7.[12]. 4.2.x is free for grabs to anyone who wants it though. ;o) Take care, TTYL P.S. Feel free to forward between mailing lists if you think others may benefit from my words above to aide the Fedora Legacy project. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat "There is a lot of speculation and I guess there is going to continue to be a lot of speculation until the speculation ends." - George W. Bush on October 18, 1998 From jonny.strom at netikka.fi Thu Jan 15 15:14:43 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 15 Jan 2004 17:14:43 +0200 Subject: Rpm's for tcpdump. Message-ID: <4006AE63.6090600@netikka.fi> Hi all I have worked on the back port of the fixes for tcpdump on RH 7.3, It was not so easy. I had to skip "_U_" on the following lines 418 471 554 617 635 778 804 830 848 866 885 1017 1055 in the print-isakmp.c file in order to get it to compile. I don't know if this have any impact on the security you can compare with the original patch that is in RH 9 update, the patch name is: "tcpdump-3.7.2-CAN-2003-0989.patch". Perhaps someone knows this better than me, but anyway it should be much better now :) Anyway the rpms are ready and they seems to work ok, you can get them from here: http://av8.netikka.fi/~johnny/fedora_legacy/rh73/ Thanks! Johnny From vicreydj at hotmail.com Thu Jan 15 16:12:19 2004 From: vicreydj at hotmail.com (Victor DeJesus) Date: Thu, 15 Jan 2004 10:12:19 -0600 Subject: Kernel Adjusting Message-ID: When I tried to make a custom kernel based off the one provided with core 1, it won't load. I am still learning how to work with kernels so bare with me. I am trying to get acpi working on my compaq presario 700 laptop working. When loading the kernel it says kernel panic: No init found. Try passing init= option to kernel. What does this mean and can you help, please? Victor DeJesus _________________________________________________________________ Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From sean at resultsoverhead.com Thu Jan 15 16:49:50 2004 From: sean at resultsoverhead.com (Sean Kerner) Date: Thu, 15 Jan 2004 11:49:50 -0500 Subject: Media Inquiry - About the Red Hat Linux 7.x and 8.0 end of life notification mailed to RHN subscribers yesterday Message-ID: Hi, I'm a RedHat 7.3 user - and a freelance techjournalist. I'm writing a story today about the official EOL sent to RedHat Subscribers. Just curious for some comments from Fedora Legacy project members and community about this official EOL. Can anyone tell me how many RHN users were mailed this notice? How many have 'converted'/ migrated their RHN up2date client to Fedora Legacy? and btw, How does an existing 7.x/8 RHN user convert up2date to use Fedora Legacy? Is someone that is running 7.x/8 without Errata support safe today? Is Fedora Legacy 'ready' in this post EOL era? thnx for any and all replies! From m.stolte at datadevil.demon.nl Thu Jan 15 17:46:46 2004 From: m.stolte at datadevil.demon.nl (m.stolte at datadevil.demon.nl) Date: Thu, 15 Jan 2004 18:46:46 +0100 Subject: Media Inquiry - About the Red Hat Linux 7.x and 8.0 end of life notification mailed to RHN subscribers yesterday In-Reply-To: References: Message-ID: <1074188806.4006d206480a7@datadevil.demon.nl> Quoting Sean Kerner : > Hi, I'm a RedHat 7.3 user - and a freelance techjournalist. > I'm writing a story today about the official EOL sent to RedHat Subscribers. > Just curious for some comments from Fedora Legacy project members and > community about this official EOL. > > Can anyone tell me how many RHN users were mailed this notice? try asking Redhat? > How many have 'converted'/ migrated their RHN up2date client to Fedora > Legacy? think legacy doesn't support up2date from rhl7, since that doesnt support apt/yum repositories. > and btw, How does an existing 7.x/8 RHN user convert up2date to use Fedora > Legacy? ah. They could try the one from the fedora core i think, thats supposed to support yum, but it'd take a recompile to run on 7 due to gcc diffs. > Is someone that is running 7.x/8 without Errata support safe today? define safe.Most exploits i've seen involve local root exploits, which isnt too big a problem for alot of us, or are for services that the average user doesn't run. > Is Fedora Legacy 'ready' in this post EOL era? > imho it is still getting up to speed, no downloads available, no official anouncement yet. Maarten From m.stolte at datadevil.demon.nl Thu Jan 15 17:42:34 2004 From: m.stolte at datadevil.demon.nl (m.stolte at datadevil.demon.nl) Date: Thu, 15 Jan 2004 18:42:34 +0100 Subject: Kernel Adjusting In-Reply-To: References: Message-ID: <1074188554.4006d10ad1027@datadevil.demon.nl> Hi Victor, Quoting Victor DeJesus : > When I tried to make a custom kernel based off the one provided with core 1, > > it won't load. I am still learning how to work with kernels so bare with > me. I am trying to get acpi working on my compaq presario 700 laptop > working. When loading the kernel it says kernel panic: No init found. Try > passing init= option to kernel. What does this mean and can you help, > please? This list is for fedora-legacy, which is maintaining the older redhat releases, not the current fedora core 1. Try looking on fedora.redhat.com for information on that product. Maarten From warren at togami.com Thu Jan 15 18:11:45 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jan 2004 08:11:45 -1000 Subject: Media Inquiry - About the Red Hat Linux 7.x and 8.0 end of life notification mailed to RHN subscribers yesterday In-Reply-To: References: Message-ID: <4006D7E1.7010900@togami.com> Sean Kerner wrote: > Hi, I'm a RedHat 7.3 user - and a freelance techjournalist. > I'm writing a story today about the official EOL sent to RedHat Subscribers. > Just curious for some comments from Fedora Legacy project members and > community about this official EOL. First I would like to say that I am saddened by the sensationalism and especially feelings of "betrayal" that has been portrayed in the media over this EOL. Everyone is acting like this is a Big Surprise. The shorter 1 year EOL for RHL distributions was announced IIRC well over a year ago, and they even extended many of the 7.x distribution support long over 1 year to all end together at Dec. 31st 2003. This should not have come as a surprise to everyone. The company has even did a Nice Thing by releasing a final kernel errata for these distributions after their Dec. 31st deadline. They didn't have to do that. Beyond that point deadline, it has been our community's responsibility with this chance given by the Legacy project. > > Can anyone tell me how many RHN users were mailed this notice? > How many have 'converted'/ migrated their RHN up2date client to Fedora > Legacy? > and btw, How does an existing 7.x/8 RHN user convert up2date to use Fedora > Legacy? We have absolutely no way of knowing how many users are using Legacy repositories, because there are an unknown number of mirrors, and there is no feasible method of keeping statistics across all of these mirrors. > Is someone that is running 7.x/8 without Errata support safe today? No. > Is Fedora Legacy 'ready' in this post EOL era? > And no again, due to the lack of interested developers in the project, and the expectation of a "free lunch" by others who only idly sit back and wait for others to due the work for them. http://www.fedora.us/LEGACY A lot of potentially good work has been submitted a few dedicated individuals, but as of yet others have not followed through with the necessary work to finalize publication of several pending updates. As I have stated in the past few days, the packages and website documentation need a lot more dedicated work in order to make this project a feasible alternative. As I have stated, I personally gave a great deal of time to this project while I have no intention of actually using this software myself. I had felt that it is important that this project exist and become self-sufficient, but I had long over-extended my allotted time and I must personally move on. This is in the hands of the community, if they wish it to thrive. It is not too late, neither is it too difficult. Warren Togami From warren at togami.com Thu Jan 15 18:13:28 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jan 2004 08:13:28 -1000 Subject: Rpm's for tcpdump. In-Reply-To: <4006AE63.6090600@netikka.fi> References: <4006AE63.6090600@netikka.fi> Message-ID: <4006D848.6060709@togami.com> Johnny Strom wrote: > Hi all > > > I have worked on the back port of the fixes for tcpdump on RH 7.3, > It was not so easy. I had to skip "_U_" on the following lines > 418 471 554 617 635 778 804 830 848 866 885 1017 1055 in > the print-isakmp.c file in order to get it to compile. > > I don't know if this have any impact on the security you can compare > with the original patch that is in RH 9 update, the patch name is: > "tcpdump-3.7.2-CAN-2003-0989.patch". > > Perhaps someone knows this better than me, > but anyway it should be much better now :) > > Anyway the rpms are ready and they seems to work ok, > you can get them from here: > > http://av8.netikka.fi/~johnny/fedora_legacy/rh73/ > > Please make sure they are properly GPG signed and submitted like the other pending proposed updates: http://www.fedora.us/LEGACY The other participants in the project will tell you if the package is acceptable or not, and if not, what you should do it make it acceptable. Warren From warren at togami.com Thu Jan 15 18:25:44 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jan 2004 08:25:44 -1000 Subject: Thoughts on legacy... In-Reply-To: <1074178617.14967.71.camel@chriss2.cait.org> References: <1074178617.14967.71.camel@chriss2.cait.org> Message-ID: <4006DB28.80101@togami.com> Chris Spencer wrote: >>When will people understand that a community project needs more than a >>"one man gang" who just tries to push it forward? Warren Togami's > > problem > >>is, he can make a project look as if it is alive and happy when in fact > > it > >>is in serious lack of contributors. Well, at fedora.us, for instance, > > it > >>is not a problem if some 50+ packages for educational programming >>languages [and other stuff with a very special target group] seem to It is not clear to me who wrote this, but if somebody feels that I made it seem like this project was doing well, then they totally have not been paying attention. I have been expressing my displeasure quite vocally, to the point of threatening to kill the project a week ago to avoid giving false hope. Instead I stuck around and continued to advise the folks in the IRC channel despite my limited time and me near a point of burn-out due to lack of sleep. They made some progress, but what is necessary now is people asserting themselves and taking the necessary steps to complete publication of packages, and fixing the website & documentation so there is something of substance here. Otherwise, talk is cheap. I acted while I have no interest in actually using this project. >>in the queue forever. But with Fedora Legacy, the project should have >>tried to be ready 1-2 months ago already and know exactly how to get an "should have" is unhelpful. I had hoped that the so called "leaders" who had stepped forward many months ago at certain companies and Universities that supposedly depend on this software and its continuance would have taken the necessary initiative and prepare things. But sadly early in December this project had ABSOLUTELY NOTHING, and it appeared that nothing would be done. I then wrote the first draft of the launch plan and sent it to those who expressed wanting to be leaders. I had ZERO responses from these people. The rest you have seen on this list. Warren From brian.t.brunner at gai-tronics.com Thu Jan 15 18:30:41 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Thu, 15 Jan 2004 13:30:41 -0500 Subject: Media Inquiry - About the Red Hat Linux 7.x and 8.0 end of life notification mailed to RHN subscribe Message-ID: You'll miss replies from a number of people who upgraded to another distribution (e.g. debian). Others (self included) repond to the note as follows: Stay with shrike (RH9) and hope everything important can be patched on a per-package basis. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> sean at resultsoverhead.com 01/15/04 11:49AM >>> Hi, I'm a RedHat 7.3 user - and a freelance techjournalist. I'm writing a story today about the official EOL sent to RedHat Subscribers. Just curious for some comments from Fedora Legacy project members and community about this official EOL. Can anyone tell me how many RHN users were mailed this notice? How many have 'converted'/ migrated their RHN up2date client to Fedora Legacy? and btw, How does an existing 7.x/8 RHN user convert up2date to use Fedora Legacy? Is someone that is running 7.x/8 without Errata support safe today? Is Fedora Legacy 'ready' in this post EOL era? thnx for any and all replies! -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated ********************************************************************** From jkeating at j2solutions.net Thu Jan 15 18:42:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Jan 2004 10:42:06 -0800 Subject: Thoughts on legacy... In-Reply-To: <4006DB28.80101@togami.com> References: <1074178617.14967.71.camel@chriss2.cait.org> <4006DB28.80101@togami.com> Message-ID: <200401151042.11388.jkeating@j2solutions.net> On Thursday 15 January 2004 10:25, Warren Togami wrote: > "should have" is unhelpful. I had hoped that the so called "leaders" > who had stepped forward many months ago at certain companies and > Universities that supposedly depend on this software and its > continuance would have taken the necessary initiative and prepare > things. I suppose this is mostly directed at me. Yes, I was rather inactive the last couple months, and I have apologized for this before. I am here now, I am making progress, and hopefully tonight I'll be able to do the QA on the packages in bugzilla and push out some notices. Warren, if you don't have time to build the kernel for the build system, I'm going to move forward with just plain mach. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Thu Jan 15 19:02:45 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jan 2004 09:02:45 -1000 Subject: Thoughts on legacy... In-Reply-To: <200401151042.11388.jkeating@j2solutions.net> References: <1074178617.14967.71.camel@chriss2.cait.org> <4006DB28.80101@togami.com> <200401151042.11388.jkeating@j2solutions.net> Message-ID: <4006E3D5.10208@togami.com> Jesse Keating wrote: > On Thursday 15 January 2004 10:25, Warren Togami wrote: > >>"should have" is unhelpful. I had hoped that the so called "leaders" >>who had stepped forward many months ago at certain companies and >>Universities that supposedly depend on this software and its >>continuance would have taken the necessary initiative and prepare >>things. > > > I suppose this is mostly directed at me. Yes, I was rather inactive the > last couple months, and I have apologized for this before. I am here > now, I am making progress, and hopefully tonight I'll be able to do the > QA on the packages in bugzilla and push out some notices. Warren, if > you don't have time to build the kernel for the build system, I'm going > to move forward with just plain mach. > Please remind me in IRC during this weekend. I should have the time then. Warren From keb at ctinetworks.com Thu Jan 15 19:20:32 2004 From: keb at ctinetworks.com (Kevin Bonner) Date: Thu, 15 Jan 2004 14:20:32 -0500 Subject: Legacy RPMs In-Reply-To: <40063C09.9070009@greenhydrant.com> References: <00c501c3db2a$f3239290$f20214ac@bite.lt> <40063C09.9070009@greenhydrant.com> Message-ID: <200401151420.32798.keb@ctinetworks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 15 January 2004 02:06, David Rees wrote: > Mindaugas Riauba wrote, On 1/14/2004 9:46 PM: > > Maybe a bit stupid question but where to download updated > > RPMs for RedHat 7.3? In: > > http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/ > > it looks like there is only RedHat updates. > > When Fedora Legacy RPMs get released, they will be moved to the > directory you mention. Unless I am mistaken, you want to look in the RPMS.legacy directory. The files in RPMS.updates are RedHat released updates. > > I need only to download RPMs because for update I'm already using > > Current up2date server. > > Right now there haven't been any Legacy update releases, but if you sort > the directory listing by date you will see the latest ones at the top. > > http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/?M=D > > -Dave According to https://bugzilla.fedora.us/show_bug.cgi?id=1176, there is a legacy RPM already published. - - Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFABugA/9i/ml3OBYMRAk1fAJ4neJINUF66ozC4nh7uSlBL2SaLbgCfSgUk rZGxko3whwZP5aal8aSJMjY= =ohbl -----END PGP SIGNATURE----- From warren at togami.com Thu Jan 15 19:26:50 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jan 2004 09:26:50 -1000 Subject: Legacy RPMs In-Reply-To: <200401151420.32798.keb@ctinetworks.com> References: <00c501c3db2a$f3239290$f20214ac@bite.lt> <40063C09.9070009@greenhydrant.com> <200401151420.32798.keb@ctinetworks.com> Message-ID: <4006E97A.1070302@togami.com> Kevin Bonner wrote: > On Thursday 15 January 2004 02:06, David Rees wrote: > >>>Mindaugas Riauba wrote, On 1/14/2004 9:46 PM: >>> >>>>Maybe a bit stupid question but where to download updated >>>>RPMs for RedHat 7.3? In: >>>>http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/ >>>>it looks like there is only RedHat updates. >>> >>>When Fedora Legacy RPMs get released, they will be moved to the >>>directory you mention. > > > Unless I am mistaken, you want to look in the RPMS.legacy directory. The > files in RPMS.updates are RedHat released updates. > > >>>>I need only to download RPMs because for update I'm already using >>>>Current up2date server. >>> >>>Right now there haven't been any Legacy update releases, but if you sort >>>the directory listing by date you will see the latest ones at the top. >>> >>>http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.updates/?M=D >>> >>>-Dave > > > According to https://bugzilla.fedora.us/show_bug.cgi?id=1176, there is a > legacy RPM already published. > > - Kevin http://www.fedora.us/wiki/FedoraChannels This page has been linked from fedoralegacy.org for a while. We have also stated on this list several times the following: os packages from the original distribution updates updates from Red Hat + updates from FedoraLegacy updates-testing updates from FedoraLegacy currently in testing before publication legacy minimal support tools for Legacy servers Warren From rostetter at mail.utexas.edu Thu Jan 15 19:29:06 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 15 Jan 2004 13:29:06 -0600 Subject: Thoughts on legacy... In-Reply-To: <4006DB28.80101@togami.com> References: <1074178617.14967.71.camel@chriss2.cait.org> <4006DB28.80101@togami.com> Message-ID: <20040115132906.7qev44sswckcg0ow@mail.ph.utexas.edu> Quoting Warren Togami : > >>in the queue forever. But with Fedora Legacy, the project should have > >>tried to be ready 1-2 months ago already and know exactly how to get an > > "should have" is unhelpful. I had hoped that the so called "leaders" > who had stepped forward many months ago at certain companies and > Universities that supposedly depend on this software and its continuance > would have taken the necessary initiative and prepare things. Several of us non-leaders tried to step forward to help. We were told a line of gibberish about using such and such IRC, such and such wiki, etc. But I don't use IRC. I don't know what wiki is or how to use it. I was being asked to do stuff, without directions, that I didn't know how to do, and didn't know why I needed to do them. So nothing happened.... This happened on several projects I tried to get into. So, I did nothing but lurk... Sad. I could contribute, but am being blocked from doing so because no one will take the time to help me get up to speed on the infrastructure the aledged "leaders" want to impose on the community. > But sadly early in December this project had ABSOLUTELY NOTHING, and it > appeared that nothing would be done. I then wrote the first draft of > the launch plan and sent it to those who expressed wanting to be > leaders. I had ZERO responses from these people. The rest you have > seen on this list. More is coming. The project is *way* behind schedule. Hopefully it will survive. But it needs leadership. And the leadership needs to be helpful to newbies, or it will all land on the leadership's hands instead of being spread around the community. And if that happens, it will probably fail, and quickly. > Warren I for one noticed and appreciated everything Warren did. He is probably the main reason this project has not yet failed, or maybe I should say still has some remote chance of success. I'll be updateing the Fedora Legacy web site just as soon as I get a chance. Unfortunately lately I've been too busy dealing with issues of my wife's health (along with my work responsibilities) to help as much as I would like to. Strangely, it turned out in the end I could help with the web site without learning about IRC, wiki, and all that other new-aged stuff... -- Eric Rostetter From kelson at speed.net Thu Jan 15 19:31:54 2004 From: kelson at speed.net (Kelson Vibber) Date: Thu, 15 Jan 2004 11:31:54 -0800 Subject: Legacy RPMs In-Reply-To: <200401151420.32798.keb@ctinetworks.com> References: <00c501c3db2a$f3239290$f20214ac@bite.lt> <40063C09.9070009@greenhydrant.com> <200401151420.32798.keb@ctinetworks.com> Message-ID: <6.0.1.1.0.20040115113002.02690db0@mail.speed.net> At 11:20 AM 1/15/2004, Kevin Bonner wrote: > > When Fedora Legacy RPMs get released, they will be moved to the > > directory you mention. > >Unless I am mistaken, you want to look in the RPMS.legacy directory. The >files in RPMS.updates are RedHat released updates. Actually, I think they are supposed to go into RPMS.updates, and RPMS.legacy is for support packages needed to *use* Fedora Legacy - yum/apt-get, upgraded versions of RPM for RH8-9, etc. On the other hand, I could also be mistaken. Kelson Vibber SpeedGate Communications From keb at ctinetworks.com Thu Jan 15 19:34:52 2004 From: keb at ctinetworks.com (Kevin Bonner) Date: Thu, 15 Jan 2004 14:34:52 -0500 Subject: Legacy RPMs In-Reply-To: <4006E97A.1070302@togami.com> References: <00c501c3db2a$f3239290$f20214ac@bite.lt> <200401151420.32798.keb@ctinetworks.com> <4006E97A.1070302@togami.com> Message-ID: <200401151434.52829.keb@ctinetworks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > http://www.fedora.us/wiki/FedoraChannels > This page has been linked from fedoralegacy.org for a while. We have > also stated on this list several times the following: > > os > packages from the original distribution > > updates > updates from Red Hat + updates from FedoraLegacy > > updates-testing > updates from FedoraLegacy currently in testing before publication > > legacy > minimal support tools for Legacy servers > > Warren Bah! Thought I had all of that info stuffed into my head. My apologies. I'll go wade through the documentation once again. - - Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFAButc/9i/ml3OBYMRAvPEAJ46aJ/1grf8Lb2mUIu5c+A4xDlYwwCfatP2 OJ6SUBwnUKm5mJz+WtrZQ58= =uemb -----END PGP SIGNATURE----- From pearcec at commnav.com Thu Jan 15 20:07:48 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 15 Jan 2004 20:07:48 GMT Subject: Thoughts on legacy... Message-ID: <33514.209.50.130.84.1074197268.commnav@home.commnav.com> Eric Rostetter said: > Several of us non-leaders tried to step forward to help. We were told a line > of gibberish about using such and such IRC, such and such wiki, etc. But I > don't use IRC. I don't know what wiki is or how to use it. I was being > asked to do stuff, without directions, that I didn't know how to do, and > didn't know why I needed to do them. So nothing happened.... I didn't use IRC either, but the fact of the matter is I needed to use this in order to be helpful for the projects sake. I learned. I believe a good deal of projects get done this way. It is a virtual meeting room. When you are asked to do something, it is because something needs to get done. When there is lack of direction that means there is a lack of leadership and decisions need to be made. So make them. If some one voices there opinion differently let them do the work then. I think working on these projects doesn't mean having someone spell it out for you. If they did that they might as well do it themselves. I don't mean to sound critical on this, but I think this is just the way it goes. > This happened on several projects I tried to get into. So, I did nothing > but lurk... Sad. I could contribute, but am being blocked from doing so > because no one will take the time to help me get up to speed on the > infrastructure the aledged "leaders" want to impose on the community. Take the time to learn it yourself. Or jump on IRC and start asking questions. Everyone was very helpful in getting me up to speed. I have a lot of packaging experience and I am knowledgable in many things. But I wasn't use to all the GPG key signing, and wasn't familiar with all the fedora policy we adopted. So I just asked. Hashing out newbies on the list can be quite noisy. Getting up to speed is part of the process. I don't know who is "aledging" to be a leader, but there are certainly people among us doing work and making decisions, that puts them in a leadership role whether they wanted it or realzed it or not. I don't think anyone is imposing anything other than trying to solve the problem the best way they (we) know how. > I'll be updateing the Fedora Legacy web site just as soon as I get a chance. > Unfortunately lately I've been too busy dealing with issues of my wife's > health (along with my work responsibilities) to help as much as I would like > to. Strangely, it turned out in the end I could help with the web site > without learning about IRC, wiki, and all that other new-aged stuff... IRC is older than dirt. Wiki's are nothing new or difficult to understand. I am sorry this isn't easier for you, but I feel I was in the same position as you were and I was interested it working on this project. Therfore I spent time reading and learning so I could be come an active particpant. -- Christian Pearce http://www.commnav.com From pearcec at commnav.com Thu Jan 15 21:26:14 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 15 Jan 2004 21:26:14 GMT Subject: QAd screen Message-ID: <33697.209.50.130.84.1074201974.commnav@home.commnav.com> I QAs screen. Anyone want to QA the package? I can't QA the package I did for 8.0. Duh. https://bugzilla.fedora.us/show_bug.cgi?id=1187 -- Christian Pearce http://www.commnav.com From pearcec at commnav.com Thu Jan 15 21:36:13 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 15 Jan 2004 21:36:13 GMT Subject: Thoughts on legacy... Message-ID: <33718.209.50.130.84.1074202573.commnav@home.commnav.com> Sorry Eric. I was in a bit of a mood when I wrote this. I have been dealing with customers all day. I do think some of what I said still rings true. -- Christian Pearce http://www.commnav.com "Christian Pearce" said: > > Eric Rostetter said: > > > Several of us non-leaders tried to step forward to help. We were told a line > > of gibberish about using such and such IRC, such and such wiki, etc. But I > > don't use IRC. I don't know what wiki is or how to use it. I was being > > asked to do stuff, without directions, that I didn't know how to do, and > > didn't know why I needed to do them. So nothing happened.... > > I didn't use IRC either, but the fact of the matter is I needed to use this in order to be helpful for the projects sake. I learned. I believe a good deal of projects get done this way. It is a virtual meeting room. > > When you are asked to do something, it is because something needs to get done. When there is lack of direction that means there is a lack of leadership and decisions need to be made. So make them. If some one voices there opinion differently let them do the work then. I think working on these projects doesn't mean having someone spell it out for you. If they did that they might as well do it themselves. I don't mean to sound critical on this, but I think this is just the way it goes. > > > This happened on several projects I tried to get into. So, I did nothing > > but lurk... Sad. I could contribute, but am being blocked from doing so > > because no one will take the time to help me get up to speed on the > > infrastructure the aledged "leaders" want to impose on the community. > > Take the time to learn it yourself. Or jump on IRC and start asking questions. Everyone was very helpful in getting me up to speed. I have a lot of packaging experience and I am knowledgable in many things. But I wasn't use to all the GPG key signing, and wasn't familiar with all the fedora policy we adopted. So I just asked. Hashing out newbies on the list can be quite noisy. > > Getting up to speed is part of the process. I don't know who is "aledging" to be a leader, but there are certainly people among us doing work and making decisions, that puts them in a leadership role whether they wanted it or realzed it or not. I don't think anyone is imposing anything other than trying to solve the problem the best way they (we) know how. > > > I'll be updateing the Fedora Legacy web site just as soon as I get a chance. > > Unfortunately lately I've been too busy dealing with issues of my wife's > > health (along with my work responsibilities) to help as much as I would like > > to. Strangely, it turned out in the end I could help with the web site > > without learning about IRC, wiki, and all that other new-aged stuff... > > IRC is older than dirt. Wiki's are nothing new or difficult to understand. > > I am sorry this isn't easier for you, but I feel I was in the same position as you were and I was interested it working on this project. Therfore I spent time reading and learning so I could be come an active particpant. > > -- > Christian Pearce > http://www.commnav.com > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From dawson at fnal.gov Thu Jan 15 21:54:45 2004 From: dawson at fnal.gov (Troy Dawson) Date: Thu, 15 Jan 2004 15:54:45 -0600 Subject: Self-Introduction: Troy J. Dawson Message-ID: <40070C25.2010402@fnal.gov> 1. Troy Jonathon Dawson 2. USA, Batavia, Illinois 3. System Administrator 4. Fermilab (Fermi National Accelorator Lab) 5. Your goals in the Fedora Project * Which packages do you want to see published? I currently only plan on working with the Fedora Legacy project, and as such don't plan on publishing any new packages. I plan on helping with packages on RedHat 7.3 (and possibly 9) that have remote security exploits. * Do you want to do QA? Yes. I am very good at that. * Anything else special? Currently, no, I'm just an average legacy sys-admin wanting to help. 6. Historical qualifications * What other projects have you worked on in the past? Fermi Linux 6.1.x, 7.1.x, 7.3.x, 9.0.x Fermi Linux LTS 3.0.x * What computer languages and other skills do you know? General jack of all trades, but very very weak in perl. Favorite is bash and java, but I've debugged in most everything back to fortran. (never tried cobol) I rarely get a chance to just sit down and code, so I'm really a little rusty on that, but where I shine is debugging and minor tweeks. * Why should we trust you? <--- too blunt? Not to blunt, and a question needed to be asked. I have a past record of fixing problems for users at Fermilab and elsewhere. But I think more important is that if I induce, or let someone else induce, a problem into these legacy packages, my users will be all over me, not to mention my boss. 7. GPG KEYID and fingerprint pub 1024D/82FD17B2 2004-01-08 Troy Dawson (Spiky Hair Hawaiian Shirts) Key fingerprint = A797 7D69 ADB9 50C6 2C2F C2FF DA6A D008 82FD 17B2 sub 1024g/41C8A496 2004-01-08 -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From pearcec at commnav.com Thu Jan 15 22:03:45 2004 From: pearcec at commnav.com (Christian Pearce) Date: Thu, 15 Jan 2004 22:03:45 GMT Subject: RPM's for elm. Message-ID: <33855.209.50.130.84.1074204225.commnav@home.commnav.com> Hi Johnny, I know we talked about this on IRC, but I want others on the list to get some understanding from this email as well. I just looked elm isn't in 8.0. That helps. But it is in 7.2. There are virtually no changes from 7.2 to 7.3. As a result we try to merge them into one spec file as a result one src.rpm. I can do the qa and src rebuild for 7.2. We also need to name it properly. I am not a 100% certain of what we want to name it. But I think the idea is to make it something with the distribution in it. Someone on the list or in IRC should be able to help. The patch looks good, but we need to get a bugzilla bug opened. You need to sign a md5sum file and sign the message to go into the bug. Look at some of the open bugs in bugzilla. You can use ethereal as an example of what I did. You also need to do a self introduction. You also need to add a changelog. The message should example what you fixed and have a link to the upstream provider of the patch and anyother links that are helpful surrounding the patch. All this signing is in the interested of security and trust. The bugzilla bugs are to help use track everything. Thanks again for your help. I will be in the IRC channel tomorrow. -- Christian Pearce http://www.commnav.com Johnny Strom said: > > Hi all > > > Now I have patched, compiled elm rpm's and tested elm and it seems to be ok. > > I have made a small page where my fedora contributions can be downloaded > from. Right now so can I only help out with RH 7.3 but later so can I > also help out with RH 9. > > Here is the page: > > > http://www.linuxvaasa.com/~johnny/fedora_legacy/rh73/ > > > And btw if someone wants test out the latest > Gnomemeeting versions so am I also doing rpms for > the CVS version, they can be found here: > > http://www.linuxvaasa.com/~johnny/ > > > Thanks! > > > Johnny > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From skvidal at phy.duke.edu Thu Jan 15 23:45:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Jan 2004 18:45:47 -0500 Subject: Self-Introduction: Troy J. Dawson In-Reply-To: <40070C25.2010402@fnal.gov> References: <40070C25.2010402@fnal.gov> Message-ID: <1074210347.10709.8.camel@binkley> On Thu, 2004-01-15 at 16:54, Troy Dawson wrote: > 1. Troy Jonathon Dawson Hi Troy. :) > * Why should we trust you? <--- too blunt? > Not to blunt, and a question needed to be asked. > I have a past record of fixing problems for users at Fermilab and elsewhere. > But I think more important is that if I induce, or let someone else induce, > a problem into these legacy packages, my users will be all over me, not to > mention my boss. If it matters, I can vouch for him to the extent that he was quite helpful in feeling out ideas on the yum list a looooong time ago, now. I doubt he's changed into an evil madman since then. :) -sv From ms-nospam-0306 at arcor.de Fri Jan 16 00:00:11 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 16 Jan 2004 01:00:11 +0100 Subject: Thoughts on legacy... In-Reply-To: <20040115132906.7qev44sswckcg0ow@mail.ph.utexas.edu> References: <1074178617.14967.71.camel@chriss2.cait.org> <4006DB28.80101@togami.com> <20040115132906.7qev44sswckcg0ow@mail.ph.utexas.edu> Message-ID: <20040116010011.28ce76de.ms-nospam-0306@arcor.de> On Thu, 15 Jan 2004 13:29:06 -0600, Eric Rostetter wrote: > Several of us non-leaders tried to step forward to help. We were told a line > of gibberish about using such and such IRC, such and such wiki, etc. But I > don't use IRC. I don't know what wiki is or how to use it. I was being > asked to do stuff, without directions, that I didn't know how to do, and > didn't know why I needed to do them. So nothing happened.... > > This happened on several projects I tried to get into. So, I did nothing > but lurk... Sad. I could contribute, but am being blocked from doing so > because no one will take the time to help me get up to speed on the > infrastructure the aledged "leaders" want to impose on the community. Don't know about the other subscribers, but I may have missed any specific questions which I could have answered. Please try again. Post specific questions to the mailing-list. Feel free to reply off-list, too. We're here to help eachother and even build teams for some tasks. -- From drees at greenhydrant.com Fri Jan 16 00:25:18 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 15 Jan 2004 16:25:18 -0800 (PST) Subject: Self-Introduction: David Rees Message-ID: <2740.208.48.139.163.1074212718.squirrel@www.greenhydrant.com> I've posted a few times on the list, would like to help with the QA process when I can: 1. Full legal name: David Rees 2. Country/City: United States, California, San Diego 3. Profession: Developemnt Manager / Software Engineer 4. Company: eBet, Inc. 5. Goals: We've got a number of RedHat 7.3 machines still in service which can't be upgraded at this time. Until they are, I'd like to assist with the process of getting important security fixes QAd. 6. Qualifications: I'm primarily a Java programmer with a good deal of experience building web applications and systems which interface with legacy software. I do a bit of everything. I have some experience with C/C++ programming as well as the various scripting languages. I've been using Linux in one form or another since 1995, lately I've been using RedHat, FC1 or Debian. 7. GPG KEYID and fingerprint $ gpg --fingerprint 63AAB5FB pub 1024D/63AAB5FB 2004-01-15 David Rees Key fingerprint = 12DF E096 F248 E150 FBF8 5BA3 3538 CF79 63AA B5FB sub 2048g/6C990097 2004-01-15 From rostetter at mail.utexas.edu Fri Jan 16 02:30:19 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 15 Jan 2004 20:30:19 -0600 Subject: Thoughts on legacy... In-Reply-To: <33514.209.50.130.84.1074197268.commnav@home.commnav.com> References: <33514.209.50.130.84.1074197268.commnav@home.commnav.com> Message-ID: <20040115203019.pwzelw8scgs880kw@mail.ph.utexas.edu> Quoting Christian Pearce : > I didn't use IRC either, but the fact of the matter is I needed to use this > in order to be helpful for the projects sake. I learned. I believe a good > deal of projects get done this way. It is a virtual meeting room. Most of the projects I work on have an IRC channel. None *require* it though. So, I thought I'd put some time into the project from work. Work said okay. But maybe I work on IBM MVS/CMS, or OpenVMS, or some other operating system that doesn't have native IRC software. Maybe I don't have access to install such software on the machine. Maybe my firewall policy won't allow it. Maybe I'm just not hip to IRC. Maybe none of the folks who told me to get on IRC bothered to say which IRC server (or what ever) I needed to use. In any case, I'm screwed. But I do know web design. I do know html. I do know php and asp. I do know xml. I do know cvs. I have access to all these things. But because I don't/can't use IRC I can't help with the FL web page? But the fact is, I *could* use IRC. Not easily, not well, but I'm sure I could get something installed and learn to use it eventually. Same with wiki. But given my limited time, and the fact that the project is behind schedule, we had two options: 1) Wait several weeks or even months for me to learn how to do these things. 2) Just let me do a web page without using IRC (say, using e-mail for communication). Now, which is a better, or least faster and more productive, method? Which one works better when people are working in different time zones; e-mail or IRC? I'd guess e-mail. > there opinion differently let them do the work then. I think working on > these projects doesn't mean having someone spell it out for you. If they did > that they might as well do it themselves. I don't mean to sound critical on > this, but I think this is just the way it goes. I wasn't looking to have anything spelled out. I was looking for details as to what was needed and within what constraints. Okay, so we need a web site. I need some info. What web server will it be on, and on what OS? What resources are available to me (does it have asp or php, cvs, etc). That kind of thing. Can be done in just a couple of e-mails. The web site can be done in a day or two. No big deal. But not if I need to do this via IRC, then it becomes weeks or months of work on my part. > Take the time to learn it yourself. Or jump on IRC and start asking > questions. Everyone was very helpful in getting me up to speed. I have a So I jump on IRC to learn how to jump on IRC? > IRC is older than dirt. Wiki's are nothing new or difficult to understand. Yep. IRC is older than dirt. I've known about it since I was a kid. And I'm 40 now. But I've still never used it, and still don't know how to use it. Wiki may not be hard, but I can't figure it out. When I signed up, it said a new user doesn't need to specify a password. So I didn't. Now I have a non-password protected wiki account, that as far as I can tell anyone can use now to post info in my name. I've searched, but I can not find a way to set the password (after the account is created). And I just haven't had time to research it. Nor have I had time to learn IRC. Nor have I had time to get on IM which has been on my TODO list since December. Things take time, and when your life is busy, you don't always have time. But should that stop me from being able to help with the project? > I am sorry this isn't easier for you, but I feel I was in the same position > as you were and I was interested it working on this project. Therfore I > spent time reading and learning so I could be come an active particpant. Well, actually, I hope I am an active participant. I have participated in the mailing list. I did create the web pages. I updated them today. I've tested some of the RPM updates. But I sure could do more if people had any interest in making it easier for me to help. Now, I don't take any of this personally. In fact, I wasn't really complaining for myself. I was complaining because I thought it would help many others on the mailing list who want to help but are just plain lost in the tech-talk that is being thrown at them when they try to help. We have a lack of participation, and I think it is because we've raised artificial walls that are blocking people who want to help. > -- > Christian Pearce > http://www.commnav.com -- Eric Rostetter From cra at WPI.EDU Fri Jan 16 03:11:54 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 15 Jan 2004 22:11:54 -0500 Subject: Self-Introduction: Troy J. Dawson In-Reply-To: <40070C25.2010402@fnal.gov> References: <40070C25.2010402@fnal.gov> Message-ID: <20040116031154.GP18793@angus.ind.WPI.EDU> On Thu, Jan 15, 2004 at 03:54:45PM -0600, Troy Dawson wrote: > 7. GPG KEYID and fingerprint > > pub 1024D/82FD17B2 2004-01-08 Troy Dawson (Spiky Hair Hawaiian Shirts) > > Key fingerprint = A797 7D69 ADB9 50C6 2C2F C2FF DA6A D008 82FD 17B2 > sub 1024g/41C8A496 2004-01-08 Where is your public key at? I can't find it on pgp.mit.edu. From Freedom_Lover at pobox.com Fri Jan 16 03:37:34 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 15 Jan 2004 22:37:34 -0500 Subject: Self-Introduction: Todd Zullinger Message-ID: <20040116033734.GG1581@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Todd Zullinger 2. USA, Mechanicsburg (Pennsylvania) 3. Geek / Hobbyist / Occasional Consultant 4. I'm a freelance hermit with no company affiliation 5. Your goals in the Fedora Project * Which packages do you want to see published? I have some 7.3 servers that I'd like to keep up to date and if I'm going to put some effort into patching them I might as well help donate that back where I can. My interest is in seeing packages related to server usage updated for security issues that arise. * Do you want to do QA? Perhaps want is too strong a term. :) But I will because it's needed and the more folks that kick in a little time the easier the task will be for everyone. I need to re-read the Package Submission and QA Policies and probably ask some questions so I can be sure I'm doing what's needed to get packages published. * Anything else special? Not that I can think of, though watching the sun rise on an empty beach is nice. 6. Historical qualifications * What other projects have you worked on in the past? Not many really. I try to be helpful when I can on the mailman, mutt, and gnupg user lists and with local Linux and Perl user groups. * What computer languages and other skills do you know? I can do PHP and HTML. I'm decent at sysadmin stuff and have been building RPMS for my own systems for a few years. I'm familiar with CVS and patching source code. I can read C/C++ a little but would be hard pressed to actually write any of it from scratch. * Why should we trust you? <--- too blunt? You shouldn't, to be equally blunt. :) Trust is earned over time. If I can be helpful in QA'ing stuff and supplying packages then perhaps I'll gain that trust. 7. GPG KEYID and fingerprint pub 1024D/D654075A 1997-12-07 Todd Key fingerprint = 0A55 D9D6 055E E2B9 99E9 7817 BAFF B4F4 D654 075A uid Todd uid Todd uid Todd uid Todd (DMSI Work Address) uid [jpeg image of size 3296] sub 3072g/094F99BB 1997-12-07 - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Private property was the original source of freedom. It still is it's main bulwark. -- Walter Lippmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAB1x8uv+09NZUB1oRAk5cAKD5adEuRgxzum/AfetPn1v4GEhnyQCgszkF dZ9jX7bcgVv3NqsFSnexxmc= =w8Hy -----END PGP SIGNATURE----- From mail at jonaspasche.de Fri Jan 16 13:34:59 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 16 Jan 2004 14:34:59 +0100 Subject: Self-Introduction: Jonas Pasche Message-ID: <1074260099.3608.78.camel@leonardo> 1. Full legal name Jonas Pasche [1] 2. Country, City Germany, Darmstadt 3. Profession or Student status System administration 4. Company or School None; self-employed [2] 5. Your goals in the Fedora Project - Which packages do you want to see published? Security fixes - Do you want to do QA? No, as I don't really know what to do to "do QA". My primary goal is writing documentation (see next point), and I think it's better to focus on one thing and do it right than doing too much things at once and produce nothing helpful. Additionally, there seem to be quite a handful of people that already could do QA. - Anything else special? Yes, I want to gather, summarize and write new documentation for fedoralegacy.org, as the docs section on that site is completely empty. I guess that with 7.3/8.0/9 EOL many people will get to know Fedora Legacy, and most of them wouldn't have heard of Fedora, apt or yum before and "just want to use it" without a high learning curve. I'm good at clarifying and summarizing things to make them more usable the end user. However, I'm not a native speaker - I'll do my best to write clean English, but it would be preferred if somebody could look over what I write to check for correct grammar and style. Historical qualifications - What other projects have you worked on in the past? I have long worked in tech support at an ISP, where I have been also developing web interfaces for different types of applications, mainly a DNS management software. Unfortunately it isn't free software because of my work contract, but at least there are still some screenshots at [3]. In 2001 I have completed my RHCE exam on RHL 7.0 [4]. I have held quite some courses; topics varying from website development through common Red Hat Linux installation and usage to DNS and mail server management, and people revisited me in other courses, so I think I don't have been too bad. ;-) I've been a contributor to the qmail and vchkpw mailing lists. You can check my posting history at the MARC list archives [5] as well as having a look on my patches for tools of the qmail world [6]. I'm currently supporting the German DynDNS provider www.selfhost.de with conceptual and technical help and have written the Linux Updater Software for that service. - What computer languages and other skills do you know? Languages: bash, Perl Other skills: Good knowledge of system administration in general, well-experienced with Red Hat Linux since 6.2 - Why should we trust you? <--- too blunt? As I'm not going to create/sign/publish RPMs that might damage people's computers, risk is low - simply judge from what and how I'm going to write. GPG KEYID and fingerprint [jonas at leonardo jonas]$ gpg --fingerprint 1F6AB94E pub 1024D/1F6AB94E 2003-03-17 Jonas Pasche Key fingerprint = 5FA7 12F9 4161 D71F D5FA AD6B BB03 78B3 1F6A B94E uid Jonas Pasche uid Jonas Pasche sub 2048g/99F05557 2003-03-17 [expires: 2004-03-16] [1] http://jonaspasche.de/index.shtml [2] http://jonaspasche.com/ (German only) [3] http://www.domke.de/produkte/dns.html (German only) [4] https://www.redhat.com/training/certification/verify/ then enter "807001935302935" [5] http://marc.theaimsgroup.com/?s=Jonas+Pasche&q=a [6] http://jonaspasche.de/qmail/ -------------- 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 jonny.strom at netikka.fi Fri Jan 16 13:45:41 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Fri, 16 Jan 2004 15:45:41 +0200 Subject: Self-Introduction Johnny Strom Message-ID: <4007EB05.3060601@netikka.fi> Full legal name: Johnny Torvald Strom Country, City: Finland, Vaasa Profession or Student status: Open source consulting. Company or School: Linux Solutions Vaasa. Your goals in the Fedora Project Which packages do you want to see published? Security uppdates for old Redhat software. Do you want to do QA? Yes, I can work on RH 7.3 packages now and I have more computers running on RH 9 that I can do backporting work on and testing later. Anything else special? Not at the moment. Historical qualifications What other projects have you worked on in the past? I try to help out on projects that I find intresting or that I have some use for, like the Gnomemeeting project. What computer languages and other skills do you know? Have been doing software development mostly in C and also in Fortran, know bash shell scripting quite well and have done quite a lot of rpms moslty for my own use. Why should we trust you? <--- too blunt? I don't know about this but I think fedora legacy needs some help and I will try to help out where I can like backporting, I already did elm and tcpdump. GPG KEYID and fingerprint This I will fix later today I hope. From jonny.strom at netikka.fi Fri Jan 16 14:22:44 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Fri, 16 Jan 2004 16:22:44 +0200 Subject: Self-Introduction Johnny Strom In-Reply-To: <4007EB05.3060601@netikka.fi> References: <4007EB05.3060601@netikka.fi> Message-ID: <4007F3B4.3080106@netikka.fi> The missing key: GPG KEYID and fingerprint pub 1024D/DA658D34 2004-01-16 Johnny Strom jonny.strom at netikka.fi Key fingerprint = 008E D226 4D18 EB97 048D 1D45 38EB 0967 DA65 8D34 sub 1024g/7C53E3FF 2004-01-16 From dawson at fnal.gov Fri Jan 16 14:34:41 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 16 Jan 2004 08:34:41 -0600 Subject: Self-Introduction: Troy J. Dawson In-Reply-To: <20040116031154.GP18793@angus.ind.WPI.EDU> References: <40070C25.2010402@fnal.gov> <20040116031154.GP18793@angus.ind.WPI.EDU> Message-ID: <4007F681.9020807@fnal.gov> Charles R. Anderson wrote: > On Thu, Jan 15, 2004 at 03:54:45PM -0600, Troy Dawson wrote: > >>7. GPG KEYID and fingerprint >> >>pub 1024D/82FD17B2 2004-01-08 Troy Dawson (Spiky Hair Hawaiian Shirts) >> >> Key fingerprint = A797 7D69 ADB9 50C6 2C2F C2FF DA6A D008 82FD 17B2 >>sub 1024g/41C8A496 2004-01-08 > > > Where is your public key at? I can't find it on pgp.mit.edu. > > Sorry about that. I'm still new to the gpg signing thing. I did an actual cut and paste from the wiki and it had --send-key KEYID I've done it again with my real key-id, and this time got a success message. Since I'm new to the gpg stuff, I've had a co-worker who is quite expert at it making sure I've created one correctly, keep it secure, etc... Obviously though, he isn't always watching over my shoulder. Actually, figuring out the gpg stuff was one of the two reason's it's taken me so long to get started here. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From dawson at fnal.gov Fri Jan 16 14:40:13 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 16 Jan 2004 08:40:13 -0600 Subject: Self-Introduction: Troy J. Dawson In-Reply-To: <1074210347.10709.8.camel@binkley> References: <40070C25.2010402@fnal.gov> <1074210347.10709.8.camel@binkley> Message-ID: <4007F7CD.3070701@fnal.gov> seth vidal wrote: > On Thu, 2004-01-15 at 16:54, Troy Dawson wrote: > >>1. Troy Jonathon Dawson > > Hi Troy. :) > > >> * Why should we trust you? <--- too blunt? >> Not to blunt, and a question needed to be asked. >> I have a past record of fixing problems for users at Fermilab and elsewhere. >> But I think more important is that if I induce, or let someone else induce, >>a problem into these legacy packages, my users will be all over me, not to >>mention my boss. > > > If it matters, I can vouch for him to the extent that he was quite > helpful in feeling out ideas on the yum list a looooong time ago, now. I > doubt he's changed into an evil madman since then. :) > > > -sv > Thanks Seth, I still keep one eye on yum, but after it got to the point where it was stable and had all the features we wanted, I've had to devote more time to other projects. Wow ... has it really been that loooong ago :) You'll be happy to know that we are now signing our rpm's here :), though I'm still glad that yum has the option to not force the rpm's to be signed. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From pearcec at commnav.com Fri Jan 16 14:58:31 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 14:58:31 GMT Subject: Self-Introduction: Jonas Pasche Message-ID: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> Welcome Jonas we are in need of documentation. I have been trying to write down faq's. And review the site. I am not certain who you need to coordinate with to get setup for updating the site. Talke with Jesse, and Eric Rostetter. We need to get some guidelines (read docs) together for Publishing a package. Everyone seems to take the same approach. Just do it, then we spend time in the channel being told to do XYZ with gpg and bugzilla. Start with taking what Fedora has for publishing guidelines. I don't know if it will be hard for you to do this if you never tried to publish a package. If you start with something we can refine it as we go. This goes for the QA docs too. The other thing we need is QA process well documented. This seems to be the other thing people get wrong off the bat. QA is more about verifying that people aren't putting in trojans. I believe testing is more of a process after the package is published into RPMS.testing. This way testers don't get screwed. While we still don't have a clear policy for verifiying something is secure, I believe we have adopted some of what Fedora has done in the past. If you can start there and extrapolate what we have started to talk about on the list in the past two weeks on the topic. But then again you don't need to listen to a word I say. This is just a start of where I think we are the weakest. BTW: I would be more that happy to read and review your work. There is another individual who emailed me off the list Bill who was also interested in helping review anything I wrote, Bill send an email to Jonas and get hooked up with him. Maybe you two can partner up together. I have to admit I will try to take on more tha I can do. But I fit more into the Policy, QA, Packaging department. Cheers, Christian -- Christian Pearce http://www.commnav.com Jonas Pasche said: > > 1. Full legal name > > Jonas Pasche [1] > > 2. Country, City > > Germany, Darmstadt > > 3. Profession or Student status > > System administration > > 4. Company or School > > None; self-employed [2] > > 5. Your goals in the Fedora Project > > - Which packages do you want to see published? > > Security fixes > > - Do you want to do QA? > > No, as I don't really know what to do to "do QA". My primary goal > is writing documentation (see next point), and I think it's better > to focus on one thing and do it right than doing too much things at > once and produce nothing helpful. Additionally, there seem to be > quite a handful of people that already could do QA. > > - Anything else special? > > Yes, I want to gather, summarize and write new documentation > for fedoralegacy.org, as the docs section on that site is > completely empty. I guess that with 7.3/8.0/9 EOL many people > will get to know Fedora Legacy, and most of them wouldn't have > heard of Fedora, apt or yum before and "just want to use it" > without a high learning curve. I'm good at clarifying and > summarizing things to make them more usable the end user. > However, I'm not a native speaker - I'll do my best to write > clean English, but it would be preferred if somebody could > look over what I write to check for correct grammar and style. > > Historical qualifications > > - What other projects have you worked on in the past? > > I have long worked in tech support at an ISP, where I have been > also developing web interfaces for different types of applications, > mainly a DNS management software. Unfortunately it isn't free > software because of my work contract, but at least there are still > some screenshots at [3]. > > In 2001 I have completed my RHCE exam on RHL 7.0 [4]. > > I have held quite some courses; topics varying from website > development through common Red Hat Linux installation and usage > to DNS and mail server management, and people revisited me in > other courses, so I think I don't have been too bad. ;-) > > I've been a contributor to the qmail and vchkpw mailing lists. You > can check my posting history at the MARC list archives [5] as well > as having a look on my patches for tools of the qmail world [6]. > > I'm currently supporting the German DynDNS provider www.selfhost.de > with conceptual and technical help and have written the Linux > Updater Software for that service. > > - What computer languages and other skills do you know? > > Languages: bash, Perl > > Other skills: Good knowledge of system administration in general, > well-experienced with Red Hat Linux since 6.2 > > - Why should we trust you? <--- too blunt? > > As I'm not going to create/sign/publish RPMs that might damage > people's computers, risk is low - simply judge from what and how > I'm going to write. > > GPG KEYID and fingerprint > > [jonas at leonardo jonas]$ gpg --fingerprint 1F6AB94E > pub 1024D/1F6AB94E 2003-03-17 Jonas Pasche > Key fingerprint = 5FA7 12F9 4161 D71F D5FA AD6B BB03 78B3 1F6A > B94E > uid Jonas Pasche > uid Jonas Pasche > sub 2048g/99F05557 2003-03-17 [expires: 2004-03-16] > > > [1] http://jonaspasche.de/index.shtml > [2] http://jonaspasche.com/ (German only) > [3] http://www.domke.de/produkte/dns.html (German only) > [4] https://www.redhat.com/training/certification/verify/ > then enter "807001935302935" > [5] http://marc.theaimsgroup.com/?s=Jonas+Pasche&q=a > [6] http://jonaspasche.de/qmail/ > From pearcec at commnav.com Fri Jan 16 15:05:07 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 15:05:07 GMT Subject: tcpdump and elm questions. Message-ID: <34405.209.50.130.84.1074265507.commnav@home.commnav.com> tcpdump: The specs are exactly the same except for the release has a different distro version. Is this what is meant by Fedora Legact Policy for combining src.rpm's into one spec? Is this what we are going to do for Fedora Legacy? Or are we literally going to have one package with one release? And drop the distro version from the release. This spec also has the epoch value of 14. What are the implications of epoch? elm: What ever decision that is made for tcpdump should be applied to elm as well. We have the same version of the code, 7.3 is one release newer and the changelog said it was a rebuild. All, We need some concensus on this issue, I believe these packages will shape policy. If no one speaks up I am going to recommend and work with Johnny on creating three src rpms for tcpdump with .spec virtually the same. Increasing the last number on the release and adding legacy. Leaving the epoch value the same. (I don't know what to do there) I will recommend we have two specs for 7.2 and 7.3 of elm as well, but using the same version of the .spec similiar to what Red Hat has done in the past with tcpdump. I am still working on verifying the tcpdump patch. I wonder if progeny released anything for tcpdump yet. I was told they did cvs and ethereal. -- Christian Pearce http://www.commnav.com From jkeating at j2solutions.net Fri Jan 16 15:58:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 07:58:58 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <1074260099.3608.78.camel@leonardo> References: <1074260099.3608.78.camel@leonardo> Message-ID: <200401160758.59891.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 January 2004 05:34, Jonas Pasche wrote: > - Anything else special? > > Yes, I want to gather, summarize and write new documentation > for fedoralegacy.org, as the docs section on that site is > completely empty. I guess that with 7.3/8.0/9 EOL many people > will get to know Fedora Legacy, and most of them wouldn't have > heard of Fedora, apt or yum before and "just want to use it" > without a high learning curve. I'm good at clarifying and > summarizing things to make them more usable the end user. > However, I'm not a native speaker - I'll do my best to write > clean English, but it would be preferred if somebody could > look over what I write to check for correct grammar and style. YAY! This is totally awesome! One thing that almost every project suffers from is lack of documentation. The fact that you want to do our documentation makes me all warm and fuzzy in side (; Please let me know what you'll need to get started! - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACApC4v2HLvE71NURAueFAJ9ZVUXjh17xdnsLVoEcdSob0VotlQCgpCTb 8/WUG96dTM21Co+ggLKDtgY= =VLsl -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jan 16 16:08:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 08:08:17 -0800 Subject: tcpdump and elm questions. In-Reply-To: <34405.209.50.130.84.1074265507.commnav@home.commnav.com> References: <34405.209.50.130.84.1074265507.commnav@home.commnav.com> Message-ID: <200401160808.19241.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 January 2004 07:05, Christian Pearce wrote: > tcpdump: > > The specs are exactly the same except for the release has a different > distro version. Is this what is meant by Fedora Legact Policy for > combining src.rpm's into one spec? Is this what we are going to do for > Fedora Legacy? Or are we literally going to have one package with one > release? And drop the distro version from the release. As long as the tarball included in the srpm is exactly the same, and the only spec difference is the version number, then what you should do is set the disttag to be 7x. You'll still have to build it specifically on 7.1, 7.2, and 7.3, it'll just have the same name. > This spec also has the epoch value of 14. What are the implications of > epoch? epoch always wins in a version comparison. Package-4.2 with epoch 14 is considered newer than Package-8.1 with epoch 13. For this reason, I do believe you should set the epoch of the newer distro up by one. Correct me if I'm wrong, but this will ensure that the package gets updated if somebody upgrades from 7.2 to 7.3. Otherwise, since they have the same name, the package wouldn't get upgraded. I don't particularly like epoch, but since it's already in use here, might as well take advantage of it. > elm: > > What ever decision that is made for tcpdump should be applied to elm as > well. We have the same version of the code, 7.3 is one release newer > and the changelog said it was a rebuild. Then do the same as above. > I am still working on verifying the tcpdump patch. I wonder if progeny > released anything for tcpdump yet. I was told they did cvs and > ethereal. A friend of mine that has signed up for the progeny service (boss's decision, not his), but he's added me to an alias that gets the notices. I'll be getting notices of all the updates that progeny makes available. I'll let the list know. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACAxx4v2HLvE71NURAoWAAJsEeepMJAws14EF4EfVyZukBu/TWwCgv94U czIohnfnu3hag496/xxW53g= =v4bq -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jan 16 16:19:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 08:19:16 -0800 Subject: tcpdump and elm questions. In-Reply-To: <200401160808.19241.jkeating@j2solutions.net> References: <34405.209.50.130.84.1074265507.commnav@home.commnav.com> <200401160808.19241.jkeating@j2solutions.net> Message-ID: <200401160819.17201.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 January 2004 08:08, Jesse Keating wrote: > epoch always wins in a version comparison. Package-4.2 with epoch 14 is > considered newer than Package-8.1 with epoch 13. For this reason, I do > believe you should set the epoch of the newer distro up by one. Correct > me if I'm wrong, but this will ensure that the package gets updated if > somebody upgrades from 7.2 to 7.3. Otherwise, since they have the same > name, the package wouldn't get upgraded. I don't particularly like > epoch, but since it's already in use here, might as well take advantage > of it. Ok, some folks have thwacked me upside the head with a big foam clue bat. Leave epoch alone. Just bump the build number to indicate a newer package. Take the existing largest build number for the package, and bump it by one for 7.1, by 2 for 7.2, by 3 for 7.3, etc.. Does this make sense? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACA8E4v2HLvE71NURAsd2AKCKWrLizAfuSeg1RF5IcUjwkyYcZACgsQC2 uayFw/zomx9zzyGC+P8OSWg= =mU+r -----END PGP SIGNATURE----- From jonny.strom at netikka.fi Fri Jan 16 16:25:05 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Fri, 16 Jan 2004 18:25:05 +0200 Subject: tcpdump and elm questions. In-Reply-To: <200401160819.17201.jkeating@j2solutions.net> References: <34405.209.50.130.84.1074265507.commnav@home.commnav.com> <200401160808.19241.jkeating@j2solutions.net> <200401160819.17201.jkeating@j2solutions.net> Message-ID: <40081061.5060104@netikka.fi> Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 16 January 2004 08:08, Jesse Keating wrote: > >>epoch always wins in a version comparison. Package-4.2 with epoch 14 is >>considered newer than Package-8.1 with epoch 13. For this reason, I do >>believe you should set the epoch of the newer distro up by one. Correct >>me if I'm wrong, but this will ensure that the package gets updated if >>somebody upgrades from 7.2 to 7.3. Otherwise, since they have the same >>name, the package wouldn't get upgraded. I don't particularly like >>epoch, but since it's already in use here, might as well take advantage >>of it. > > > Ok, some folks have thwacked me upside the head with a big foam clue bat. > Leave epoch alone. Just bump the build number to indicate a newer > package. Take the existing largest build number for the package, and bump > it by one for 7.1, by 2 for 7.2, by 3 for 7.3, etc.. > > Does this make sense? Yes it seems fine. > > - -- > Jesse Keating RHCE MCSE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFACA8E4v2HLvE71NURAsd2AKCKWrLizAfuSeg1RF5IcUjwkyYcZACgsQC2 > uayFw/zomx9zzyGC+P8OSWg= > =mU+r > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From mail at jonaspasche.de Fri Jan 16 16:41:28 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 16 Jan 2004 17:41:28 +0100 Subject: Getting started with documentation In-Reply-To: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> Message-ID: <1074271288.3608.214.camel@leonardo> Hi again, and thanks Christian and Jesse for the warm welcome! > I am not certain who you need to coordinate with to get setup for > updating the site. Talke with Jesse, and Eric Rostetter. Okay, so let's start collecting information: - Who has write access to the site / whom should I send new content? - Who wants to help writing? - Who wants to review content before publishing? Or would it be better to pre-publish content on my own site first and let it be reviewed by any list members who are willing to? From my point of view the process is more straightforward if there is only a small group who manages it, to avoid what I call the "wiki effect": A couple of pages, some very very detailed, some still to be written, some pages that are more a bookmark collection than written content, and everything in different writing styles and quality. - To the webmaster: In what file format is new content expected - plain text? HTML? Or are these pages generated through some kind of CMS? Regarding the content itself - from my point of view we need two parts of documentation as a start: 1) End users: What is Fedora Legacy? What can I do to keep my system up to date? Where can I find security advisories? ... I think I can prepare this part well, because I know most things about it. 2) Developers: How can I participate? ... This part would be harder for me, because I'm not a developer. Besides that, package submission and QA mainly works as with regular Fedora extra packages (I think so?!), which are documented on the Wiki, however, in a very short form. For legacy packages, the process should be easier, because some parts (e.g. writing completely new %pre[un] and %post[un] scripts, package name choosing, desktop entry choosing) are simply not needed for legacy packages. Anyway, I need assistance with this part from somebody who knows this process very well to tell me what is needed and what isn't. A word about participation in general: There is a short list on fedoralegacy.org what can be done, but few information how the make the first steps to actually start helping. In turn, there are quite a couple of self introductions on the list, so there are people to do work, but nothing has yet effectively led to officially published packages, so obviously people are missing directions on what to do and how to it - or am I missing another reason? Based on this, we should also work on the "Participate" section, telling a bit more than "We need every helping hand we can get" - maybe more in the style of "We need somebody who regularly checks the Bugzilla LEGACY queue, downloads packages and test if they build and install cleanly, then giving feedback on Bugzilla. We need somebody who watches the Red Hat Announcement list for updates that are important for Fedora Legacy, does a quick analysis of the update and informs the people on what is to be done", and so on. Meaning, more a kind of a job description, to allow interested people to judge what they can to and what they can't. For example, maybe I'd be technically able to "do QA" and simply don't know it, because I don't know what exactly "doing QA" means, being confused by 25 steps in 7 sections, just to mention the PackageSubmissionQAPolicy document - and I'm sure I only have to do a few of them, regarding legacy packages. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pearcec at commnav.com Fri Jan 16 16:55:38 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 16:55:38 GMT Subject: tcpdump and elm questions. Message-ID: <34570.209.50.130.84.1074272138.commnav@home.commnav.com> Johnny Strom said: > > Jesse Keating wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Friday 16 January 2004 08:08, Jesse Keating wrote: > > > >>epoch always wins in a version comparison. Package-4.2 with epoch 14 is > >>considered newer than Package-8.1 with epoch 13. For this reason, I do > >>believe you should set the epoch of the newer distro up by one. Correct > >>me if I'm wrong, but this will ensure that the package gets updated if > >>somebody upgrades from 7.2 to 7.3. Otherwise, since they have the same > >>name, the package wouldn't get upgraded. I don't particularly like > >>epoch, but since it's already in use here, might as well take advantage > >>of it. > > > > > > Ok, some folks have thwacked me upside the head with a big foam clue bat. > > Leave epoch alone. Just bump the build number to indicate a newer > > package. Take the existing largest build number for the package, and bump > > it by one for 7.1, by 2 for 7.2, by 3 for 7.3, etc.. > > > > Does this make sense? > > > Yes it seems fine. I guess it isn't for me. I want to try and clarify. In all cases leave epoch alone. We use the same spec file but the _revisions_ are different. elm: dist|orig|legacy 7.2 elm-2.5.6-1 -> elm-2.5.6.3.legacy 7.3 elm-2.5.6-2 -> elm-2.5.6.3.legacy tcpdump: 7.2 tcpdump-3.6.3-17.7.2.3 -> tcpdump-3.6.3-17.7.2.4.legacy 7.3 tcpdump-3.6.3-17.7.3.3 -> tcpdump-3.6.3-17.7.3.4.legacy 8.0 tcpdump-3.6.3-17.8.0.3 -> tcpdump-3.6.3-17.8.0.4.legacy Is this correct? From rostetter at mail.utexas.edu Fri Jan 16 17:16:44 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Jan 2004 11:16:44 -0600 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> Message-ID: <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> Quoting Christian Pearce : > Welcome Jonas we are in need of documentation. Yes! > I have been trying to write > down faq's. Here is my list of FAQ's, but without good answers. If anyone can supply answers, I'll get them on the web site asap. * What is the errata policy for The Fedora Legacy Project? * What version of RHL/FC are supported? * What architectures are supported? * How do I update packages? * How do I get notifications about new updates when they become available? * Where can I get more info on apt/yum? > And review the site. I am not certain who you need to > coordinate with to get setup for updating the site. Talke with Jesse, and > Eric Rostetter. Jesse if you want direct access to the web site CVS. Otherwise you can send submissions to me directly and I'll put them in CVS. The site was just updated this morning, so check it out again if you haven't. > We need to get some guidelines (read docs) together for Publishing a package. Yes! > Everyone seems to take the same approach. Just do it, then we spend time in > the channel being told to do XYZ with gpg and bugzilla. Start with taking > what Fedora has for publishing guidelines. I don't know if it will be hard > for you to do this if you never tried to publish a package. If you start > with something we can refine it as we go. This goes for the QA docs too. If no one else does, I'll try to "steal" the fedora pages and add them to our web site. We can refine from there. I should be able to get to this later today if no one else does. > The other thing we need is QA process well documented. This seems to be the > other thing people get wrong off the bat. QA is more about verifying that > people aren't putting in trojans. I believe testing is more of a process > after the package is published into RPMS.testing. This way testers don't get > screwed. While we still don't have a clear policy for verifiying something > is secure, I believe we have adopted some of what Fedora has done in the > past. If you can start there and extrapolate what we have started to talk > about on the list in the past two weeks on the topic. Interesting. Best summary of this I've seen yet. Anyone interested in posting the IRC logs on the web? Might be interesting for those of us who don't IRC to be able to browse the logs... > Cheers, > Christian -- Eric Rostetter From jkeating at j2solutions.net Fri Jan 16 17:19:25 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 09:19:25 -0800 Subject: Getting started with documentation In-Reply-To: <1074271288.3608.214.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <1074271288.3608.214.camel@leonardo> Message-ID: <200401160919.30020.jkeating@j2solutions.net> On Friday 16 January 2004 08:41, Jonas Pasche wrote: > Okay, so let's start collecting information: > > - Who has write access to the site / whom should I send new content? Eric Rostetter, Warren Togami,and I have write access to the site. The site is held in CVS, but no anon access just yet (weird bug I haven't tracked down). If your content changes and such prove good, I can arrange for you to have write access to the CVS repository as well. > - Who wants to help writing? I can't write much, but I can answer questions about the project and it's direction. > - Who wants to review content before publishing? Or would it be > better to pre-publish content on my own site first and let it be > reviewed by any list members who are willing to? From my point of > view the process is more straightforward if there is only a small > group who manages it, to avoid what I call the "wiki effect": A > couple of pages, some very very detailed, some still to be written, > some pages that are more a bookmark collection than written content, > and everything in different writing styles and quality. I think a private version held on your site that is reviewed by a select few would be good. For now you can run things through me and Eric. Right now Eric is the main web developer for this project. > - To the webmaster: In what file format is new content expected - > plain text? HTML? Or are these pages generated through some kind of > CMS? The pages are html/php (php is just for the dynamic includes at to/bottom/right/left). The pages themselves are held in CVS. I have yet to develop an automated way to get whats in CVS out to the public web. Currently it's a manual process done by either Eric or I. > Regarding the content itself - from my point of view we need two > parts of documentation as a start: > > 1) End users: What is Fedora Legacy? What can I do to keep my system > up to date? Where can I find security advisories? ... > > I think I can prepare this part well, because I know most things > about it. Great, this is very much needed information. We do now have an announce mailing list. http://www.redhat.com/mailman/listinfo/fedora-legacy-announce This list is read-only and it's where update announcements will be posted. > 2) Developers: How can I participate? ... > > This part would be harder for me, because I'm not a developer. > Besides that, package submission and QA mainly works as with > regular Fedora extra packages (I think so?!), which are documented on > the Wiki, however, in a very short form. For legacy packages, the > process should be easier, because some parts (e.g. writing completely > new %pre[un] and %post[un] scripts, package name choosing, desktop > entry choosing) are simply not needed for legacy packages. Anyway, I > need assistance with this part from somebody who knows this process > very well to tell me what is needed and what isn't. Correct. Warren posted his package submission steps a while ago, I provided feedback on how they should be modified to be Legacy specific. It's in this mailing list's archives. Perhaps grabbing his process, applying my changes, and making it static content on our fedoralegacy.org website would be best. > A word about participation in general: There is a short list on > fedoralegacy.org what can be done, but few information how the make > the first steps to actually start helping. In turn, there are quite a > couple of self introductions on the list, so there are people to do > work, but nothing has yet effectively led to officially published > packages, so obviously people are missing directions on what to do > and how to it - or am I missing another reason? Most the infrastructure for contribution is in the air unfortunately. We got a late start on the project, mostly due to my fault. The build server was late in being turned over to me, and it's still not ready for public use, so we're doing things by hand. Warren was awesome and stepped in while I was otherwise busy and got some things rolling. We're almost ready to be self contained, but we do still need some help. I think the biggest step right now is getting the packages published and signed. I do believe there are packages in bugzilla that have gotten the appropriate QA and are ready to be published. Warren and I need to work out a way to get these published and signed. The announce list was one of the roadblocks in getting this done. Now that we have the list, I urge everybody to sign up as we'll be pushing out packages soon. > Based on this, we should also work on the "Participate" section, > telling a bit more than "We need every helping hand we can get" - > maybe more in the style of "We need somebody who regularly checks the > Bugzilla LEGACY queue, downloads packages and test if they build and > install cleanly, then giving feedback on Bugzilla. We need somebody > who watches the Red Hat Announcement list for updates that are > important for Fedora Legacy, does a quick analysis of the update and > informs the people on what is to be done", and so on. Meaning, more a > kind of a job description, to allow interested people to judge what > they can to and what they can't. For example, maybe I'd be > technically able to "do QA" and simply don't know it, because I don't > know what exactly "doing QA" means, being confused by 25 steps in 7 > sections, just to mention the PackageSubmissionQAPolicy document - > and I'm sure I only have to do a few of them, regarding legacy > packages. Agreeable. Specific tasks with shortened steps would be best in this case. While fedora.us has a great deal of information, it is rather difficult to digest. Breaking it into manageable chunks for individuals to do individual tasks would be best for our website. Please keep the questions coming, this is great! -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Jan 16 17:27:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 09:27:35 -0800 Subject: tcpdump and elm questions. In-Reply-To: <34570.209.50.130.84.1074272138.commnav@home.commnav.com> References: <34570.209.50.130.84.1074272138.commnav@home.commnav.com> Message-ID: <200401160927.36057.jkeating@j2solutions.net> On Friday 16 January 2004 08:55, Christian Pearce wrote: > I guess it isn't for me. I want to try and clarify. > > In all cases leave epoch alone. > > We use the same spec file but the _revisions_ are different. > > elm: > > dist|orig|legacy > 7.2 elm-2.5.6-1 -> elm-2.5.6.3.legacy > 7.3 elm-2.5.6-2 -> elm-2.5.6.3.legacy > > tcpdump: > 7.2 tcpdump-3.6.3-17.7.2.3 -> tcpdump-3.6.3-17.7.2.4.legacy > 7.3 tcpdump-3.6.3-17.7.3.3 -> tcpdump-3.6.3-17.7.3.4.legacy > 8.0 tcpdump-3.6.3-17.8.0.3 -> tcpdump-3.6.3-17.8.0.4.legacy Not quite. if the package is the same across the 7.x platform, the disttag becomes 7x. But if there is no distag already in the package name, please don't add one. elm: 7.2 elm-2.5.6-1 -> elm-2.5.6-3.legacy 7.3 elm-2.5.6-2 -> elm-2.5.6-4.legacy tcpdump: 7.2 tcpdump-3.6.3-17.7.2.3 -> tcpdump-3.6.3-17.7.2.4.legacy 7.3 tcpdump-3.6.3-17.7.3.3 -> tcpdump-3.6.3-17.7.3.4.legacy 8.0 tcpdump-3.6.3-17.8.0.3 -> tcpdump-3.6.3-17.8.0.4.legacy This seems fine. In the past, RH has bumped the last number up, leaving the "-17.x.x" alone, so we should follow suit on this one. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pmatilai at welho.com Fri Jan 16 17:43:41 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 16 Jan 2004 19:43:41 +0200 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] Message-ID: <1074275021.7350.0.camel@chip.laiskiainen.org> Thought you folks might be interested... - Panu - -----Forwarded Message----- From: Ryan Finnie To: whitebox-devel at beau.org Subject: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0 Date: Fri, 16 Jan 2004 04:34:49 -0800 http://oss.redundant.com/pub/party-updates/ I'm taking the white box linux approach for the update RPMs that Progeny is releasing for EOL'd RHL releases. If you still have some 7.2/7.3/8.0 boxes around (as I do), this should help you out. BTW, yum rocks. I don't know why I haven't played with it until recently. RF _______________________________________________ Whitebox-devel mailing list Whitebox-devel at beau.org http://beau.org/mailman/listinfo/whitebox-devel From jkeating at j2solutions.net Fri Jan 16 17:44:43 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 09:44:43 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> Message-ID: <200401160944.43607.jkeating@j2solutions.net> On Friday 16 January 2004 09:16, Eric Rostetter wrote: > Here is my list of FAQ's, but without good answers. If anyone can > supply answers, I'll get them on the web site asap. > > * What is the errata policy for The Fedora Legacy Project? It's "update" and not errata first. For RHL systems, we will continue to issue backports for as long as there is community interest. At lease another 1.5 years. For FC releases, we will follow a 1-2-3 and out policy. FC1 is released, then FC2. When FC2 releases, FC1 is no longer supported by RH. Legacy then supports FC1. FC3 releases and RH drops FC2. Legacy picks up FC2, and FC1 becomes deprecated. FC4 releases, RH drops FC3, Legacy picks up FC3, Legacy drops FC1, and FC2 becomes deprecated. This will insure roughly 1.5 years of updates total for any FC release. When Legacy drops a release, backports are still accepted, but they neither get Legacy keysigned, nor get QAd. Perhaps we'll have a seperate "unsupported" repository. This needs more discussion, but can wait. > * What version of RHL/FC are supported? RHL 7.[123], 8.0. In the future, we'll support RHL9, FC1, etc... > * What architectures are supported? x86 for now. With FC releases, x86_64 will be come supported as well. SRPMS are provided so that other archs can use them. > * How do I update packages? Using yum, apt-get, or manually downloading packages from our updates channel. Currently updates are hosted at fedora.us, soon to be expanded to our mirror system. The mirror system needs engineering, but it can wait just a bit longer. > * How do I get notifications about new updates when they become > available? By signing up to the fedora-legacy-announce list: https://www.redhat.com/mailman/listinfo/fedora-legacy-announce > * Where can I get more info on apt/yum? Specific Legacy related info, or just general info? > Anyone interested in posting the IRC logs on the web? Might be > interesting for those of us who don't IRC to be able to browse the > logs... Could be possible, although the logs tend to be quite long and not exactly easy to follow. My client logs IRC and I have a persistant connection to the channel. I can provide the text files from that channel log if you'd like. Perhaps we can run a logging bot in the future. I'm still not sure about this one. Thoughts? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rohwedde at codegrinder.com Fri Jan 16 18:01:36 2004 From: rohwedde at codegrinder.com (Jason) Date: Fri, 16 Jan 2004 12:01:36 -0600 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <1074275021.7350.0.camel@chip.laiskiainen.org> References: <1074275021.7350.0.camel@chip.laiskiainen.org> Message-ID: <20040116180136.GL3353@codegrinder.com> This is interesting, in that it'll give us a bit of insight into how progeny handles these updates.. and their src.rpm's may be valuable to verify patches that we apply from other sources. But, I think we should resist the temptation to merely copy their work. After all, when FC1 eol's we'll certainly need to be able to stand on our own merit. -jason On Fri, Jan 16, 2004 at 07:43:41PM +0200, Panu Matilainen wrote: > Thought you folks might be interested... > > - Panu - > > -----Forwarded Message----- > From: Ryan Finnie > To: whitebox-devel at beau.org > Subject: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0 > Date: Fri, 16 Jan 2004 04:34:49 -0800 > > http://oss.redundant.com/pub/party-updates/ > > I'm taking the white box linux approach for the update RPMs that Progeny > is releasing for EOL'd RHL releases. If you still have some 7.2/7.3/8.0 > boxes around (as I do), this should help you out. > > BTW, yum rocks. I don't know why I haven't played with it until recently. > > RF > _______________________________________________ > Whitebox-devel mailing list > Whitebox-devel at beau.org > http://beau.org/mailman/listinfo/whitebox-devel > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cspencer at cait.org Fri Jan 16 18:19:33 2004 From: cspencer at cait.org (Chris Spencer) Date: Fri, 16 Jan 2004 12:19:33 -0600 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <20040116180136.GL3353@codegrinder.com> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> Message-ID: <1074277173.15831.12.camel@chriss2.cait.org> Things like that will probably make sure progeny makes no effort to continue the service. Besides which it does actually violate the SLA that the subscribers agree to so whoever chooses to provide updates in this way can be cut off from updates from Progeny. The same is true for whitebox Linux. -Chris On Fri, 2004-01-16 at 12:01, Jason wrote: > This is interesting, in that it'll give us a bit of insight into how > progeny handles these updates.. and their src.rpm's may be valuable to > verify patches that we apply from other sources. But, I think we should > resist the temptation to merely copy their work. After all, when FC1 > eol's we'll certainly need to be able to stand on our own merit. > > -jason > > On Fri, Jan 16, 2004 at 07:43:41PM +0200, Panu Matilainen wrote: > > Thought you folks might be interested... > > > > - Panu - > > > > -----Forwarded Message----- > > From: Ryan Finnie > > To: whitebox-devel at beau.org > > Subject: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0 > > Date: Fri, 16 Jan 2004 04:34:49 -0800 > > > > http://oss.redundant.com/pub/party-updates/ > > > > I'm taking the white box linux approach for the update RPMs that Progeny > > is releasing for EOL'd RHL releases. If you still have some 7.2/7.3/8.0 > > boxes around (as I do), this should help you out. > > > > BTW, yum rocks. I don't know why I haven't played with it until recently. > > > > RF > > _______________________________________________ > > Whitebox-devel mailing list > > Whitebox-devel at beau.org > > http://beau.org/mailman/listinfo/whitebox-devel > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list "Why, of course, the people don't want war... Voice or no voice, the people can always be brought to the bidding of the leaders... All you have to do is tell them they are being attacked and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in any country." - Nazi Hermann Goering, at the Nuremberg war-crimes tribunal From mail at jonaspasche.de Fri Jan 16 18:40:54 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 16 Jan 2004 19:40:54 +0100 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> Message-ID: <1074278454.3608.305.camel@leonardo> Hi Eric, > Here is my list of FAQ's, but without good answers. If anyone can supply > answers, I'll get them on the web site asap. Thanks. I have started with them, collection information from other fedoralegacy.org pages, the Wiki and Jesse's recent posting, and finally created: http://jonaspasche.de/fedoralegacy/faq.html Some entries need a bit work; I have added my questions in italics. Please post comments and corrections on the list! The HTML source of the FAQ entries has the same format as the original page, so publishing should be just copy and paste. > Jesse if you want direct access to the web site CVS. Otherwise you can send > submissions to me directly and I'll put them in CVS. I don't need CVS access, as I'm not familiar with it. Anyway, we can talk about it later, if people decide that my writing is good enough to publish pages directly. > If no one else does, I'll try to "steal" the fedora pages and add them to > our web site. We can refine from there. I should be able to get to this > later today if no one else does. That would be a good start for the developer's documentation! > Anyone interested in posting the IRC logs on the web? Might be interesting > for those of us who don't IRC to be able to browse the logs... Maybe on the wiki; IMHO fedoralegacy.org should be a clean site composed by editorial staff, while the wiki is used by active developers. I don't think end users and people willing to help are interested in raw IRC logs. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rostetter at mail.utexas.edu Fri Jan 16 18:49:24 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Jan 2004 12:49:24 -0600 Subject: Getting started with documentation In-Reply-To: <1074271288.3608.214.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <1074271288.3608.214.camel@leonardo> Message-ID: <20040116124924.nnusiyqogcs4kcw0@mail.ph.utexas.edu> Quoting Jonas Pasche : > Okay, so let's start collecting information: > > - Who has write access to the site / whom should I send new content? Jesse, myself, probably warren? > - Who wants to help writing? You may be on your own :( > - Who wants to review content before publishing? Or would it be better > to pre-publish content on my own site first and let it be reviewed by > any list members who are willing to? From my point of view the process Either is fine. I can review/clean-up content if you want. Or posting for list review is fine. > - To the webmaster: In what file format is new content expected - plain > text? HTML? Or are these pages generated through some kind of CMS? Either plain text or html. PHP is okay if used for a reason. No CMS system as of now. We do have it in CVS. There's a link on the web page (upper right "news" section) to info about the cvs. > Regarding the content itself - from my point of view we need two parts > of documentation as a start: > > 1) End users: What is Fedora Legacy? What can I do to keep my system up > to date? Where can I find security advisories? ... What it is we try to cover in the "about" section. How to keep it up to date we try to cover somewhat in the "download" section. Where can I find advisories has yet to be determined as far as I know. I think an announcement mailing list is in the cooker but not done yet? > I think I can prepare this part well, because I know most things > about it. Start with what is there, and add on or rewrite it. > 2) Developers: How can I participate? ... This needs a lot of work! > This part would be harder for me, because I'm not a developer. > Besides that, package submission and QA mainly works as with regular > Fedora extra packages (I think so?!), which are documented on the > Wiki, however, in a very short form. For legacy packages, the process > should be easier, because some parts (e.g. writing completely new > %pre[un] and %post[un] scripts, package name choosing, desktop entry > choosing) are simply not needed for legacy packages. Anyway, I need > assistance with this part from somebody who knows this process very > well to tell me what is needed and what isn't. Yes, me too. I'm going to steal some of the fedora stuff for our site, and hope it gets refined from there. But any help from anyone is welcome. > A word about participation in general: There is a short list on > fedoralegacy.org what can be done, but few information how the make the > first steps to actually start helping. In turn, there are quite a couple Yes, that page is very bad. Needs lots of help. > of self introductions on the list, so there are people to do work, but > nothing has yet effectively led to officially published packages, so > obviously people are missing directions on what to do and how to it - or > am I missing another reason? I think direction/directions are certainly missing. As are definitions as to what certain steps in the process even mean. > Based on this, we should also work on the "Participate" section, telling Yes, please do! > be done", and so on. Meaning, more a kind of a job description, to allow > interested people to judge what they can to and what they can't. For > example, maybe I'd be technically able to "do QA" and simply don't know > it, because I don't know what exactly "doing QA" means, being confused > by 25 steps in 7 sections, just to mention the PackageSubmissionQAPolicy > document - and I'm sure I only have to do a few of them, regarding > legacy packages. Yes, exactly. Great idea linking it to a "job description" style. Sounds great. > Jonas -- Eric Rostetter From mail at jonaspasche.de Fri Jan 16 19:05:36 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 16 Jan 2004 20:05:36 +0100 Subject: Getting started with documentation In-Reply-To: <200401160919.30020.jkeating@j2solutions.net> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <1074271288.3608.214.camel@leonardo> <200401160919.30020.jkeating@j2solutions.net> Message-ID: <1074279935.3608.322.camel@leonardo> Hi Jesse, > I think a private version held on your site that is reviewed by a select > few would be good. For now you can run things through me and Eric. > Right now Eric is the main web developer for this project. I already posted a link to my FAQ entries; in general I will pre-publish documentation updates here: http://jonaspasche.de/fedoralegacy/ I'll try to write down detailed instructions for end users over the weekend and publish them there for a review. > http://www.redhat.com/mailman/listinfo/fedora-legacy-announce > > This list is read-only and it's where update announcements will be > posted. Great, that has been a missing link! > Correct. Warren posted his package submission steps a while ago, I > provided feedback on how they should be modified to be Legacy specific. > It's in this mailing list's archives. Perhaps grabbing his process, > applying my changes, and making it static content on our > fedoralegacy.org website would be best. I'd be glad if somebody that is actively involved in this process could quickly threw the most important things toghether and post them here or send them by private mail to, as I don't know where to start here. I'm going to transform it into publishable document, polishing it, and - most important, I guess - review it from the perspective of somebody who has never submitted any packages before, but wants to learn and help. > Agreeable. Specific tasks with shortened steps would be best in this > case. While fedora.us has a great deal of information, it is rather > difficult to digest. Breaking it into manageable chunks for > individuals to do individual tasks would be best for our website. Okay, I'll do the end user's section first. For the developer's section, I kindly ask for help to have a start, as said above. Alternatively, I'll start working on the "Who we need, and what people should do to help us" section, whatever comes first. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora-legacy at share-foo.com Fri Jan 16 19:09:28 2004 From: fedora-legacy at share-foo.com (Ray Ferguson) Date: Fri, 16 Jan 2004 13:09:28 -0600 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <1074277173.15831.12.camel@chriss2.cait.org> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> Message-ID: <200401161309.28932.fedora-legacy@share-foo.com> Technically the sources are GPLed so the provider never has to have a subscription or SLA of any kind to be entitled to the source code. Additionally WBEL scrubs the source of trade marks prior to recompile, so you can use WBEL without voiding RHEL SLAs. Same goes for progeny. However, I agree with you that using these products reduces the incentive for the companies to continue releasing and maintaining the products. Personally I'm leaning heavily towards using Progeny, but if we do so, it will be under straightforward terms. We will pay for every box that uses the RPMs even though we will be maintaining our own repository and could get away with hell. The reason is quite simple. $60/yr per box is affordable, and if enough people pay it, Progeny will make money and continue providing the service. Now WBEL on the other hand, I do use at home for development and experimentation. At work, in production, we pay for it. It's also good for academia. RH's refusal to reduce their rates and offer RHEL under affordable terms to academic institutions already excludes those potential consumers who now must find alternate solutions. I should think RH would be better off with those consumers then using WBEL instead of SUSE, Mandrake, Debian or another alternative. This way they still can maintain mind-share they way they formerly did with the standard RH line. Most of the customers RHEL is targeting won't touch WBEL anyway since support for it is an unknown and though it may be technically legal, it smells sketchy. I think RH has already realizes that WBEL is not a threat, and that it may even be good for RHEL. This would explain why they haven't made any efforts to F* w/ WBEL. Sorry if my 2 cents is a little off topic. BTW: 1. Ray Ferguson 2. Madison, WI 3. Operations Engineer 4. Berbee 5. Goals: provide migration solution. 6. Qualifications: unimportant as I do not have time to contribute. I will let you know if this changes. -ray. On Friday 16 January 2004 12:19 pm, Chris Spencer wrote: > Things like that will probably make sure progeny makes no effort to > continue the service. > > Besides which it does actually violate the SLA that the subscribers > agree to so whoever chooses to provide updates in this way can be cut > off from updates from Progeny. > > The same is true for whitebox Linux. > > > -Chris > > On Fri, 2004-01-16 at 12:01, Jason wrote: > > This is interesting, in that it'll give us a bit of insight into how > > progeny handles these updates.. and their src.rpm's may be valuable to > > verify patches that we apply from other sources. But, I think we should > > resist the temptation to merely copy their work. After all, when FC1 > > eol's we'll certainly need to be able to stand on our own merit. > > > > -jason > > > > On Fri, Jan 16, 2004 at 07:43:41PM +0200, Panu Matilainen wrote: > > > Thought you folks might be interested... > > > > > > - Panu - > > > > > > -----Forwarded Message----- > > > From: Ryan Finnie > > > To: whitebox-devel at beau.org > > > Subject: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0 > > > Date: Fri, 16 Jan 2004 04:34:49 -0800 > > > > > > http://oss.redundant.com/pub/party-updates/ > > > > > > I'm taking the white box linux approach for the update RPMs that > > > Progeny is releasing for EOL'd RHL releases. If you still have some > > > 7.2/7.3/8.0 boxes around (as I do), this should help you out. > > > > > > BTW, yum rocks. I don't know why I haven't played with it until > > > recently. > > > > > > RF > > > _______________________________________________ > > > Whitebox-devel mailing list > > > Whitebox-devel at beau.org > > > http://beau.org/mailman/listinfo/whitebox-devel > > > > > > > > > -- > > > fedora-legacy-list mailing list > > > fedora-legacy-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > "Why, of course, the people don't want war... Voice or no voice, the > people can always be brought to the bidding of the leaders... All you > have to do is tell them they are being attacked and denounce the > pacifists for lack of patriotism and exposing the country to danger. It > works the same in any country." - Nazi Hermann Goering, at the Nuremberg > war-crimes tribunal > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Fri Jan 16 19:03:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 11:03:59 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <1074278454.3608.305.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <1074278454.3608.305.camel@leonardo> Message-ID: <200401161104.03413.jkeating@j2solutions.net> On Friday 16 January 2004 10:40, Jonas Pasche wrote: > http://jonaspasche.de/fedoralegacy/faq.html > > Some entries need a bit work; I have added my questions in italics. > Please post comments and corrections on the list! Number 1, change "errata" to "update". Number 2, feel free to drop the 7.1, I was mistaken. You list "7.2, 7.3, and 8.0, as /both/". Shouldn't that both be more like "as /these/"? All FC releases will be supported, please see my other email about support length. Number 3, 7.2 was actually released for ia64 and s390, but I doubt there are many legacy users that are interested in those. We do not have the resources to be able to build packages and QA packages for these archs. There is an amd64 release of FC1 in public test 1 phase right now, so we will support amd64 FC1. Number 4, the mirror list will have locations, so we can flat list areas of the world and list mirrors that way. Number 5, the example should be on the download page probably. Link to it. Number 6, Link to the download page, the download page should link to apt/yum respective homepages. Number 7, We're free and public, we're providing longer support, we support yum/apt freedownloads, we will support Fedora Core. Number 8, change the "to" to "two". To answer your question, it's more of when RH no longer supports FC3, thats when Legacy picks it up, and no longer supports FC1. Legacy will end up (officially) supporting 2 FC releases at any given time. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pearcec at commnav.com Fri Jan 16 19:32:57 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 19:32:57 GMT Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] Message-ID: <34865.209.50.130.84.1074281577.commnav@home.commnav.com> Progeny is trying to make money in a closed end market. It is really not a good business investment. Moving forward I think Fedora Legacy has a future with Fedora Core EOLs. Is progeny planning to do the same? Doubt it. Will them make money on 7.2-9 long after Fedora Legacy leaves it behind? Maybe. Are they going to find it increasingly more difficult? yes. For the same reasons we will choose to stop supporting it. Can they charge more money as they go? Sure why not. Will we see people move from Progeny to FedoraLegacy and vice-versa? Yes. Does my company want to spend money on this? No they can spend my hours helping with the project since that money already exists. It is a soft value. I can't blame progeny for doing it, I would do the exact same thing if I was that company. They are already set up for it. As fars this WBEL stuff. Cool like like to have some else shoulders to look over. Only as a verification. Personally I enjoy going through the process. Makes me feel more confident about what I am putting on my systems. Are group is always going to be a little behind. Let's face facts. I think we will always have an example of some sort to work with. -- Christian Pearce http://www.commnav.com Ray Ferguson said: > > Technically the sources are GPLed so the provider never has to have a > subscription or SLA of any kind to be entitled to the source code. > Additionally WBEL scrubs the source of trade marks prior to recompile, so you > can use WBEL without voiding RHEL SLAs. Same goes for progeny. However, I > agree with you that using these products reduces the incentive for the > companies to continue releasing and maintaining the products. Personally I'm > leaning heavily towards using Progeny, but if we do so, it will be under > straightforward terms. We will pay for every box that uses the RPMs even > though we will be maintaining our own repository and could get away with > hell. The reason is quite simple. $60/yr per box is affordable, and if > enough people pay it, Progeny will make money and continue providing the > service. > > Now WBEL on the other hand, I do use at home for development and > experimentation. At work, in production, we pay for it. It's also good for > academia. RH's refusal to reduce their rates and offer RHEL under affordable > terms to academic institutions already excludes those potential consumers who > now must find alternate solutions. I should think RH would be better off > with those consumers then using WBEL instead of SUSE, Mandrake, Debian or > another alternative. This way they still can maintain mind-share they way > they formerly did with the standard RH line. Most of the customers RHEL is > targeting won't touch WBEL anyway since support for it is an unknown and > though it may be technically legal, it smells sketchy. I think RH has > already realizes that WBEL is not a threat, and that it may even be good for > RHEL. This would explain why they haven't made any efforts to F* w/ WBEL. > > Sorry if my 2 cents is a little off topic. > > BTW: > > 1. Ray Ferguson > 2. Madison, WI > 3. Operations Engineer > 4. Berbee > 5. Goals: provide migration solution. > 6. Qualifications: unimportant as I do not have time to contribute. I will let > you know if this changes. > > -ray. > > On Friday 16 January 2004 12:19 pm, Chris Spencer wrote: > > Things like that will probably make sure progeny makes no effort to > > continue the service. > > > > Besides which it does actually violate the SLA that the subscribers > > agree to so whoever chooses to provide updates in this way can be cut > > off from updates from Progeny. > > > > The same is true for whitebox Linux. > > > > > > -Chris > > > > On Fri, 2004-01-16 at 12:01, Jason wrote: > > > This is interesting, in that it'll give us a bit of insight into how > > > progeny handles these updates.. and their src.rpm's may be valuable to > > > verify patches that we apply from other sources. But, I think we should > > > resist the temptation to merely copy their work. After all, when FC1 > > > eol's we'll certainly need to be able to stand on our own merit. > > > > > > -jason > > > > > > On Fri, Jan 16, 2004 at 07:43:41PM +0200, Panu Matilainen wrote: > > > > Thought you folks might be interested... > > > > > > > > - Panu - > > > > > > > > -----Forwarded Message----- > > > > From: Ryan Finnie > > > > To: whitebox-devel at beau.org > > > > Subject: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0 > > > > Date: Fri, 16 Jan 2004 04:34:49 -0800 > > > > > > > > http://oss.redundant.com/pub/party-updates/ > > > > > > > > I'm taking the white box linux approach for the update RPMs that > > > > Progeny is releasing for EOL'd RHL releases. If you still have some > > > > 7.2/7.3/8.0 boxes around (as I do), this should help you out. > > > > > > > > BTW, yum rocks. I don't know why I haven't played with it until > > > > recently. > > > > > > > > RF > > > > _______________________________________________ > > > > Whitebox-devel mailing list > > > > Whitebox-devel at beau.org > > > > http://beau.org/mailman/listinfo/whitebox-devel > > > > > > > > > > > > -- > > > > fedora-legacy-list mailing list > > > > fedora-legacy-list at redhat.com > > > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > "Why, of course, the people don't want war... Voice or no voice, the > > people can always be brought to the bidding of the leaders... All you > > have to do is tell them they are being attacked and denounce the > > pacifists for lack of patriotism and exposing the country to danger. It > > works the same in any country." - Nazi Hermann Goering, at the Nuremberg > > war-crimes tribunal > > > > > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From cspencer at cait.org Fri Jan 16 20:12:48 2004 From: cspencer at cait.org (Chris Spencer) Date: Fri, 16 Jan 2004 14:12:48 -0600 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <200401161309.28932.fedora-legacy@share-foo.com> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> Message-ID: <1074283968.15843.49.camel@chriss2.cait.org> On Fri, 2004-01-16 at 13:09, Ray Ferguson wrote: > Technically the sources are GPLed so the provider never has to have a > subscription or SLA of any kind to be entitled to the source code. > Additionally WBEL scrubs the source of trade marks prior to recompile, so you > can use WBEL without voiding RHEL SLAs. Same goes for progeny. I can take a get the source to a product under the GPL. I can make modifications to it and repackage it. I can sell my repackaged for to corporation XYZ and I can say here is a modified product. It's licensed under the GPL so here is the source. You can do with it anything you want...but if you re-release it I won't sell you the next upgrade. XYZ can re-release the code in any way they want...they have the freedom that the GPL affords but I don't have to continue to do business with them. As far as Red Hat and WBEL goes....what it boils down to (my bet) is that they don't want the negative publicity associated with cracking down on it. The fact is they can't touch WBEL anyway. They can however, shut off the freely (and openly) provided distribution and errata source code. They still have to provide it but they could get away with doing it only for subscribers and they could tell their subscribers that their service would be terminated if they used it on multiple systems without paying for each. What I would hope is that people that are do these types of things don't expect that they will be allowed to forever get no cost updates. If people want no cost updates then they better start contributing right here. Right now. -Chris "There are only two things that are infinite: the universe and human stupidity. And I'm not sure about the universe." - Albert Einstein From rostetter at mail.utexas.edu Fri Jan 16 20:07:11 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Jan 2004 14:07:11 -0600 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <200401160944.43607.jkeating@j2solutions.net> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <200401160944.43607.jkeating@j2solutions.net> Message-ID: <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> Quoting Jesse Keating : > > * What is the errata policy for The Fedora Legacy Project? > > It's "update" and not errata first. Changed. > For FC releases, we will follow a 1-2-3 and > out policy. FC1 is released, then FC2. When FC2 releases, FC1 is no > longer supported by RH. Legacy then supports FC1. FC3 releases and RH > drops FC2. Legacy picks up FC2, and FC1 becomes deprecated. FC4 > releases, RH drops FC3, Legacy picks up FC3, Legacy drops FC1, and FC2 > becomes deprecated. This will insure roughly 1.5 years of updates > total for any FC release. When Legacy drops a release, backports are > still accepted, but they neither get Legacy keysigned, nor get QAd. > Perhaps we'll have a seperate "unsupported" repository. This needs > more discussion, but can wait. Can anyone summarize this is a short, easy to understand way for the FAQ? And how official is that last part about accepting backports after the support is ended? > > * What version of RHL/FC are supported? > > RHL 7.[123], 8.0. In the future, we'll support RHL9, FC1, etc... There is no repository for 7.1, so I'm not putting that in yet. If someone creates/populates a 7.1 repo, we can revisit it. > > * Where can I get more info on apt/yum? > > Specific Legacy related info, or just general info? Both actually. :) -- Eric Rostetter From mail at jonaspasche.de Fri Jan 16 20:25:01 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 16 Jan 2004 21:25:01 +0100 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <200401161104.03413.jkeating@j2solutions.net> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <1074278454.3608.305.camel@leonardo> <200401161104.03413.jkeating@j2solutions.net> Message-ID: <1074284701.3608.368.camel@leonardo> Hi Jesse, > Number 1, change "errata" to "update". Fixed. For my clarification; what exactly is the difference between these two words? Red Hat publishes all updates as "errata" with the subcategories "security alerts", "bugfixes" and "enhancements"; that's why I thought "errata" would be appropriate. > Number 2, feel free to drop the 7.1, I was mistaken. You list "7.2, > 7.3, and 8.0, as /both/". Shouldn't that both be more like "as > /these/"? All FC releases will be supported, please see my other email > about support length. Fixed. > Number 3, 7.2 was actually released for ia64 and s390, but I doubt there > are many legacy users that are interested in those. We do not have the > resources to be able to build packages and QA packages for these archs. > There is an amd64 release of FC1 in public test 1 phase right now, so > we will support amd64 FC1. Fixed; but I don't publish concrete plans for FC1 yet, because it's neither officially published for amd64 nor outdated yet. > Number 4, the mirror list will have locations, so we can flat list areas > of the world and list mirrors that way. What does that mean for the published page? IMHO we should dynamically provide a link to a near mirror, based on the IP of the user, and give the option to list other mirrors. Alternatively, show the fedora.us download URL, but let the link target be a page to select a mirror instead of a direct link to the fedora.us download server. Any suggestions? I'd prefer a simple solution that can be used _anywhere_ on the site whereever download links are needed. > Number 5, the example should be on the download page probably. Link to > it. I'll include this in my still-to-do end user "How to use Fedora Legacy" page. Actually I find that title better than "Download", because using Fedory Legacy isn't actually like downloading and installing a package, but that's open to discussion. > Number 6, Link to the download page, the download page should link to > apt/yum respective homepages. Fixed. > Number 7, We're free and public, we're providing longer support, we > support yum/apt freedownloads, we will support Fedora Core. Fixed. How long will Progeny provide support? I haven't found a concrete statement on their website, so how can we tell that we're providing longer support? > Number 8, change the "to" to "two". To answer your question, it's more > of when RH no longer supports FC3, thats when Legacy picks it up, and > no longer supports FC1. Legacy will end up (officially) supporting 2 > FC releases at any given time. Fixed, but still not-so-easy to understand, I think. Maybe a small graph can clarify this? If yes - volunteers? I'm not good at such things. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at physik.fu-berlin.de Fri Jan 16 20:46:52 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 16 Jan 2004 21:46:52 +0100 Subject: GPL (was: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0]) In-Reply-To: <1074283968.15843.49.camel@chriss2.cait.org> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> <1074283968.15843.49.camel@chriss2.cait.org> Message-ID: <20040116204652.GF15618@neu.nirvana> On Fri, Jan 16, 2004 at 02:12:48PM -0600, Chris Spencer wrote: > On Fri, 2004-01-16 at 13:09, Ray Ferguson wrote: > > Technically the sources are GPLed so the provider never has to have a > > subscription or SLA of any kind to be entitled to the source code. > > Additionally WBEL scrubs the source of trade marks prior to recompile, so you > > can use WBEL without voiding RHEL SLAs. Same goes for progeny. > > I can take a get the source to a product under the GPL. > I can make modifications to it and repackage it. > I can sell my repackaged for to corporation XYZ and I can say here is a > modified product. It's licensed under the GPL so here is the source. > You can do with it anything you want...but if you re-release it I won't > sell you the next upgrade. All true, but the last, if the product is made _publicly_ available, like RHEL3, Progeny update services etc. > XYZ can re-release the code in any way they want...they have the freedom > that the GPL affords but I don't have to continue to do business with > them. You have to provide source code, even if you never had done or will do business with a person, if you are offering the product publicly. http://www.gnu.org/licenses/gpl-faq.html The above is not to interpreted as an encouragement to follow this practice, that is an etirely different matter. > As far as Red Hat and WBEL goes....what it boils down to (my bet) is > that they don't want the negative publicity associated with cracking > down on it. The fact is they can't touch WBEL anyway. > > They can however, shut off the freely (and openly) provided distribution > and errata source code. They still have to provide it but they could > get away with doing it only for subscribers and they could tell their > subscribers that their service would be terminated if they used it on > multiple systems without paying for each. No, that's not a possible business model with the GPL. (but I'm no lawyer either) > What I would hope is that people that are do these types of things don't > expect that they will be allowed to forever get no cost updates. > > If people want no cost updates then they better start contributing right > here. Right now. > > -Chris > > "There are only two things that are infinite: the universe and human > stupidity. And I'm not sure about the universe." - Albert Einstein > > > -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpdalbec at ysu.edu Fri Jan 16 20:51:08 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 16 Jan 2004 15:51:08 -0500 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <20040116200800.12132.49786.Mailman@listman.back-rdu.redhat.com> References: <20040116200800.12132.49786.Mailman@listman.back-rdu.redhat.com> Message-ID: <40084EBC.7050408@ysu.edu> > From: Ray Ferguson > To: fedora-legacy-list at redhat.com > Subject: Re: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] > Date: Fri, 16 Jan 2004 13:09:28 -0600 > Reply-To: fedora-legacy-list at redhat.com > > $60/yr per box is affordable > RH's refusal to reduce their rates and offer RHEL under affordable > terms to academic institutions http://www.redhat.com/solutions/industries/education/indiv/ $25/year ($50/year for servers) is not affordable, but $60/year is? John From ms-nospam-0306 at arcor.de Fri Jan 16 21:13:37 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 16 Jan 2004 22:13:37 +0100 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <1074284701.3608.368.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <1074278454.3608.305.camel@leonardo> <200401161104.03413.jkeating@j2solutions.net> <1074284701.3608.368.camel@leonardo> Message-ID: <20040116221337.0b159895.ms-nospam-0306@arcor.de> On Fri, 16 Jan 2004 21:25:01 +0100, Jonas Pasche wrote: > > Number 1, change "errata" to "update". > > Fixed. For my clarification; what exactly is the difference between > these two words? Red Hat publishes all updates as "errata" with the > subcategories "security alerts", "bugfixes" and "enhancements"; that's > why I thought "errata" would be appropriate. For Red Hat Linux and Red Hat Enterprise Linux it's "Errata". As of Fedora Core it's "Updates" and "Test Updates". -- From jkeating at j2solutions.net Fri Jan 16 21:22:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 13:22:41 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <1074284701.3608.368.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <200401161104.03413.jkeating@j2solutions.net> <1074284701.3608.368.camel@leonardo> Message-ID: <200401161322.46443.jkeating@j2solutions.net> On Friday 16 January 2004 12:25, Jonas Pasche wrote: > Fixed. For my clarification; what exactly is the difference between > these two words? Red Hat publishes all updates as "errata" with the > subcategories "security alerts", "bugfixes" and "enhancements"; > that's why I thought "errata" would be appropriate. I differ to Warren on this one. We're using "updates" based on his recommendation. He had good reasons, I just forgot them. > > Number 4, the mirror list will have locations, so we can flat list > > areas of the world and list mirrors that way. > > What does that mean for the published page? IMHO we should > dynamically provide a link to a near mirror, based on the IP of the > user, and give the option to list other mirrors. Alternatively, show > the fedora.us download URL, but let the link target be a page to > select a mirror instead of a direct link to the fedora.us download > server. > > Any suggestions? Way too complicated. Who cares where the browser IP is, they could be getting links for a box that is half a country away from them ( I constantly do ). A simple mirror list split by geographical region, allowing the end user to pick their place would be best. > > Number 5, the example should be on the download page probably. > > Link to it. > > I'll include this in my still-to-do end user "How to use Fedora > Legacy" page. Actually I find that title better than "Download", > because using Fedory Legacy isn't actually like downloading and > installing a package, but that's open to discussion. I like that name too, works for me. > > Number 7, We're free and public, we're providing longer support, we > > support yum/apt freedownloads, we will support Fedora Core. > > Fixed. How long will Progeny provide support? I haven't found a > concrete statement on their website, so how can we tell that we're > providing longer support? Don't know for sure. > > Number 8, change the "to" to "two". To answer your question, it's > > more of when RH no longer supports FC3, thats when Legacy picks it > > up, and no longer supports FC1. Legacy will end up (officially) > > supporting 2 FC releases at any given time. > > Fixed, but still not-so-easy to understand, I think. Maybe a small > graph can clarify this? If yes - volunteers? I'm not good at such > things. Instead of a graph, how about a simple timeline that has the events rather than dates. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Jan 16 21:27:15 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 13:27:15 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <200401160944.43607.jkeating@j2solutions.net> <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> Message-ID: <200401161327.15109.jkeating@j2solutions.net> On Friday 16 January 2004 12:07, Eric Rostetter wrote: > Can anyone summarize this is a short, easy to understand way for the > FAQ? And how official is that last part about accepting backports > after the support is ended? I think the best way would be to show a timeline that has text pointers to the events. > > > * What version of RHL/FC are supported? > > > > RHL 7.[123], 8.0. In the future, we'll support RHL9, FC1, etc... > > There is no repository for 7.1, so I'm not putting that in yet. > If someone creates/populates a 7.1 repo, we can revisit it. yeah, my bad. Forget 7.1 > > > * Where can I get more info on apt/yum? > > > > Specific Legacy related info, or just general info? > > Both actually. :) Yeah, well warren has the info on that. Basically it's the same configuration that you'd use for fedora.us, minus the os.stable/testing stuff. just the os and os.updates. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Jan 16 21:28:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 13:28:31 -0800 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <40084EBC.7050408@ysu.edu> References: <20040116200800.12132.49786.Mailman@listman.back-rdu.redhat.com> <40084EBC.7050408@ysu.edu> Message-ID: <200401161328.32023.jkeating@j2solutions.net> On Friday 16 January 2004 12:51, John Dalbec wrote: > $25/year ($50/year for servers) is not affordable, but $60/year is? > John There are some heavy restrictions on the educational discounts. Be wary. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From kelson at speed.net Fri Jan 16 21:39:02 2004 From: kelson at speed.net (Kelson Vibber) Date: Fri, 16 Jan 2004 13:39:02 -0800 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <200401160944.43607.jkeating@j2solutions.net> <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> Message-ID: <6.0.1.1.0.20040116132320.027bfaa8@mail.speed.net> At 12:07 PM 1/16/2004, Eric Rostetter wrote: >Can anyone summarize this is a short, easy to understand way for the FAQ? >And how official is that last part about accepting backports after the >support is ended? How about something like this: Fedora Legacy will provide updates for Fedora Core releases two versions back from the current release. When Fedora Core 3 is available, we will provide updates for Fedora Core 1 and 2. When Fedora Core 4 is released, we will provide updates for Fedora Core 2 and 3. The actual hand-off will occur when the main Fedora Project drops support for each old release. Based on the current schedule for Fedora Core, this should give each release about 1.5 years of update support. Kelson Vibber SpeedGate Communications From zen23003 at zen.co.uk Fri Jan 16 21:44:06 2004 From: zen23003 at zen.co.uk (Paul Welsh) Date: Fri, 16 Jan 2004 21:44:06 -0000 Subject: Legacy not mentioned at http://fedora.redhat.com? References: <40053205.1000106@togami.com> Message-ID: <005401c3dc79$dde60a20$0100000a@lan> Probably a dumb question, but how come the Legacy project isn't mentioned at http://fedora.redhat.com/ ? I can find no mention of this project, anyhow. From jkeating at j2solutions.net Fri Jan 16 21:44:09 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 13:44:09 -0800 Subject: Legacy not mentioned at http://fedora.redhat.com? In-Reply-To: <005401c3dc79$dde60a20$0100000a@lan> References: <40053205.1000106@togami.com> <005401c3dc79$dde60a20$0100000a@lan> Message-ID: <200401161344.09117.jkeating@j2solutions.net> On Friday 16 January 2004 13:44, Paul Welsh wrote: > Probably a dumb question, but how come the Legacy project isn't > mentioned at http://fedora.redhat.com/ ? I can find no mention of > this project, anyhow. We used to be mentioned under the Fedora Name page, but that page seems WAY smaller than it was. I'll ping the powers that be and see if we can't get linkage from it. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pearcec at commnav.com Fri Jan 16 21:50:12 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 21:50:12 GMT Subject: tcpdump bug entered #1222 needs QA Message-ID: <35101.209.50.130.84.1074289812.commnav@home.commnav.com> The link: https://bugzilla.fedora.us/show_bug.cgi?id=1222 The solution: I grabbed the patches from RedHat AS2.1. They were very similiar in nature to what Johnny Strom put together. I could have produced them myself, but figured it wasn't necessary. I would just be reinventing the weel. Johnny, you had to add a DEFINE of _U_=\"\" to fix you complication errors. You effectively did the same thing by removing them. Thanks for your help. I entered an informative bug. I compiled for 7.3 and make src rpms for 7.2 and 8.0 by changing the dist revision number. They are basically the same. We should QA and test at the same time. If anyone has a problem with the approach let me know. We can make changes if need be. At this point I want to show the everyone we are capable of doing this. -- Christian Pearce http://www.commnav.com From rostetter at mail.utexas.edu Fri Jan 16 21:51:46 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Jan 2004 15:51:46 -0600 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <1074284701.3608.368.camel@leonardo> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <1074278454.3608.305.camel@leonardo> <200401161104.03413.jkeating@j2solutions.net> <1074284701.3608.368.camel@leonardo> Message-ID: <20040116155146.zljnjg9kw8k4o888@mail.ph.utexas.edu> Quoting Jonas Pasche : > > Number 4, the mirror list will have locations, so we can flat list areas > > of the world and list mirrors that way. > > What does that mean for the published page? IMHO we should dynamically > provide a link to a near mirror, based on the IP of the user, and give > the option to list other mirrors. Alternatively, show the fedora.us > download URL, but let the link target be a page to select a mirror > instead of a direct link to the fedora.us download server. I could code something up in php which would check the user's IP, find it's theoretical country code, and try to match that to a mirror's country code. But what if there is no mirror in their country? How to we find a "close" or "closest" country? If a country has several mirrors, how do we know which is closest? If the closest isn't the fastest, they may want another anyway... Seems too much bother to me... I think a link to the entire list, organized by country, is fine. I don't think trying to match the user to the country will work well. > Any suggestions? > > I'd prefer a simple solution that can be used _anywhere_ on the site > whereever download links are needed. See above. I can start coding something up, but I don't think it will work well. Maybe we can create a flat list organized by country, with #name links to each country. Then we can try to find the user's country code, and if we can send them to the page with the #name link set to their country, so they see their country first. If we can't find their country, we just send them to the top of the list. Kind of a mix of the two ideas... > Fixed, but still not-so-easy to understand, I think. Maybe a small graph > can clarify this? If yes - volunteers? I'm not good at such things. I'll commit a slightly modified version of it, and then take comments on it. Ideas welcome still. > Jonas -- Eric Rostetter From cspencer at cait.org Fri Jan 16 22:01:04 2004 From: cspencer at cait.org (Chris Spencer) Date: Fri, 16 Jan 2004 16:01:04 -0600 Subject: GPL (was: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0]) In-Reply-To: <20040116204652.GF15618@neu.nirvana> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> <1074283968.15843.49.camel@chriss2.cait.org> <20040116204652.GF15618@neu.nirvana> Message-ID: <1074290464.15843.200.camel@chriss2.cait.org> On Fri, 2004-01-16 at 14:46, Axel Thimm wrote: > All true, but the last, if the product is made _publicly_ available, > like RHEL3, Progeny update services etc. It's not _publicly_ available. They only owe source code to those people that have purchased it. The people that have done so are free to give that source code away but they have no promise to subsequent binary releases. No law or license says you have to do business with someone. > http://www.gnu.org/licenses/gpl-faq.html No where here does it say what you claim. In fact it says: The GPL says that modified versions, if released, must be "licensed ... to all third parties." Who are these third parties? Section 2 says that modified versions you distribute must be licensed to all third parties under the GPL. "All third parties" means absolutely everyone--but this does not require you to *do* anything physically for them. It only means they have a license from you, under the GPL, for your version. ---- Which means that you can't go after someone for using something you made/released once they have it. If they have the software, it's legal for them to have it. Not only that once they have it you are required to make the source available to them. IE: They have the right to redistribute the binaries once they have them as well as the source. It still doesn't say you have to give any updates to them and if they can't provide proof that they have have the new binaries (with a written notice, that is included with the binaries) you don't have to give the source. Eventually you may have to give the source out but you can legally delay that process enough to make sure that anyone using updates not obtained from you are vulnerable for awhile. This part comes from the GPL section 3 letter b where it reads: b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, (http://www.gnu.org/copyleft/gpl.html) The point here again is these companies are playing nice and if enough people erode enough of the money they will stop playing nice. They are under no obligation, although unlike the entertainment industry they don't want to harass their customers. and again...people that want free updates ought to be contributing to the process. This is the place to do that. -Chris "Why, of course, the people don't want war... Voice or no voice, the people can always be brought to the bidding of the leaders... All you have to do is tell them they are being attacked and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in any country." - Nazi Hermann Goering, at the Nuremberg war-crimes tribunal From rostetter at mail.utexas.edu Fri Jan 16 22:13:48 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Jan 2004 16:13:48 -0600 Subject: Self-Introduction: Jonas Pasche In-Reply-To: <6.0.1.1.0.20040116132320.027bfaa8@mail.speed.net> References: <34315.209.50.130.84.1074265111.commnav@home.commnav.com> <20040116111644.uudwsgw8kcoos40w@mail.ph.utexas.edu> <200401160944.43607.jkeating@j2solutions.net> <20040116140711.qsixo8lws080k8s8@mail.ph.utexas.edu> <6.0.1.1.0.20040116132320.027bfaa8@mail.speed.net> Message-ID: <20040116161348.aqdjtpbokwgcoc0w@mail.ph.utexas.edu> Quoting Kelson Vibber : > How about something like this: > > Fedora Legacy will provide updates for Fedora Core releases two versions > back from the current release. When Fedora Core 3 is available, we will > provide updates for Fedora Core 1 and 2. When Fedora Core 4 is released, > we will provide updates for Fedora Core 2 and 3. The actual hand-off will > occur when the main Fedora Project drops support for each old > release. Based on the current schedule for Fedora Core, this should give > each release about 1.5 years of update support. Nice. I cut it down even further with you help: Fedora Core releases will follow the so-called "1-2-3 and out" policy in co-operation with Red Hat/Fedora Core. This means that when the Red Hat/Fedora Core group no longer supports a Fedora Core release, Fedora Legacy will pick it up and maintain it for two additional Fedora Core release cycles. Based on the current schedule for Fedora Core releases, this should provide each release with approximately 1.5 years of total update support. In short, Fedora Legacy will provide updates for any Fedora Core releases up to two versions back from the current release. How's that work? > Kelson Vibber > SpeedGate Communications > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From jdaily at progeny.com Fri Jan 16 22:10:32 2004 From: jdaily at progeny.com (John Daily) Date: Fri, 16 Jan 2004 17:10:32 -0500 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: Your message of "Fri, 16 Jan 2004 13:09:28 CST." <200401161309.28932.fedora-legacy@share-foo.com> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> Message-ID: <20040116221607.4FC7863781@morimoto.progeny.com> Earlier, Ray Ferguson wrote: > Technically the sources are GPLed so the provider never has to > have a subscription or SLA of any kind to be entitled to the > source code... However, I agree with you that using these > products reduces the incentive for the companies to continue > releasing and maintaining the products. Personally I'm leaning > heavily towards using Progeny, but if we do so, it will be > under straightforward terms. We will pay for every box that > uses the RPMs even though we will be maintaining our own > repository and could get away with hell. The reason is quite > simple. $60/yr per box is affordable, and if enough people pay > it, Progeny will make money and continue providing the service. What he said. Our intent is to make the Progeny Transition Service attractively priced and reflective of real value to users in the hope that people would choose to do the right thing and pay for what they were going to use. We have included the right to "cut people off" in our subscription agreement, to ensure that we have that option available if there is substantial abuse, but fundamentally, we want to trust in the honesty of the community to pay a fair price for value offered. -- John R. Daily jdaily at progeny.com Director of Technology Progeny Linux Systems Master of the ephemeral epiphany From pearcec at commnav.com Fri Jan 16 22:40:18 2004 From: pearcec at commnav.com (Christian Pearce) Date: Fri, 16 Jan 2004 22:40:18 GMT Subject: Notes from a packager... Message-ID: <35199.209.50.130.84.1074292818.commnav@home.commnav.com> I wanted to put down some thoughts of what I do when I package. I was hoping this helps the documentors. * Identify the vulnerability - Some one posts to the list or you find it yourself * Due dilligence on how to patch - Figure out what others have done. In a lot of cases each package is going to require a different method for getting a backport. In some cases it is a simple one liner. In other cases we might need to find the revision fixed in cvs and run a diff with the revision in the current tar ball. A lot of these needs to be discussed in the lists or on IRC. (Dig back we hashed this out pretty good. ) This link might help with what the backporting policy is. http://www.redhat.com/archives/fedora-legacy-list/2004-January/msg00176.html * Spec files - Figure out the best method for releasing the specs. Some cases you might need to release three spec files. But the idea is to try to combine all the spec files in to one version if possible. * Get some consensus - Verify with the group the approaches are ok. * Do the work on the spec and build patches if need be. * Build - src.rpm * create md5sum - gpg --clearsign it * Post the md5sum file and src.rpm's to a public server * Create a bug @ bugzilla.fedora.com (See existing bugs) - Select - Fedora Meta - Add a Summary - Add a Description -- Sign it, add upstream sources, explain what you did, add links to your src.rpm's and md5sums - Select Component - Package Request Submit - Add keywords - LEGACY, QA, rh72, rh73, rh80 ( Or what distros you need) Hope this helps it is a little choppy. -- Christian Pearce http://www.commnav.com From fedora-legacy at share-foo.com Sat Jan 17 01:24:46 2004 From: fedora-legacy at share-foo.com (Ray Ferguson) Date: Fri, 16 Jan 2004 19:24:46 -0600 Subject: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0] In-Reply-To: <40084EBC.7050408@ysu.edu> References: <20040116200800.12132.49786.Mailman@listman.back-rdu.redhat.com> <40084EBC.7050408@ysu.edu> Message-ID: <200401161924.46202.fedora-legacy@share-foo.com> On Friday 16 January 2004 2:51 pm, John Dalbec wrote: > http://www.redhat.com/solutions/industries/education/indiv/ > > $25/year ($50/year for servers) is not affordable, but $60/year is? > John To the best of my knowledge this did not exist when WBEL was born and apparently it still doesn't help the library that originally sponsored WBEL. Anyway, I'm glad to see that they are doing the right with qualified educational institutions. This still doesn't help me do dev work at home. If I didn't have access to WBEL, I'd have two choices, develop on another platform, or steal. Of course I'd just develop on another platform. Probable Suse since it's IBM and Novell backed and I could eventually deploy it in production. Instead, I develop on WBEL at home and it ports strait to production RHEL with no fuss. In this case RedHat is better off for the existence of WBEL since it is responsible for keeping the proverbial camel's nose out the tent. -ray. From skvidal at phy.duke.edu Sat Jan 17 04:45:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 16 Jan 2004 23:45:36 -0500 Subject: introduction: seth vidal Message-ID: <1074314735.17373.9.camel@binkley> Hi, I couldn't find the form so I'll guess: Name: Seth Vidal Employer: Duke University Job: I'm a sysadmin at duke physics. I also take care of duke's linux-related things. Open source stuff: yum - http://linux.duke.edu/yum/ (It's probably installed on your fc1 machines) metadata - http://linux.duke.edu/metadata/ (hoping to get this installed too ;) some of the treetools - http://dulug.duke.edu/treetools/ other stuff I do: http://fedora.linux.duke.edu/fedorapeople/ <-- fedora developer blogs http://torrent.dulug.duke.edu <-- torrent server http://mirror.dulug.duke.edu <-- commonly used mirror by WAY too many people I'm willing to do stuff to make packages work b/c I have a bunch of people still running 7.3 that I need to make sure stay patched. Ditto with 9 and probably every N release of Fedora Core. Why you should trust me - yum updates a lot of machines so..... gpg key: pub 1024D/69886CC7 2001-09-16 Seth Vidal Key fingerprint = CB55 05F9 8868 0962 DF52 F6A6 D408 F7C7 6988 6CC7 sub 2048g/65B66ED3 2001-09-16 http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x69886CC7 -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Sat Jan 17 05:06:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jan 2004 21:06:46 -0800 Subject: Self-Introduction: Jesse Keating Message-ID: <200401162106.52252.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Name: Jesse Lee Keating Location: Earth, USA, Redmond Washington Profession: Linux Systems Engineer, lifetime student Employeer: Pogo Linux, School: Life Goals: Well, I'm trying to be the leader of this project, to ensure that things get done, and the people that want to keep legacy systems around have a place to get free and highquality security updates. Packages: All that need updating QA: As much as I possibly can Anything Special: Well, taking the heat for being absent the last month or two was pretty "special". Qualifications: MondoRescue: Small amount of development, package maintainer, project director. Fedora Legacy: What I'm doing now! pub 1024D/F13BD4D5 2003-10-08 Jesse Keating (j2Solutions) Key fingerprint = 3ECD F72F 3A73 3C17 6DBA 7CDA E2FD 872E F13B D4D5 sub 2048g/D59486A2 2003-10-08 - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACMLr4v2HLvE71NURAvV9AJ4wKGxDxgNAGh/zsXPbi8ZoyKxgHgCgv7M6 ENC6IiVRC/8622r5IMpqYYs= =A3Z4 -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Sat Jan 17 05:06:06 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 17 Jan 2004 00:06:06 -0500 Subject: bug in mc - midnight commander Message-ID: <1074315966.17373.13.camel@binkley> Hi all, bug in midnight commander. The errata notice from the debian people today. affects 7.2, 7.3 maybe 8.0 - not sure. patched 7.3 mc with it. http://bugzilla.fedora.us/show_bug.cgi?id=1224 there's the bug. QA needed and someone with a 7.2 machine - the patch should work there too. -sv From ms-nospam-0306 at arcor.de Sat Jan 17 09:40:48 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 17 Jan 2004 10:40:48 +0100 Subject: bug in mc - midnight commander In-Reply-To: <1074315966.17373.13.camel@binkley> References: <1074315966.17373.13.camel@binkley> Message-ID: <20040117104048.3076712f.ms-nospam-0306@arcor.de> On Sat, 17 Jan 2004 00:06:06 -0500, seth vidal wrote: > bug in midnight commander. The errata notice from the debian people > today. affects 7.2, 7.3 maybe 8.0 - not sure. > > patched 7.3 mc with it. > http://bugzilla.fedora.us/show_bug.cgi?id=1224 > > there's the bug. > QA needed and someone with a 7.2 machine - the patch should work there > too. Can you get it to crash on rh73? Here, exp.tgz opens fine without any problems. -- From Axel.Thimm at physik.fu-berlin.de Sat Jan 17 09:44:45 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 17 Jan 2004 10:44:45 +0100 Subject: GPL (was: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0]) In-Reply-To: <1074290464.15843.200.camel@chriss2.cait.org> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> <1074283968.15843.49.camel@chriss2.cait.org> <20040116204652.GF15618@neu.nirvana> <1074290464.15843.200.camel@chriss2.cait.org> Message-ID: <20040117094445.GE25951@neu.nirvana> On Fri, Jan 16, 2004 at 04:01:04PM -0600, Chris Spencer wrote: > On Fri, 2004-01-16 at 14:46, Axel Thimm wrote: > > > All true, but the last, if the product is made _publicly_ available, > > like RHEL3, Progeny update services etc. > > It's not _publicly_ available. They only owe source code to those > people that have purchased it. And to any people that have received copies from any of them. Sorry, let me rephrase (I am not a lawyer, and neither speaks me as one ;): If it is _offered_ in _public_, as opposed to doing contract work for instance. Modifying a GPL program for a single company is O.K., offering these modifications to an anonymous customer requires offering the source code to "all third parties". > The people that have done so are free to give that source code away but > they have no promise to subsequent binary releases. > > No law or license says you have to do business with someone. The GPL does in this sense. If you offer GPLed binaries to more than a specific customer, you need to offer source code to everybody asking for it (without interrogating him where he got it, free copying is one of the main aspects of the GPL). > > http://www.gnu.org/licenses/gpl-faq.html > > No where here does it say what you claim. > > In fact it says: > The GPL says that modified versions, if released, must be "licensed ... > to all third parties." Who are these third parties? > > Section 2 says that modified versions you distribute must be licensed to > all third parties under the GPL. "All third parties" means absolutely > everyone--but this does not require you to *do* anything physically for > them. It only means they have a license from you, under the GPL, for > your version. You have at least to commit yourself for three years in writing, that you will ship the source code to anyone interested. So anyone is entitled to the source code. Check http://www.gnu.org/licenses/gpl-faq.html#TOCWhatDoesWrittenOfferValid > What does this "written offer valid for any third party" mean? Does > that mean everyone in the world can get the source to any GPL'ed > program no matter what? > "Valid for any third party" means that anyone who has the offer is > entitled to take you up on it. [...] On Fri, Jan 16, 2004 at 04:01:04PM -0600, Chris Spencer wrote: > Eventually you may have to give the source out but you can legally delay > that process enough to make sure that anyone using updates not obtained > from you are vulnerable for awhile. Yes, you can do all sort of legal tricks, even claiming the GPL is not conforming with the fundamental US laws, or possibly the human rights ;) Let's not go SCO ;) > The point here again is these companies are playing nice and if enough > people erode enough of the money they will stop playing nice. They are > under no obligation, although unlike the entertainment industry they > don't want to harass their customers. > > and again...people that want free updates ought to be contributing to > the process. This is the place to do that. Argeed, but the GPL is the wrong tool to enforce this, it is reversing its purpose of freedom. Accroding to the GPL you need to make the source code available in some adequate channel. Anyway, maybe this is becoming OT and better discussed in presence of GPL experts like the GNU lists. The point is, that the GPL business models work over services, and Red Hat and Progeny have done well with it. Asking for not torpedoing these services/companies is a non-legal issue (nevertheless valid from an economic/moral POV). -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ms-nospam-0306 at arcor.de Sat Jan 17 11:42:35 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 17 Jan 2004 12:42:35 +0100 Subject: GPL (was: [Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0]) In-Reply-To: <20040117094445.GE25951@neu.nirvana> References: <1074275021.7350.0.camel@chip.laiskiainen.org> <20040116180136.GL3353@codegrinder.com> <1074277173.15831.12.camel@chriss2.cait.org> <200401161309.28932.fedora-legacy@share-foo.com> <1074283968.15843.49.camel@chriss2.cait.org> <20040116204652.GF15618@neu.nirvana> <1074290464.15843.200.camel@chriss2.cait.org> <20040117094445.GE25951@neu.nirvana> Message-ID: <20040117124235.2bce3e38.ms-nospam-0306@arcor.de> On Sat, 17 Jan 2004 10:44:45 +0100, Axel Thimm wrote: > On Fri, Jan 16, 2004 at 04:01:04PM -0600, Chris Spencer wrote: > > On Fri, 2004-01-16 at 14:46, Axel Thimm wrote: > > > > > All true, but the last, if the product is made _publicly_ available, > > > like RHEL3, Progeny update services etc. > > > > It's not _publicly_ available. They only owe source code to those > > people that have purchased it. > > And to any people that have received copies from any of them. > > Sorry, let me rephrase (I am not a lawyer, and neither speaks me as > one ;): If it is _offered_ in _public_, as opposed to doing contract > work for instance. Modifying a GPL program for a single company is > O.K., offering these modifications to an anonymous customer requires > offering the source code to "all third parties". Just quote the GPL FAQ to avoid misunderstandings: "Valid for any third party" means that anyone who has the offer is entitled to take you up on it. Note the "who has the offer". If the customer is a loyal one and doesn't pass long the binaries and neither the written offer to receive source code, there's no way for others to get access to the source code. They need the written offer. If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer. The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you. -- From skvidal at phy.duke.edu Sat Jan 17 14:33:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 17 Jan 2004 09:33:51 -0500 Subject: bug in mc - midnight commander In-Reply-To: <20040117104048.3076712f.ms-nospam-0306@arcor.de> References: <1074315966.17373.13.camel@binkley> <20040117104048.3076712f.ms-nospam-0306@arcor.de> Message-ID: <1074350030.17373.15.camel@binkley> On Sat, 2004-01-17 at 04:40, Michael Schwendt wrote: > On Sat, 17 Jan 2004 00:06:06 -0500, seth vidal wrote: > > > bug in midnight commander. The errata notice from the debian people > > today. affects 7.2, 7.3 maybe 8.0 - not sure. > > > > patched 7.3 mc with it. > > http://bugzilla.fedora.us/show_bug.cgi?id=1224 > > > > there's the bug. > > QA needed and someone with a 7.2 machine - the patch should work there > > too. > > Can you get it to crash on rh73? Here, exp.tgz opens fine without > any problems. I did. It crashes consistently on 7.3, 9 and fc1 -sv From lowen at pari.edu Sat Jan 17 14:54:48 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 17 Jan 2004 09:54:48 -0500 Subject: Self introduction: Lamar Owen Message-ID: <200401170954.48240.lowen@pari.edu> [Since everyone else seems to be doing this, I'll go along....Just, if you reply to this message for some subtopic of the message PLEASE CHANGE THE SUBJECT (there have already be a handful of threads that discuss substantial technical issues that are threaded 'Re: Self Introduction.....'). This is a repost of my introduction to Fedora-Devel, with minor edits.] While I have been contributing to Red Hat's development (through maintenance of the PostgreSQL RPMset) for some years now, I'll go ahead with the self intro as requested on the fedora.us site. Lamar Randall Owen USA, Rosman, NC Director of Information Technology Pisgah Astonomical Research Institute I currently maintain the community packages for PostgreSQL, as well as building packages for other programs, including the SWORD project and BibleTime (Bible software for KDE using the SWORD libraries and modules). While I do some QA testing now, I am mostly interested in making the Fedora PostgreSQL packages the best they can be. For Fedora Legacy, I should note that my community packages for the latest PostgreSQL are routinely being built on Red Hat 6.2, 7.3, 8.0, 9, AS2.1, and RHEL3, as well as FC1. The latest RPM isn't yet available for RHL9 due to lack of a build host, and I am in process of building it on RHL8.0. I distribute binaries for all of those, as well as Aurora 1.0, a SPARCed RHL 7.3. Upgrading to the latest and greatest from previous versions can be mighty painful; however, if a security issue occurs in the versions distributed with the EOLd distribution, backporting security fixes to more than one major previous version is not going to be priority for the PostgreSQL core developers. Red Hat 6.2, for instance, shipped with PostgreSQL 6.5.3. This is a positively archaic version of PostgreSQL, with the current version being 7.4.1. Versions prior to 7.3.5 are not likely to be supported upstream at all; the EOLd distributions are all prior to that. Since AS 2.1 is still supported, source RPMs for it could be rebuilt on at least RHL 7.3, and maybe even 8.0. RHEL3 source RPM errata could be rebuilt on RHL9 without much problem. Historical Qualifications. Over four years maintaining the PostgreSQL RPMs and contributing to discussions there and on the RPM list. I've beta tested Red Hat for right at four years, since the 6.2 cycle. I have programmed in numerous languages over the years: see my sourceforge profile (user lowen). I maintain the postgresql database driver for the AOLserver project. Red Hat trusts me (Red Hat 6.1 shipped with rebuilt versions of my PostgreSQL packages, and they have been the base packages ever since, even though RH has their own internal maintainer (currently Tom Lane, previously David Jee and before that Andrew Overholt, and before him Trond Eivind Glomsr?d)), so I guess you should too. :-) Key fingerprint (fresh key, as I've not used one before for public consumption (except in my post to Fedora Devel)): pub 1024D/25C6AF5B 2003-12-04 Lamar Owen Key fingerprint = 3142 7AB1 F9AA 5D14 BBB3 FC4A 073D 25BA 25C6 AF5B sub 2048g/C1F9E9DA 2003-12-04 I guess I'll begin signing the PostgreSQL RPM's at ftp.postgresql.org; they haven't previously been signed. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From mail at jonaspasche.de Sat Jan 17 20:55:16 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Sat, 17 Jan 2004 21:55:16 +0100 Subject: Notes from a packager... In-Reply-To: <35199.209.50.130.84.1074292818.commnav@home.commnav.com> References: <35199.209.50.130.84.1074292818.commnav@home.commnav.com> Message-ID: <1074372915.3695.199.camel@leonardo> Hi Christian, > I wanted to put down some thoughts of what I do when I package. I was > hoping this helps the documentors. Definitely, thanks for your work. I'll try to divide this into smaller sub-jobs which could actually be done by different people, so we can have a good link to the "Participate" section to answer the ultimate question "I want to help - what exactly can I do?". I'll post a draft of this in a few days - actually it's weekend; time for a social life. ;-) Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Mon Jan 19 01:41:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Jan 2004 17:41:55 -0800 Subject: mc packages need QA Message-ID: <200401181741.56506.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is a set of mc packages for 7.2, 7.3, and 8.0 that need QA so that we can publish them ASAP. Small flaw, but I'd like to see it fixed and published to show that we are capable of doing something. https://bugzilla.fedora.us/show_bug.cgi?id=1224 - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACzXj4v2HLvE71NURAhVNAJ4yNIFyvotvLcMQXnKdod/kHOAKSACdGWVk FrQ5AntWpdfbZBqX5L2ouEE= =SyRt -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 03:09:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Jan 2004 19:09:24 -0800 Subject: clearsigned bugzilla entries Message-ID: <200401181909.25216.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, whats a good way to make sure that the clearsigned bugzilla entries will check out once posted. I made one post, then tried to verify my sig and I get a bad sig. Is it because of the line feeds? what should I do here? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAC0pk4v2HLvE71NURAgxTAKCxgdqeQIFlOVIOblFGrv8HVqUyigCfakOn TIa2EkDzOhDVf32J+qIR0+w= =EmSc -----END PGP SIGNATURE----- From arvand at sbcglobal.net Mon Jan 19 03:19:02 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Sun, 18 Jan 2004 19:19:02 -0800 Subject: mc packages need QA In-Reply-To: <200401181741.56506.jkeating@j2solutions.net> Message-ID: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> Hello, I noticed that a lot of packages are being put out however some are not being tested (QAed?). This is probably the reason they are not being published even a week after they are created. My question is that do you think it is possible to run VMware (http://www.vmware.com/) and install RH 7.3/8.0/9.0 then test the packages using this? Or would the testing not be accurate as it is being done in VMWare? Also, how thorough of a testing do you require? I realize vulnerability and functionality tests are a must but I sometimes don't even understand the vulnerability rather than test it. So on some packages I would only be able to tell if they install fine and whether they work or not. Regards, Arvand Sabetian -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of Jesse Keating Sent: Sunday, January 18, 2004 5:42 PM To: fedora-legacy-list at redhat.com Subject: mc packages need QA -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is a set of mc packages for 7.2, 7.3, and 8.0 that need QA so that we can publish them ASAP. Small flaw, but I'd like to see it fixed and published to show that we are capable of doing something. https://bugzilla.fedora.us/show_bug.cgi?id=1224 - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACzXj4v2HLvE71NURAhVNAJ4yNIFyvotvLcMQXnKdod/kHOAKSACdGWVk FrQ5AntWpdfbZBqX5L2ouEE= =SyRt -----END PGP SIGNATURE----- -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Mon Jan 19 05:29:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Jan 2004 21:29:42 -0800 Subject: mc packages need QA In-Reply-To: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> References: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> Message-ID: <200401182129.43716.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 18 January 2004 19:19, Arvand Sabetian wrote: > Hello, > > I noticed that a lot of packages are being put out however some are not > being tested (QAed?). This is probably the reason they are not being > published even a week after they are created. My question is that do you > think it is possible to run VMware (http://www.vmware.com/) and install > RH 7.3/8.0/9.0 then test the packages using this? Or would the testing > not be accurate as it is being done in VMWare? Vmware is a perfect tool for this. If I did not have a seperate machine for which to do my work, I'd use vmware. > Also, how thorough of a testing do you require? I realize vulnerability > and functionality tests are a must but I sometimes don't even understand > the vulnerability rather than test it. So on some packages I would only > be able to tell if they install fine and whether they work or not. http://www.fedora.us/wiki/PackageSubmissionQAPolicy Run through that, with the idea that the package has already been published, we're just adding a little bit to it. Disregard most the stuff about spec file changes, as we are trying to modify as little as possible. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAC2tG4v2HLvE71NURAhE2AJ9jYZFMrXDiV7hoJ4s0waveTzIPegCZAdlp aaSmyKHH7vMSfSNLKAEp08A= =Ty8N -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Mon Jan 19 06:50:54 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 19 Jan 2004 07:50:54 +0100 Subject: mc packages need QA In-Reply-To: <200401182129.43716.jkeating@j2solutions.net> References: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> <200401182129.43716.jkeating@j2solutions.net> Message-ID: <20040119075054.773c17d2.ms-nospam-0306@arcor.de> On Sun, 18 Jan 2004 21:29:42 -0800, Jesse Keating wrote: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > Run through that, with the idea that the package has already been > published, we're just adding a little bit to it. Disregard most the stuff > about spec file changes, as we are trying to modify as little as possible. This is going into a wrong direction. Don't reinvent the wheel. That will result in learning from mistakes painfully. The build-system strictly requires a complete set of build requirements. Else the builds will fail, and that will slow down the release of updates. My advice: take the original spec file, and for the first legacy update, fix it where necessary and where it seems reasonable (small adjustments like "Copyright -> License" or an updated URL don't hurt anyone unless the packager starts to rearrange the order of lines in the spec). Don't change the indendation or regroup fields. A diff against the previous release should stay straight-forward and readable. But do add missing build requirements and fix obvious package bugs. Right now the "mc" update ticket contains src.rpms which don't build due to terribly incomplete build requirements. For example, on rh73 with the 6.legacy package you'll get: [...] /usr/bin/ld: cannot find -ldb1 collect2: ld returned 1 exit status make[3]: *** [plain-gmc] Error 1 [...] Missing buildrequires db1-devel, at least. Skimming over the build log, also missing seem to be "gettext, slang-devel, e2fsprogs-devel, pam-devel", probably more, and that check took me only a minute (?) after the test-build failed. It took longer to write this message. "Buildrequires: slang" is wrong and a slip on Red Hat's part. Further, potential missing buildrequires are ncurses-devel and libtermcap-devel (didn't look a 2nd time) based on what "rpm -qR mc" of Red Hat's binary rpm returns. -- From jkeating at j2solutions.net Mon Jan 19 07:14:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Jan 2004 23:14:56 -0800 Subject: mc packages need QA In-Reply-To: <20040119075054.773c17d2.ms-nospam-0306@arcor.de> References: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> <200401182129.43716.jkeating@j2solutions.net> <20040119075054.773c17d2.ms-nospam-0306@arcor.de> Message-ID: <200401182314.58136.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 18 January 2004 22:50, Michael Schwendt wrote: > My advice: take the original spec file, and for the first legacy update, > fix it where necessary and where it seems reasonable (small adjustments > like "Copyright -> License" or an updated URL don't hurt anyone unless > the packager starts to rearrange the order of lines in the spec). Don't > change the indendation or regroup fields. A diff against the previous > release should stay straight-forward and readable. But do add missing > build requirements and fix obvious package bugs. > > Right now the "mc" update ticket contains src.rpms which don't build due > to terribly incomplete build requirements. For example, on rh73 with the > 6.legacy package you'll get: > > [...] > /usr/bin/ld: cannot find -ldb1 > collect2: ld returned 1 exit status > make[3]: *** [plain-gmc] Error 1 > [...] > > Missing buildrequires db1-devel, at least. Skimming over the build log, > also missing seem to be "gettext, slang-devel, e2fsprogs-devel, > pam-devel", probably more, and that check took me only a minute (?) > after the test-build failed. It took longer to write this > message. "Buildrequires: slang" is wrong and a slip on Red Hat's > part. Further, potential missing buildrequires are ncurses-devel and > libtermcap-devel (didn't look a 2nd time) based on what "rpm -qR mc" of > Red Hat's binary rpm returns. Sound advice. I'm sure a lot of these would have been caught by a proper build system. Unfortunately ours isn't "proper" yet. Could you please add your comments to the bugzilla system? If it's a blocker, then I'll re-roll the packages. If we can go forward and fix in the future, I'd rather get the update out and published. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAC4Pw4v2HLvE71NURAo8PAJwOEPfQ0QScV+XnKprZ1q0KXH2lCQCfbFcE aPN1euqo/S3Fp2cQi5p6IyY= =UsiR -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 08:18:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 00:18:33 -0800 Subject: Legacy mirror structure Message-ID: <200401190018.35186.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My proposal is to run a master mirror server for FL. An ISP has offered rackspace and bandwidth for such a beast. The layout I envision is this: download.fedoralegacy.org/legacy/$releasever/SRPMS/ download.fedoralegacy.org/legacy/$releasever/SRPMS//base download.fedoralegacy.org/legacy/$releasever/SRPMS/updates download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons download.fedoralegacy.org/legacy/$releasever/$basearch/base download.fedoralegacy.org/legacy/$releasever/$basearch/updates download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons where each subdir of $basearch has a directory RPMS, and a symlink SRPMS, which points to the correct ../../SRPMS/foo dir. Given the 7.3 release, i386 arch, and the "updates" dir we would have: download.fedoralegacy.org/legacy/7.3/i386/updates/RPMS download.fedoralegacy.org/legacy/7.3/i386/updates/SRPMS->../../SRPMS/updates base, updates, and legacy-addons would each be a metadata top-level, so a yum.conf file would look like: [base] name=Red Hat Linux $releasever base baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/base gpgcheck=1 [updates] name=Red Hat Linux $releasever updates baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/updates gpgcheck=1 #[updates-testing] #name=Red Hat Linux $releasever updates-testing #baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/updates-testing #gpgcheck=1 [legacy-addons] name=Fedora Legacy tools for Red Hat Linux $releasever baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons gpgcheck=1 Same would be for the apt stuff I would assume, although I'm not familiar with apt setup. I'm thinking of this from the unified metadata structure mindset, not apt or yum specific. Each tree would be rsyncable, suggested rsync point would be the $releasever directory. Sites like fedora.us that have a current setup already in place can choose to sync specific directories. All mirrors should provide fedoralegacy.org the correct yum/apt conf settings specific to their mirror. Thoughts? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAC5LZ4v2HLvE71NURAl/4AKCLX3M2AMyM2j7iScv1JQnyn1ym0ACeIP/Z fbYtH0nrEILC/lIFeOgeDDU= =Wvwt -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 09:04:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 01:04:33 -0800 Subject: Publishing Policy Message-ID: <200401190104.34706.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As we get closer to pushing out our first round of updates, we need to (re)visit our publishing policy. Warren had persuaded me to agree with him that an extra level of testing needs to happen prior to a public release. Currently the process in full is: 1) file a bug with packages fixing a certain flaw 2) QA the package for source aspects and general build issues 3) push the package into updates-testing once two people give "PUBLISH" votes. 4) once in updates-testing, one test of package in full production is enough to release the package into testing. The whole "updates-testing" thing is the new wrinkle that Warren talked to me about. What I'm struggling with is how to handle the -testing aspects. A) Is the updates-testing package signed, and if so, with what key? B) How is the package announced? C) How can we verify that the tester is really testing the package? D) Since we release the package across multiple releases, how long do we wait on a specific release to be tested before releasing the rest of the packages? Please comment. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAC52h4v2HLvE71NURAovDAJ9sbVHvWaZTM4KAQziLYv6oPWmtBACfUl/L XPj/knIX/HOz+OJ3zAzL3OY= =u6Jw -----END PGP SIGNATURE----- From warren at togami.com Mon Jan 19 09:28:39 2004 From: warren at togami.com (Warren Togami) Date: Sun, 18 Jan 2004 23:28:39 -1000 Subject: Publishing Policy In-Reply-To: <200401190104.34706.jkeating@j2solutions.net> References: <200401190104.34706.jkeating@j2solutions.net> Message-ID: <400BA347.7060302@togami.com> Jesse Keating wrote: > As we get closer to pushing out our first round of updates, we need to > (re)visit our publishing policy. > > Warren had persuaded me to agree with him that an extra level of testing > needs to happen prior to a public release. Currently the process in full > is: > > 1) file a bug with packages fixing a certain flaw > 2) QA the package for source aspects and general build issues > 3) push the package into updates-testing once two people give "PUBLISH" > votes. > 4) once in updates-testing, one test of package in full production is > enough to release the package into testing. We must be able to use our discretion, and do MORE testing on all distributions especially for the important packages. This probably means get GPG clearsigned "name-version-release works for me on RH7.3 after 1 hour of functionality testing. I also verified that the binary ldd output matches RH's package" from multiple people for packages like screen, but if apache needs upgrading even more feedback should be submitted since it is such a complex and important package. Another good test is using ldd and compare the output of the binaries in RH's package and Legacy's package. It is entirely possible that Legacy's binary in updates-testing could be missing functionality since BuildRequires are missing. http://www.fedora.us/pipermail/fedora-devel/2004-January/002526.html "Careful - Missing BuildRequires for Reproducibility" Read this thread for details about the many missing BuildRequires in many RH packages. Multiple packages currently in LEGACY QA have this problem and need to be fixed. http://www.fedora.us/wiki/PendingRepository fedora.us QA pending channel detailed on this page serves a similar need to Legacy's updates-testing channel, but fedora.us never had this particular problem of missing BuildRequires since we were strict on BuildRequires requirements from the beginning. > > The whole "updates-testing" thing is the new wrinkle that Warren talked to > me about. What I'm struggling with is how to handle the -testing aspects. > > A) Is the updates-testing package signed, and if so, with what key? FedoraLegacy.org eventually, when the build server is in production. > B) How is the package announced? Has the template been finalized? Perhaps consider using sha1sum instead of md5sum since it is less susceptible to the birthday attack? > C) How can we verify that the tester is really testing the package? That is why multiple testers are needed. One of the testers should be the packager of course. People that have submitted good testing results and especially found ERRORS in the past are to be trusted more than new people. > D) Since we release the package across multiple releases, how long do we > wait on a specific release to be tested before releasing the rest of the > packages? > Use best judgement. Wait for enough clearsigned feedback based upon the importance of a package to avoid regressions. Something like apache would need far more testing than something like screen. But NEVER push it too soon. Warren From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 19 11:11:50 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 19 Jan 2004 12:11:50 +0100 Subject: Legacy mirror structure In-Reply-To: <200401190018.35186.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: <20040119121150.573a81e5@python.freshrpms.net> Jesse Keating wrote : > My proposal is to run a master mirror server for FL. An ISP has offered > rackspace and bandwidth for such a beast. The layout I envision is this: > > download.fedoralegacy.org/legacy/$releasever/SRPMS/ > download.fedoralegacy.org/legacy/$releasever/SRPMS//base > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons > download.fedoralegacy.org/legacy/$releasever/$basearch/base > download.fedoralegacy.org/legacy/$releasever/$basearch/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons I guess there is a typo for SRPMS/updates-testing where s/SRPMS/$basearch/. > where each subdir of $basearch has a directory RPMS, and a symlink SRPMS, > which points to the correct ../../SRPMS/foo dir. Given the 7.3 release, > i386 arch, and the "updates" dir we would have: > > download.fedoralegacy.org/legacy/7.3/i386/updates/RPMS > download.fedoralegacy.org/legacy/7.3/i386/updates/SRPMS->../../SRPMS/upd > ates Are these SRPMS symlinks really useful? Why not this instead : $releasever/{base,updates,..}/{$basearch,SRPMS}/*.rpm Just a thought. [...] > Thoughts? Yes, one more important one : As it is planned to support at least some Fedora Core releases later on, the information about "redhat" vs. "fedora" should appear somewhere, otherwise there will clearly be a scalability problem once Fedora Core 9 needs to be supported ;-) I'd suggest : /legacy/{redhat,fedora}/$releasever/... Also, for the ftp/rsync accessible structure, having the leading /legacy/ part of the path is a good thing (as /pub/legacy for ftp and as a "legacy" rsync module for instance), but for http it's quite redundant with the virtual host name, and could be removed for purely cosmetic and line length considerations. In the end, my final suggestion would be : http://download.fedoralegacy.org/redhat/$releasever/base/$basearch http://download.fedoralegacy.org/redhat/$releasever/base/SRPMS http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch http://download.fedoralegacy.org/redhat/$releasever/updates-testing/$basearch http://download.fedoralegacy.org/redhat/$releasever/updates-testing/SRPMS http://download.fedoralegacy.org/redhat/$releasever/legacy-addons/$basearch http://download.fedoralegacy.org/redhat/$releasever/legacy-addons/SRPMS With "redhat" substituted for "fedora" when the time will come. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2154.nptl Load : 0.08 0.12 0.32 From dennis at ausil.us Mon Jan 19 11:17:28 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Jan 2004 21:17:28 +1000 Subject: Legacy mirror structure In-Reply-To: <200401190018.35186.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: <200401192117.41083.dennis@ausil.us> Once upon a time Monday 19 January 2004 6:18 pm, Jesse Keating wrote: > My proposal is to run a master mirror server for FL. An ISP has offered > rackspace and bandwidth for such a beast. The layout I envision is this: > > download.fedoralegacy.org/legacy/$releasever/SRPMS/ > download.fedoralegacy.org/legacy/$releasever/SRPMS//base > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons > download.fedoralegacy.org/legacy/$releasever/$basearch/base > download.fedoralegacy.org/legacy/$releasever/$basearch/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons can i sugest going with a common format used my most mirrors that way what is on the fedoralegacy server will match that of the mirrors. I plan on having a mirror of Legacy if the deal with the hosting company i have been dealing with works out. download.fedoralegacy.org/pub/fedoralegacy/$releasever/SRPMS/ download.fedoralegacy.org/lpub/fedoraegacy/$releasever/SRPMS//base download.fedoralegacy.org/pub/fedoralegacy/$releasever/SRPMS/updates download.fedoralegacy.org/pub/fedoralegacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/pub/fedoralegacy/$releasever/SRPMS/legacy-addons download.fedoralegacy.org/pub/fedoralegacy/$releasever/RPMS/$basearch/base download.fedoralegacy.org/pub/fedoralegacy/$releasever/RPMS/$basearch/updates download.fedoralegacy.org/pub/fedoralegacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/pub/fedoralegacy/$releasever/RPMS/$basearch/legacy-addons > where each subdir of $basearch has a directory RPMS, and a symlink SRPMS, > which points to the correct ../../SRPMS/foo dir. Given the 7.3 release, > i386 arch, and the "updates" dir we would have: I wouldnt worry about the symlink to SRPMS but would put in the RPMS dir then break down to archs for example download.fedoralegacy.org/pub/fedoralegacy/7.3/RPMS/i386/legacy-addons download.fedoralegacy.org/pub/fedoralegacy/7.3/RPMS/ppc/legacy-addons download.fedoralegacy.org/pub/fedoralegacy/7.3/SRPMS/legacy-addons > download.fedoralegacy.org/legacy/7.3/i386/updates/RPMS > download.fedoralegacy.org/legacy/7.3/i386/updates/SRPMS->../../SRPMS/update >s > > base, updates, and legacy-addons would each be a metadata top-level, so a > yum.conf file would look like: > > [base] > name=Red Hat Linux $releasever base > baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/base > gpgcheck=1 for example [base] name=Red Hat Linux $releasever base baseurl=http://download.fedoralegacy.org/pub/fedoralegacy/$releasever/RPMS/$basearch/base gpgcheck=1 to set for a mirror [base] name=Red Hat Linux $releasever base baseurl=http://somemirror.org/pub/fedoralegacy/$releasever/RPMS/$basearch/base gpgcheck=1 > [updates] > name=Red Hat Linux $releasever updates > baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/updat >es gpgcheck=1 > > #[updates-testing] > #name=Red Hat Linux $releasever updates-testing > #baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/upda >tes-testing #gpgcheck=1 > > [legacy-addons] > name=Fedora Legacy tools for Red Hat Linux $releasever > baseurl=http://download.fedoralegacy.org/legacy/$releasever/$basearch/legac >y-addons gpgcheck=1 > > Same would be for the apt stuff I would assume, although I'm not familiar > with apt setup. I'm thinking of this from the unified metadata structure > mindset, not apt or yum specific. > > Each tree would be rsyncable, suggested rsync point would be the > $releasever directory. Sites like fedora.us that have a current setup > already in place can choose to sync specific directories. All mirrors > should provide fedoralegacy.org the correct yum/apt conf settings specific > to their mirror. > > Thoughts? if we get the structure set right on our server then the user should only need to swap in the name of the mirror server. the way redhat has set things for there download makes it a little bit harder for users to easily config yum and apt to use a mirror server. fedora.us is the same the whole /fedora/fedora thing is strange it should be /pub/fedora but it is a good start. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dennis at ausil.us Mon Jan 19 11:23:09 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Jan 2004 21:23:09 +1000 Subject: Legacy mirror structure In-Reply-To: <20040119121150.573a81e5@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040119121150.573a81e5@python.freshrpms.net> Message-ID: <200401192123.09314.dennis@ausil.us> Once upon a time Monday 19 January 2004 9:11 pm, Matthias Saou wrote: > Jesse Keating wrote : > > My proposal is to run a master mirror server for FL. An ISP has offered > > rackspace and bandwidth for such a beast. The layout I envision is this: > Are these SRPMS symlinks really useful? Why not this instead : > $releasever/{base,updates,..}/{$basearch,SRPMS}/*.rpm > Just a thought. > > [...] > > > Thoughts? > > Yes, one more important one : As it is planned to support at least some > Fedora Core releases later on, the information about "redhat" vs. "fedora" > should appear somewhere, otherwise there will clearly be a scalability > problem once Fedora Core 9 needs to be supported ;-) I'd suggest : > > /legacy/{redhat,fedora}/$releasever/... perhaps go with numbers for Red Hat but use a leading FC for fedoracore /pub/fedoralegacy/FC1/ /pub/fedoralegacy/7.3/ > Also, for the ftp/rsync accessible structure, having the leading /legacy/ > part of the path is a good thing (as /pub/legacy for ftp and as a "legacy" > rsync module for instance), but for http it's quite redundant with the > virtual host name, and could be removed for purely cosmetic and line length > considerations. I really think that just using legacy will make it hard to distingush what its for on mirrors what if some mandrake legacy project starts up users may be confused. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Mon Jan 19 11:40:49 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 19 Jan 2004 03:40:49 -0800 (PST) Subject: Legacy mirror structure In-Reply-To: <200401190018.35186.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: > My proposal is to run a master mirror server for FL. An ISP has offered > rackspace and bandwidth for such a beast. The layout I envision is > this: > > download.fedoralegacy.org/legacy/$releasever/SRPMS/ > download.fedoralegacy.org/legacy/$releasever/SRPMS//base > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons > download.fedoralegacy.org/legacy/$releasever/$basearch/base > download.fedoralegacy.org/legacy/$releasever/$basearch/updates > download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing > download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons I'd be interested to see us include lingual and architecture support in those paths. Recall that the redhat storage paths are: $releasever/en/os/$arch I think they make a great deal of sense, and will prevent us from having to play "two-path-monte" or create ugly symbolic link farms if we need to make changes later. > Thoughts? Thoughts? -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From warren at togami.com Mon Jan 19 12:41:47 2004 From: warren at togami.com (Warren Togami) Date: Mon, 19 Jan 2004 02:41:47 -1000 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: <400BD08B.2060407@togami.com> Chuck Wolber wrote: > >>My proposal is to run a master mirror server for FL. An ISP has offered >>rackspace and bandwidth for such a beast. The layout I envision is >>this: >> >>download.fedoralegacy.org/legacy/$releasever/SRPMS/ >>download.fedoralegacy.org/legacy/$releasever/SRPMS//base >>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates >>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing >>download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons >>download.fedoralegacy.org/legacy/$releasever/$basearch/base >>download.fedoralegacy.org/legacy/$releasever/$basearch/updates >>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing >>download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons > > > I'd be interested to see us include lingual and architecture support in > those paths. Recall that the redhat storage paths are: > > $releasever/en/os/$arch > > I think they make a great deal of sense, and will prevent us from having > to play "two-path-monte" or create ugly symbolic link farms if we need to > make changes later. > > ==================================================== The following are my personal recommendations regarding the mirror structure. IMHO, since long time ago RH merged all languages into a single distribution, I highly doubt we will go back to having multiple distributions for different languages. The earlier 7.x supported by Legacy is only a special case. For this reason I would suggest not using a language directory. Keep one layer of complexity out. arch directory does make sense though. I am surprised they are missing from your original proposal you were the one that suggested arch i386 and x86_64 in IRC. =) I am in agreement with previous posters in suggesting making the basedir "fedoralegacy" rather than just "legacy". This makes things more clear for mirror maintainers. I would highly suggest going through at least another day of discussion and consensus for the mirror structure, since this is IMPORTANT. You need to live with it forever. One note about when you write the Fedora Legacy mirror HOWTO document. Make sure that your package timestamps match exactly RH's main mirror, and make sure that mirrors use rsync option "-a" which will preserve timestamps among several other wanted options. This should allow mirror admins to use the hardlink tool (contained in the legacy-addons channel) to consolidate tons of space with their existing redhat and fedora.redhat.com mirrors. I would suggest NOT holding the base SRPMS within the mirror tree on the Legacy master mirror. Just keep the directory empty. They are almost totally never needed, and if a developer really does need it, they can get it easily enough from any of the thousand existing RH/Fedora mirrors. I am intrigued by the channel name "legacy-addons" rather than "legacy" currently used by fedora.us. It would be a little confusing to have both names exist. I suppose I could rename the channels on fedora.us, but unfortunately all existing users pointing there will need to upgrade their yum or edit their configurations. I do admit however that "legacy-addons" is less ambiguous and very clear that it contains only add-ons, while "updates" does not. Thus I am thinking this is a good idea. Sorry existing users... but read below, since I am thinking to soon remove 7.2 and 7.3 completely from download.fedora.us for reasons of redundancy. ============== Just to clarify about why download.fedora.us is maintaining a separate mirror structure from fedoralegacy.org. Below outlines my thoughts for future maintenance and distribution of fedora.us, and how it will continue to operate after FC2 when the Extras development and repositories are moved to fedora.redhat.com. 1) fedoralegacy.org's own mirror structure allows a separation of governace, security, build system, and responsibility of sysadmin duties. (Community no longer needs to rely on Warren. Warren does not go insane.) 2) I plan on automatically rsyncing legacy's updates and legacy-addons channel into the appropriate directories of download.fedora.us. This will allow existing fedora.us users to continue to get updates from repositories they had been using since 9 months ago for RH8, RH9 and FC1. Other existing repositories with an "updates" channel like freshrpms.net could do the same from legacy's "updates" and continue to serve existing users in a similar manner. Existing users need only import the new FEDORA-LEGACY-GPG-KEY. 3) It is true that download.fedora.us 7.2 and 7.3 will be completely redundant to fedoralegacy.org's 7.2 and 7.3 since fedora.us never did make add-on packages for 7.x. For this reason I am thinking to simply remove the 7.2 and 7.3 trees from download.fedora.us. I'm hurting for space anyhow... 4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in the Extras channels stable/testing/unstable for users who wish to use them, while continuing to benefit from "updates" which are copied from legacy. fedora.us will indefinitely maintain security updates for RH8, RH9, FC1 Extras within the existing download.fedora.us tree, with the help of the Legacy team. 5) download.fedora.us will no longer be needed by FC2, since Extras will be moved to fedora.redhat.com. Then fedoralegacy.org will continue to handle "updates" for each distribution in their own mirror structure. 6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. Thus fedoralegacy.org may need to add an "updates-extras" channel in order to serve security updates to FC2's Extras. We will not need to discuss this until sometime during 2005 though. 7) fedoralegacy.org can continue to use bugzilla.fedora.us. That instance of Bugzilla is now being maintained professionally and should remain stable as a result. New products/components can be added to the Bugzilla to uniquely support Legacy development. 8) fedoralegacy.org should eventually fork their documentation into their own Wiki for draft & editing purposes while policies are discussed and agreed upon. Then maybe later docbook XML for nicely formatted finalized documents. This policy & process documentation writing is another job needed for fedoralegacy.org, and another chance for volunteers to contribute. Comments? Questions? Please reply to both lists as this impacts both of our projects in the future. Warren Togami warren at togami.com From dennis at ausil.us Mon Jan 19 13:30:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Jan 2004 23:30:40 +1000 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <400BD08B.2060407@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> Message-ID: <200401192330.45813.dennis@ausil.us> Once upon a time Monday 19 January 2004 10:41 pm, Warren Togami wrote: > IMHO, since long time ago RH merged all languages into a single > distribution, I highly doubt we will go back to having multiple > distributions for different languages. The earlier 7.x supported by > Legacy is only a special case. For this reason I would suggest not > using a language directory. Keep one layer of complexity out. Totally agree the language doesnt make any sense. > arch directory does make sense though. I am surprised they are missing > from your original proposal you were the one that suggested arch i386 > and x86_64 in IRC. =) there should definetly be arch in RPMS all arches should be built from the same SRPM right? > I am in agreement with previous posters in suggesting making the basedir > "fedoralegacy" rather than just "legacy". This makes things more clear > for mirror maintainers. > > I would highly suggest going through at least another day of discussion > and consensus for the mirror structure, since this is IMPORTANT. You > need to live with it forever. it needs to be right first time we need agreement on structure that we can live with. as Warren said it is very IMPORTANT > One note about when you write the Fedora Legacy mirror HOWTO document. > Make sure that your package timestamps match exactly RH's main mirror, > and make sure that mirrors use rsync option "-a" which will preserve > timestamps among several other wanted options. This should allow mirror > admins to use the hardlink tool (contained in the legacy-addons channel) > to consolidate tons of space with their existing redhat and > fedora.redhat.com mirrors. > > I would suggest NOT holding the base SRPMS within the mirror tree on the > Legacy master mirror. Just keep the directory empty. They are almost > totally never needed, and if a developer really does need it, they can > get it easily enough from any of the thousand existing RH/Fedora mirrors. > > I am intrigued by the channel name "legacy-addons" rather than "legacy" > currently used by fedora.us. It would be a little confusing to have > both names exist. I suppose I could rename the channels on fedora.us, > but unfortunately all existing users pointing there will need to upgrade > their yum or edit their configurations. could we symlink legacy to legacy-addons on fedora.us for a short period with an updated yum package pointing to the new location perhaps a future feature for yum would be to detect 301 errors and adjust its config to suit. i like thats it creates the clearness legacy kind of implies that they are updated packages > 2) I plan on automatically rsyncing legacy's updates and legacy-addons > channel into the appropriate directories of download.fedora.us. This > will allow existing fedora.us users to continue to get updates from > repositories they had been using since 9 months ago for RH8, RH9 and > FC1. Other existing repositories with an "updates" channel like > freshrpms.net could do the same from legacy's "updates" and continue to > serve existing users in a similar manner. > Existing users need only import the new FEDORA-LEGACY-GPG-KEY. i like this idea alot. the end users should see as minimal change as possible. > 3) It is true that download.fedora.us 7.2 and 7.3 will be completely > redundant to fedoralegacy.org's 7.2 and 7.3 since fedora.us never did > make add-on packages for 7.x. For this reason I am thinking to simply > remove the 7.2 and 7.3 trees from download.fedora.us. I'm hurting for > space anyhow... I think it would be fine to remove the trees i was supprised when you put them up. > 4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in > the Extras channels stable/testing/unstable for users who wish to use > them, while continuing to benefit from "updates" which are copied from > legacy. fedora.us will indefinitely maintain security updates for RH8, > RH9, FC1 Extras within the existing download.fedora.us tree, with the > help of the Legacy team. Very nice i think at this point fedora.us should cease to release new RH8.0 packages as it is EOL. it should however provide security updates for existing fedora.us packages. > 5) download.fedora.us will no longer be needed by FC2, since Extras will > be moved to fedora.redhat.com. Then fedoralegacy.org will continue to > handle "updates" for each distribution in their own mirror structure. > > 6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. > Thus fedoralegacy.org may need to add an "updates-extras" channel in > order to serve security updates to FC2's Extras. We will not need to > discuss this until sometime during 2005 though. perhaps should the fedora.us tree be considered extras for RH8.0 RH9 and FC1? and moved to fedoralegacy.org when product is EOL? > 7) fedoralegacy.org can continue to use bugzilla.fedora.us. That > instance of Bugzilla is now being maintained professionally and should > remain stable as a result. New products/components can be added to the > Bugzilla to uniquely support Legacy development. as part of the fedoralegacy.org identity i think we should have our own bugzilla and wiki > 8) fedoralegacy.org should eventually fork their documentation into > their own Wiki for draft & editing purposes while policies are discussed > and agreed upon. Then maybe later docbook XML for nicely formatted > finalized documents. This policy & process documentation writing is > another job needed for fedoralegacy.org, and another chance for > volunteers to contribute. this should be a must. we should even look at versioning of policies similiar to how debian do it so that updated packages can easily be moved to newer versions via a changelog process. and we know exactly what standard the package was written against for instance we have a policy change all pending QA packages would need to start over as they wouldnt meet current statndard but if they meet standard 1.3 there ok next update they can move to 1.4 > Comments? Questions? Please reply to both lists as this impacts both > of our projects in the future. > > Warren Togami > warren at togami.com > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Mon Jan 19 13:52:56 2004 From: warren at togami.com (Warren Togami) Date: Mon, 19 Jan 2004 03:52:56 -1000 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <200401192330.45813.dennis@ausil.us> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> <200401192330.45813.dennis@ausil.us> Message-ID: <400BE138.2030500@togami.com> Dennis Gilmore wrote: > could we symlink legacy to legacy-addons on fedora.us for a short period with > an updated yum package pointing to the new location perhaps a future feature > for yum would be to detect 301 errors and adjust its config to suit. An interesting idea that I haven't heard before, but unfortunately I doubt this is feasible. I can think of several ways to potentially abuse this too... > > >>5) download.fedora.us will no longer be needed by FC2, since Extras will >>be moved to fedora.redhat.com. Then fedoralegacy.org will continue to >>handle "updates" for each distribution in their own mirror structure. >> >>6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. >>Thus fedoralegacy.org may need to add an "updates-extras" channel in >>order to serve security updates to FC2's Extras. We will not need to >>discuss this until sometime during 2005 though. > > > perhaps should the fedora.us tree be considered extras for RH8.0 RH9 and FC1? > and moved to fedoralegacy.org when product is EOL? Users already use our existing trees and fedura.us mirrors. Better to not confuse fedoralegacy's goal which is ONLY updates and not add-ons. > > >>7) fedoralegacy.org can continue to use bugzilla.fedora.us. That >>instance of Bugzilla is now being maintained professionally and should >>remain stable as a result. New products/components can be added to the >>Bugzilla to uniquely support Legacy development. > > > as part of the fedoralegacy.org identity i think we should have our own > bugzilla and wiki Just point another domainname to that IP address. It should work I think. =) But if you folks insist on running your own Bugzilla, that means you need to maintain it too. Warren From mail at jonaspasche.de Mon Jan 19 14:36:07 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Mon, 19 Jan 2004 15:36:07 +0100 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <200401192330.45813.dennis@ausil.us> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> <200401192330.45813.dennis@ausil.us> Message-ID: <1074522966.3562.165.camel@leonardo> Hi Dennis, > could we symlink legacy to legacy-addons on fedora.us for a short period with > an updated yum package pointing to the new location perhaps a future feature > for yum would be to detect 301 errors and adjust its config to suit. Symlink yes, but I'm highly against automatically made changes to the config. This would alert file integrity checkers like aide or tripwire on systems where an administrator checks the integrity of a package right before and after an update (and then updates the checksums as well). When thinking about the security of a machine, the admin has to make decisions on which repositories to use. This decision shouldn't be overriden by the automatic package management in any case. Instead, the admin should get informed over the change (yum could output a warning with the new repository URL or the new channel name), but it should be left over to the admin to decide what to do. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Mon Jan 19 16:10:39 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 08:10:39 -0800 Subject: Legacy mirror structure In-Reply-To: <20040119121150.573a81e5@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040119121150.573a81e5@python.freshrpms.net> Message-ID: <200401190810.41216.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 January 2004 03:11, Matthias Saou wrote: > I guess there is a typo for SRPMS/updates-testing where > s/SRPMS/$basearch/. yeah. > > where each subdir of $basearch has a directory RPMS, and a symlink > > SRPMS, which points to the correct ../../SRPMS/foo dir. Given the 7.3 > > release, i386 arch, and the "updates" dir we would have: > > > > download.fedoralegacy.org/legacy/7.3/i386/updates/RPMS > > download.fedoralegacy.org/legacy/7.3/i386/updates/SRPMS->../../SRPMS/u > >pd ates > > Are these SRPMS symlinks really useful? Why not this instead : > $releasever/{base,updates,..}/{$basearch,SRPMS}/*.rpm > Just a thought. My concern is that the same SRPMS are used for all arches. Its not a concern when dealing with JUST i386, but starting with fedora core 1, we'll have x86_64 to deal with, and possibly ppc in the future. Instead of duplicating all the SRPMS across all the arches, I chose to maintain a single SRPM directory, above the basearch. > [...] > > > Thoughts? > > Yes, one more important one : As it is planned to support at least some > Fedora Core releases later on, the information about "redhat" vs. > "fedora" should appear somewhere, otherwise there will clearly be a > scalability problem once Fedora Core 9 needs to be supported ;-) I'd > suggest : > > /legacy/{redhat,fedora}/$releasever/... > > Also, for the ftp/rsync accessible structure, having the leading > /legacy/ part of the path is a good thing (as /pub/legacy for ftp and as > a "legacy" rsync module for instance), but for http it's quite redundant > with the virtual host name, and could be removed for purely cosmetic and > line length considerations. Good suggestion. > In the end, my final suggestion would be : > > http://download.fedoralegacy.org/redhat/$releasever/base/$basearch > http://download.fedoralegacy.org/redhat/$releasever/base/SRPMS > http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch > http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch > http://download.fedoralegacy.org/redhat/$releasever/updates-testing/$bas >earch > http://download.fedoralegacy.org/redhat/$releasever/updates-testing/SRPM >S > http://download.fedoralegacy.org/redhat/$releasever/legacy-addons/$basea >rch > http://download.fedoralegacy.org/redhat/$releasever/legacy-addons/SRPMS > > With "redhat" substituted for "fedora" when the time will come. > > Matthias I wish to use something close to that, but maintain my SRPM links for multiarch space concerns. http://download.fedoralegacy.org/redhat/$releasever/$basearch/updates/RPMS http://download.fedoralegacy.org/redhat/$releasever/$basearch/updates/SRPMS->../../updates/SRPMS - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADAF/4v2HLvE71NURAvnqAJ44+SjIrbfei0RFPLpsY7CXxA+SXgCfcB9a yVcY6lmvyaWUxrIpsGksrLU= =vLDK -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 16:16:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 08:16:48 -0800 Subject: Legacy mirror structure In-Reply-To: <200401192117.41083.dennis@ausil.us> References: <200401190018.35186.jkeating@j2solutions.net> <200401192117.41083.dennis@ausil.us> Message-ID: <200401190816.49026.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 January 2004 03:17, Dennis Gilmore wrote: > can i sugest going with a common format used my most mirrors that way > what is on the fedoralegacy server will match that of the mirrors. I > plan on having a mirror of Legacy if the deal with the hosting company i > have been dealing with works out. I fail to see a common format across most mirrors. Half have a /pub, half just start with /redhat, some have /pub/mirrors/redhat, some have /linux/redhat/linux, etc.. The way I was structuring my system, is so that mirror folks can chose their own top dir to rsync against, and append their own dirs leading up to that top dir. After that top dir of their choice, then everything should be the same. > I wouldnt worry about the symlink to SRPMS but would put in the RPMS > dir then break down to archs for example > > download.fedoralegacy.org/pub/fedoralegacy/7.3/RPMS/i386/legacy-addons > download.fedoralegacy.org/pub/fedoralegacy/7.3/RPMS/ppc/legacy-addons > download.fedoralegacy.org/pub/fedoralegacy/7.3/SRPMS/legacy-addons That breaks metadata structure. Why would you have a seperate update conf line for the SRPMS? SRPMS and RPMS for the given section should exist within the same tree, hence the SRPM link back. That way, one could run say yum-arch (replace this with the new metadata tool) at /redhat/7.3/i386/updates/ and it will gather all the rpms in RPMS/ as well as the srpms in SRPMS/. This makes each "base|updates|updates-testing|legacy-addons" a complete unit for a update tool config line. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADALw4v2HLvE71NURAuyrAJ0Xb0Ra0Bc+k2rmQxLf9zn8GjdrXACgnluV wTR9FygEEwdOsD1Ax1XTyA0= =UP0y -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 16:24:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 08:24:07 -0800 Subject: Legacy mirror structure In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: <200401190824.08686.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 January 2004 03:40, Chuck Wolber wrote: > I'd be interested to see us include lingual and architecture support in > those paths. Recall that the redhat storage paths are: > > $releasever/en/os/$arch Languages no longer make sense as they are merged into a single distribution. No need to add the language. Also, it makes little sense to split out the smaller arch stuff. It's not necessary when update tools give you the right package given the choices. It just creates more subdirs and more headaches. The $basearch I speak of is like i386 vs x86_64 vs ppc vs ia64 etc... not i386 vs i686. the small arch stuff can live in the same directory, just the way that Fedora Core does it. > I think they make a great deal of sense, and will prevent us from having > to play "two-path-monte" or create ugly symbolic link farms if we need > to make changes later. How would you have two-path-monte going on? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADASn4v2HLvE71NURAiUKAKCJ3jVayX3h1z3iV3d0WMa5NO9kPgCfdldk 5o4kpqXkvjckmVW+EBTiCSs= =vQwl -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 19 16:33:13 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 19 Jan 2004 17:33:13 +0100 Subject: Legacy mirror structure In-Reply-To: <200401190810.41216.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <20040119121150.573a81e5@python.freshrpms.net> <200401190810.41216.jkeating@j2solutions.net> Message-ID: <20040119173313.7370ae35@python.freshrpms.net> Jesse Keating wrote : > My concern is that the same SRPMS are used for all arches. Its not a > concern when dealing with JUST i386, but starting with fedora core 1, > we'll have x86_64 to deal with, and possibly ppc in the future. Instead > of duplicating all the SRPMS across all the arches, I chose to maintain a > single SRPM directory, above the basearch. Indeed, silly me. Then wouldn't using the same layout as Red Hat is currently using for FC development be best? It's having "SRPMS" and all arch directories beside each other in the version or component directory. [...]/redhat/$releasever/{updates,..}/{SRPMS,i386,ia64,..}/{headers/,*.rpm} > I wish to use something close to that, but maintain my SRPM links for > multiarch space concerns. Wit the above, you don't really need any kind of symlink, although for Fedora Core, Red Hat has create one within all $basearch which points to ../SRPMS IIRC. At a quick glance, this conforms to Warren's recommendations, as long as the base ftp/rsync directory/module name is "fedoralegacy". I'm also all for using the "legacy-addons" name for the legacy-specific additional packages, as we've already seen confusion on the list as to where the "legacy updates" packages were actually located. http://download.fedoralegacy.org/redhat/$releasever//SRPMS/headers http://download.fedoralegacy.org/redhat/$releasever//SRPMS/*.rpm http://download.fedoralegacy.org/redhat/$releasever//$basearch/headers http://download.fedoralegacy.org/redhat/$releasever//$basearch/*.rpm With "" in : base, updates, testing-updates, legacy-addons The headers in SRPMS could probably be omitted to not increase even more the number of files to consider for each mirror rsync run, as they are not useful or used AFAIK. Oh, another concern : Is there any plan to include any debuginfo packages? It could then be something like this? : [...]/fedora/$releasever/updates/$basearch/debug/{headers/,*.rpm} But the headers for the non-debug packages would then contain the debug ones too... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2154.nptl Load : 0.06 0.13 0.15 From jkeating at j2solutions.net Mon Jan 19 16:39:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 08:39:05 -0800 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <400BD08B.2060407@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> Message-ID: <200401190839.07327.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 January 2004 04:41, Warren Togami wrote: > ==================================================== > The following are my personal recommendations regarding the mirror > structure. > > IMHO, since long time ago RH merged all languages into a single > distribution, I highly doubt we will go back to having multiple > distributions for different languages. The earlier 7.x supported by > Legacy is only a special case. For this reason I would suggest not > using a language directory. Keep one layer of complexity out. Correct. I agree too. > arch directory does make sense though. I am surprised they are missing > from your original proposal you were the one that suggested arch i386 > and x86_64 in IRC. =) My original proposal DOES have arch, the $basearch of the url is for the i386 vs x86_64 vs ia64. Thats the reason behind the whole SRPM symlink system. > I am in agreement with previous posters in suggesting making the basedir > "fedoralegacy" rather than just "legacy". This makes things more clear > for mirror maintainers. The basedir of MY server matters little. The mirror admins should be allowed to make their own base dir(s) and choose at what point in our master tree they wish to rsync from. We should not try to force a specific basedir upon them. In our mirror document, we can suggest a basedir of fedoralegacy though. > I would highly suggest going through at least another day of discussion > and consensus for the mirror structure, since this is IMPORTANT. You > need to live with it forever. Of course, I'm not going to just go out and implement it today... I have to contact the ISP and go through all of that. I'd MUCH rather get good consensus on the system before we move forward. > One note about when you write the Fedora Legacy mirror HOWTO document. > Make sure that your package timestamps match exactly RH's main mirror, > and make sure that mirrors use rsync option "-a" which will preserve > timestamps among several other wanted options. This should allow mirror > admins to use the hardlink tool (contained in the legacy-addons channel) > to consolidate tons of space with their existing redhat and > fedora.redhat.com mirrors. Duly noted. Is there any chance you could tell me what time server updates.redhat.com syncs against? > I would suggest NOT holding the base SRPMS within the mirror tree on the > Legacy master mirror. Just keep the directory empty. They are almost > totally never needed, and if a developer really does need it, they can > get it easily enough from any of the thousand existing RH/Fedora > mirrors. I'm somewhat tossing/turning over this one. I've ran across servers that don't have the SRPMS and it pisses me off that I have to hunt down another fast server that has my content. To make our master server self hosting(well a little beyond) I'd rather have it there, since we can plan for the space usage anyway. Individual mirrors can choose to exclude/hardlink this directory if they wish. > I am intrigued by the channel name "legacy-addons" rather than "legacy" > currently used by fedora.us. It would be a little confusing to have > both names exist. I suppose I could rename the channels on fedora.us, > but unfortunately all existing users pointing there will need to upgrade > their yum or edit their configurations. Yes, that is unfortunate, but they'll probably have to do it again in the future sometime if we come up with a good round-robin URL to use that points to a few different well supported mirrors to include with the default yum/apt config files. Pointing to a single server can hurt, just as Seth about duke's mirror and the effects of yum defaulting to it. I'd rather see a generic URL, like "mirror.fedoralegacy.org" used as a round robin to represent a few spread out locations across the world for the default. The end user can live with this, or find the mirror list on our site and change it themselves. Those servers represented by the roundrobin would have to have the exact same structure though. > I do admit however that "legacy-addons" is less ambiguous and very clear > that it contains only add-ons, while "updates" does not. Thus I am > thinking this is a good idea. Sorry existing users... but read below, > since I am thinking to soon remove 7.2 and 7.3 completely from > download.fedora.us for reasons of redundancy. Soon, but not before Legacy has their master mirror server up right? (: > ============== > Just to clarify about why download.fedora.us is maintaining a separate > mirror structure from fedoralegacy.org. Below outlines my thoughts for > future maintenance and distribution of fedora.us, and how it will > continue to operate after FC2 when the Extras development and > repositories are moved to fedora.redhat.com. > > 1) fedoralegacy.org's own mirror structure allows a separation of > governace, security, build system, and responsibility of sysadmin > duties. (Community no longer needs to rely on Warren. Warren does not > go insane.) LOL! Good reasons. > 2) I plan on automatically rsyncing legacy's updates and legacy-addons > channel into the appropriate directories of download.fedora.us. This > will allow existing fedora.us users to continue to get updates from > repositories they had been using since 9 months ago for RH8, RH9 and > FC1. Other existing repositories with an "updates" channel like > freshrpms.net could do the same from legacy's "updates" and continue to > serve existing users in a similar manner. > Existing users need only import the new FEDORA-LEGACY-GPG-KEY. This is perfect. My design of the main legacy mirror server should allow individual mirror admins or systems to sync only what they need, and publish specific config files for use with their mirror(system). > 3) It is true that download.fedora.us 7.2 and 7.3 will be completely > redundant to fedoralegacy.org's 7.2 and 7.3 since fedora.us never did > make add-on packages for 7.x. For this reason I am thinking to simply > remove the 7.2 and 7.3 trees from download.fedora.us. I'm hurting for > space anyhow... Thats agreeable to me, as long as we have our mirrors up first. > 4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in > the Extras channels stable/testing/unstable for users who wish to use > them, while continuing to benefit from "updates" which are copied from > legacy. fedora.us will indefinitely maintain security updates for RH8, > RH9, FC1 Extras within the existing download.fedora.us tree, with the > help of the Legacy team. Can you re-word this a bit? Almost sounds like you want us to maintain security releases for the 3rd party packages you host for 8.0, 9, and FC1.. Isn't that a bit beyond the scope of Fedora Legacy? > 5) download.fedora.us will no longer be needed by FC2, since Extras will > be moved to fedora.redhat.com. Then fedoralegacy.org will continue to > handle "updates" for each distribution in their own mirror structure. Ok. > 6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. > Thus fedoralegacy.org may need to add an "updates-extras" channel in > order to serve security updates to FC2's Extras. We will not need to > discuss this until sometime during 2005 though. Yes, it's been in the back of my mind how to handle extras and alternatives. I suppose we'll have to wait and see what kind of content makes it in there, and if it's within the scope of Legacy to support such things. > 7) fedoralegacy.org can continue to use bugzilla.fedora.us. That > instance of Bugzilla is now being maintained professionally and should > remain stable as a result. New products/components can be added to the > Bugzilla to uniquely support Legacy development. I like this. I would like to create an A record for your system, just call it bugzilla.fedoralegacy.org. This shouldn't be a problem no? In the future, can we have our own tracker, instead of Fedora Meta, can it be Fedora Legacy with me as the default bug owner? Your call. > 8) fedoralegacy.org should eventually fork their documentation into > their own Wiki for draft & editing purposes while policies are discussed > and agreed upon. Then maybe later docbook XML for nicely formatted > finalized documents. This policy & process documentation writing is > another job needed for fedoralegacy.org, and another chance for > volunteers to contribute. Yep, I've been thinking on that too. I do like your wiki system, I'd like to copy it for our use for doc drafts, but our website should NOT point to wiki pages for documentation. They should point to the docbook XML formats you mention above. This way we could also mirror the www.fedoralegacy.org site without mirroring the wiki and having problems that go along with that. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADAgp4v2HLvE71NURAkjKAKCD5AzHCZC8dkCMs9LYHJ4TpadMAgCfZ6/V tDYS+2dujVsg2u5+hO4jGsw= =n266 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 19 16:45:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 08:45:16 -0800 Subject: Legacy mirror structure In-Reply-To: <20040119173313.7370ae35@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190810.41216.jkeating@j2solutions.net> <20040119173313.7370ae35@python.freshrpms.net> Message-ID: <200401190845.18176.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 January 2004 08:33, Matthias Saou wrote: > Indeed, silly me. Then wouldn't using the same layout as Red Hat is > currently using for FC development be best? It's having "SRPMS" and all > arch directories beside each other in the version or component > directory. > > [...]/redhat/$releasever/{updates,..}/{SRPMS,i386,ia64,..}/{headers/,*.r >pm} > > > I wish to use something close to that, but maintain my SRPM links for > > multiarch space concerns. > > Wit the above, you don't really need any kind of symlink, although for > Fedora Core, Red Hat has create one within all $basearch which points to > ../SRPMS IIRC. > > At a quick glance, this conforms to Warren's recommendations, as long as > the base ftp/rsync directory/module name is "fedoralegacy". I'm also all > for using the "legacy-addons" name for the legacy-specific additional > packages, as we've already seen confusion on the list as to where the > "legacy updates" packages were actually located. > > http://download.fedoralegacy.org/redhat/$releasever//SRPMS/headers > http://download.fedoralegacy.org/redhat/$releasever//SRPMS/*.rpm > http://download.fedoralegacy.org/redhat/$releasever//$basearch/head >ers > http://download.fedoralegacy.org/redhat/$releasever//$basearch/*.rp >m > > With "" in : base, updates, testing-updates, legacy-addons > The headers in SRPMS could probably be omitted to not increase even more > the number of files to consider for each mirror rsync run, as they are > not useful or used AFAIK. Again, your running into a situation where the end user would have to have an explicit "SRPM" yum/apt config line. With my structure the [updates] section itself supports both RPMS and SRPMS. This seems far less confusing to the end user. > Oh, another concern : Is there any plan to include any debuginfo > packages? It could then be something like this? : > [...]/fedora/$releasever/updates/$basearch/debug/{headers/,*.rpm} > > But the headers for the non-debug packages would then contain the debug > ones too... Yes, difficult thing to think of. Perhaps it would be feasable for the master mirror to hold the correct headers/ file that has SRPMS and debug stuff, but have a mirror.headers/ directory that is the result of ignoring the SRPMS and the debug stuff. I personally don't wish to include debug stuff. If the end user wants debug, they can download the SRPM and build it themselves. But a headers/ and a headers.nosrpms/ would be useful for mirror folks. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADAmc4v2HLvE71NURAhcIAJ0UXs7+zpgTfqdfCeZuoJrnyA5kXgCfQRHW mVntqafPD6WMH8mULdC0rTk= =ifeb -----END PGP SIGNATURE----- From mail at jonaspasche.de Mon Jan 19 16:49:30 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Mon, 19 Jan 2004 17:49:30 +0100 Subject: End-user documentation for 7.x Message-ID: <1074530969.3562.203.camel@leonardo> Hi folks, I've written end-user documentation for users of Red Hat Linux 7.x - please review it and send feedback to me or to the list for discussion: http://jonaspasche.de/fedoralegacy/enduser-rh7x.html The page reflects the fact that yum hasn't been a part of 7.x, and it shows a straightforward way to use Fedora Legacy on without explaining too much details that aren't needed for basic usage. If discussion of this page is finished, I'll rework it for 8.0 (including information on How to upgrade RPM and How to check if yum is already installed). When both docs are ready and published, I'd suggest to put a link to that page on the "Download" page as many people simply try to skip the docs and go directly to the downloads, which isn't appropriate here. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sean at resultsoverhead.com Mon Jan 19 17:22:02 2004 From: sean at resultsoverhead.com (Sean Kerner) Date: Mon, 19 Jan 2004 12:22:02 -0500 Subject: End-user documentation for 7.x In-Reply-To: <1074530969.3562.203.camel@leonardo> Message-ID: Hi Jonas, Great stuff - for a relative 'low-skill-level' 7.x admin like myself this will really help. One small grammer thing that I'd like to suggest: >yum (Yellow dog Updater, Modified) is an automatic updater and package installer/remover for RPM systems. It will help you keeping your system up to date and is used by Fedora Core, the successor of Red Hat Linux. Unfortunately, it wasn't included in 7.x releases of Red Hat Linux, but we have prepared a package for you to get the full yum functionality on your existing system< Suggestion: Second sentence change to: It will help you to keep your system up to date and is used by Fedora Core, the successor of Red Hat Linux. Sean -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com]On Behalf Of Jonas Pasche Sent: January 19, 2004 11:50 AM To: fedora-legacy-list at redhat.com Subject: End-user documentation for 7.x Hi folks, I've written end-user documentation for users of Red Hat Linux 7.x - please review it and send feedback to me or to the list for discussion: http://jonaspasche.de/fedoralegacy/enduser-rh7x.html The page reflects the fact that yum hasn't been a part of 7.x, and it shows a straightforward way to use Fedora Legacy on without explaining too much details that aren't needed for basic usage. If discussion of this page is finished, I'll rework it for 8.0 (including information on How to upgrade RPM and How to check if yum is already installed). When both docs are ready and published, I'd suggest to put a link to that page on the "Download" page as many people simply try to skip the docs and go directly to the downloads, which isn't appropriate here. Jonas From notting at redhat.com Mon Jan 19 17:30:38 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jan 2004 12:30:38 -0500 Subject: Legacy mirror structure In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> Message-ID: <20040119173038.GA22383@devserv.devel.redhat.com> Chuck Wolber (chuckw at quantumlinux.com) said: > I'd be interested to see us include lingual and architecture support in > those paths. Recall that the redhat storage paths are: > > $releasever/en/os/$arch There are no language-specific package bits. Bill From kelson at speed.net Mon Jan 19 17:49:11 2004 From: kelson at speed.net (Kelson Vibber) Date: Mon, 19 Jan 2004 09:49:11 -0800 Subject: End-user documentation for 7.x In-Reply-To: References: <1074530969.3562.203.camel@leonardo> Message-ID: <6.0.1.1.0.20040119094808.02576b08@mail.speed.net> At 09:22 AM 1/19/2004, Sean Kerner wrote: >Suggestion: Second sentence change to: >It will help you to keep your system up to date and is used by Fedora Core, >the successor of Red Hat Linux. I'd like to make another suggestion on this one: I think "successor to" would be more appropriate than "successor of" Kelson Vibber SpeedGate Communications From warren at togami.com Mon Jan 19 18:00:52 2004 From: warren at togami.com (Warren Togami) Date: Mon, 19 Jan 2004 08:00:52 -1000 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <200401190839.07327.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> <200401190839.07327.jkeating@j2solutions.net> Message-ID: <400C1B54.3050408@togami.com> Jesse Keating wrote: >>>I am in agreement with previous posters in suggesting making the basedir >>>"fedoralegacy" rather than just "legacy". This makes things more clear >>>for mirror maintainers. > > > The basedir of MY server matters little. The mirror admins should be > allowed to make their own base dir(s) and choose at what point in our > master tree they wish to rsync from. We should not try to force a > specific basedir upon them. In our mirror document, we can suggest a > basedir of fedoralegacy though. > Fair enough. > > I'm somewhat tossing/turning over this one. I've ran across servers that > don't have the SRPMS and it pisses me off that I have to hunt down another > fast server that has my content. To make our master server self > hosting(well a little beyond) I'd rather have it there, since we can plan > for the space usage anyway. Individual mirrors can choose to > exclude/hardlink this directory if they wish. You want to have convenience for yourself at the expense of several GB's for the many mirrors that don't exclude or hardlink? I would highly advocate for "smart by default". > >>>4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in >>>the Extras channels stable/testing/unstable for users who wish to use >>>them, while continuing to benefit from "updates" which are copied from >>>legacy. fedora.us will indefinitely maintain security updates for RH8, >>>RH9, FC1 Extras within the existing download.fedora.us tree, with the >>>help of the Legacy team. > > > Can you re-word this a bit? Almost sounds like you want us to maintain > security releases for the 3rd party packages you host for 8.0, 9, and > FC1.. Isn't that a bit beyond the scope of Fedora Legacy? I meant to say that Legacy should only help to keep an eye for security holes and just alert us. Watching the lists is the hardest part. Legacy people already watch the list as part of their job, so they can really help us in this regard. > >>>7) fedoralegacy.org can continue to use bugzilla.fedora.us. That >>>instance of Bugzilla is now being maintained professionally and should >>>remain stable as a result. New products/components can be added to the >>>Bugzilla to uniquely support Legacy development. > > > I like this. I would like to create an A record for your system, just call > it bugzilla.fedoralegacy.org. This shouldn't be a problem no? In the > future, can we have our own tracker, instead of Fedora Meta, can it be > Fedora Legacy with me as the default bug owner? Your call. Adding products/components to the bugzilla is no problem. Just wait until a day where it is 8AM and I had had a night of sleep... Warren From Craig.Miskell at agresearch.co.nz Mon Jan 19 19:18:00 2004 From: Craig.Miskell at agresearch.co.nz (Miskell, Craig) Date: Tue, 20 Jan 2004 08:18:00 +1300 Subject: End-user documentation for 7.x Message-ID: Nit pick: "It will help you keep your system up to date", or "It will help you in keeping your system up to date". I'm not sure which one you intended.;-) Craig > -----Original Message----- > From: Sean Kerner [mailto:sean at resultsoverhead.com] > Sent: Tuesday, 20 January 2004 6:22 a.m. > To: fedora-legacy-list at redhat.com > Subject: RE: End-user documentation for 7.x > > > Hi Jonas, > > Great stuff - for a relative 'low-skill-level' 7.x admin like > myself this > will really help. > > One small grammer thing that I'd like to suggest: > > >yum (Yellow dog Updater, Modified) is an automatic updater > and package > installer/remover for RPM systems. It will help you keeping > your system up > to date and is used by Fedora Core, the successor of Red Hat Linux. > Unfortunately, it wasn't included in 7.x releases of Red Hat > Linux, but we > have prepared a package for you to get the full yum > functionality on your > existing system< > > Suggestion: Second sentence change to: > It will help you to keep your system up to date and is used > by Fedora Core, > the successor of Red Hat Linux. > > > Sean > > > -----Original Message----- > From: fedora-legacy-list-admin at redhat.com > [mailto:fedora-legacy-list-admin at redhat.com]On Behalf Of Jonas Pasche > Sent: January 19, 2004 11:50 AM > To: fedora-legacy-list at redhat.com > Subject: End-user documentation for 7.x > > > Hi folks, > > I've written end-user documentation for users of Red Hat Linux 7.x - > please review it and send feedback to me or to the list for > discussion: > http://jonaspasche.de/fedoralegacy/enduser-rh7x.html The page reflects the fact that yum hasn't been a part of 7.x, and it shows a straightforward way to use Fedora Legacy on without explaining too much details that aren't needed for basic usage. If discussion of this page is finished, I'll rework it for 8.0 (including information on How to upgrade RPM and How to check if yum is already installed). When both docs are ready and published, I'd suggest to put a link to that page on the "Download" page as many people simply try to skip the docs and go directly to the downloads, which isn't appropriate here. Jonas -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From Craig.Miskell at agresearch.co.nz Mon Jan 19 19:19:19 2004 From: Craig.Miskell at agresearch.co.nz (Miskell, Craig) Date: Tue, 20 Jan 2004 08:19:19 +1300 Subject: End-user documentation for 7.x Message-ID: Oh bother. Mis-parsed the e-mail.. Please ignore me this time. Craig > -----Original Message----- > From: Miskell, Craig > Sent: Tuesday, 20 January 2004 8:18 a.m. > To: fedora-legacy-list at redhat.com > Subject: RE: End-user documentation for 7.x > > > Nit pick: "It will help you keep your system up to date", or "It will > help you in keeping your system up to date". I'm not sure > which one you > intended.;-) > > Craig > > > -----Original Message----- > > From: Sean Kerner [mailto:sean at resultsoverhead.com] > > Sent: Tuesday, 20 January 2004 6:22 a.m. > > To: fedora-legacy-list at redhat.com > > Subject: RE: End-user documentation for 7.x > > > > > > Hi Jonas, > > > > Great stuff - for a relative 'low-skill-level' 7.x admin like > > myself this > > will really help. > > > > One small grammer thing that I'd like to suggest: > > > > >yum (Yellow dog Updater, Modified) is an automatic updater > > and package > > installer/remover for RPM systems. It will help you keeping > > your system up > > to date and is used by Fedora Core, the successor of Red Hat Linux. > > Unfortunately, it wasn't included in 7.x releases of Red Hat > > Linux, but we > > have prepared a package for you to get the full yum > > functionality on your > > existing system< > > > > Suggestion: Second sentence change to: > > It will help you to keep your system up to date and is used > > by Fedora Core, > > the successor of Red Hat Linux. > > > > > > Sean > > > > > > -----Original Message----- > > From: fedora-legacy-list-admin at redhat.com > > [mailto:fedora-legacy-list-admin at redhat.com]On Behalf Of > Jonas Pasche > > Sent: January 19, 2004 11:50 AM > > To: fedora-legacy-list at redhat.com > > Subject: End-user documentation for 7.x > > > > > > Hi folks, > > > > I've written end-user documentation for users of Red Hat Linux 7.x - > > please review it and send feedback to me or to the list for > > discussion: > > > http://jonaspasche.de/fedoralegacy/enduser-rh7x.html > > The page reflects the fact that yum hasn't been a part of 7.x, and it > shows a straightforward way to use Fedora Legacy on without explaining > too much details that aren't needed for basic usage. > > If discussion of this page is finished, I'll rework it for 8.0 > (including information on How to upgrade RPM and How to check > if yum is > already installed). > > When both docs are ready and published, I'd suggest to put a link to > that page on the "Download" page as many people simply try to skip the > docs and go directly to the downloads, which isn't appropriate here. > > Jonas > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > ============================================================== > ========= > Attention: The information contained in this message and/or > attachments > from AgResearch Limited is intended only for the persons or entities > to which it is addressed and may contain confidential and/or > privileged > material. Any review, retransmission, dissemination or other > use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipients is prohibited by > AgResearch > Limited. If you have received this message in error, please notify the > sender immediately. > ============================================================== > ========= > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From drees at greenhydrant.com Mon Jan 19 19:36:03 2004 From: drees at greenhydrant.com (David Rees) Date: Mon, 19 Jan 2004 11:36:03 -0800 (PST) Subject: mc packages need QA In-Reply-To: <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> References: <200401181741.56506.jkeating@j2solutions.net> <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> Message-ID: <1332.208.48.139.163.1074540963.squirrel@www.greenhydrant.com> On Sun, January 18, 2004 at 7:19 pm, Arvand Sabetian wrote: > > I noticed that a lot of packages are being put out however some are not > being tested (QAed?). This is probably the reason they are not being > published even a week after they are created. My question is that do you > think it is possible to run VMware (http://www.vmware.com/) and install RH > 7.3/8.0/9.0 then test the packages using this? Or would the testing not be > accurate as it is being done in VMWare? Another option besides VMware is UML (User Mode Linux, http://user-mode-linux.sourceforge.net/). I've been trying to get this setup so I can start getting familiar with the QA process. -Dave From chuckw at quantumlinux.com Mon Jan 19 19:50:26 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 19 Jan 2004 11:50:26 -0800 (PST) Subject: Legacy mirror structure In-Reply-To: <200401190824.08686.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190824.08686.jkeating@j2solutions.net> Message-ID: > > I think they make a great deal of sense, and will prevent us from > > having to play "two-path-monte" or create ugly symbolic link farms if > > we need to make changes later. > > How would you have two-path-monte going on? When you realize you were being too shortsighted and have to have two paths to the same location so you don't break tools. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From maxfield at one.ctelcom.net Mon Jan 19 20:10:43 2004 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Mon, 19 Jan 2004 14:10:43 -0600 (CST) Subject: mc packages need QA In-Reply-To: <1332.208.48.139.163.1074540963.squirrel@www.greenhydrant.com> References: <200401181741.56506.jkeating@j2solutions.net> <200401190318.i0J3Ihlo059596@pimout4-ext.prodigy.net> <1332.208.48.139.163.1074540963.squirrel@www.greenhydrant.com> Message-ID: I've done UML. I've found that redhat 8.0 is the most stable platform underneath the uml. I've tried Mandrake and Debian. Debian was very unstable on an athlon. I use tun/tap to generate the ip address sockets to create your ip addresses. This gives every machine its own address without tying up addresses on the host machine. I run some mandrakes as uml's, so I create a Mandrake user. The Mandrake user runs the uml under 'his' permissions, so the startup file must create the taps with his permissions. -------------------------------------- here is part of my /etc/rc.d/rc.local # # set up bridging on ethernet 0 /etc/rc.d/setup_br0 # bridging on ethernet 1 /etc/rc.d/setup_br1 ------------------------------------- the setup_br0 file --------------------------- #setup_br0 # modify eth0, turning it into br0 modprobe bridge modprobe tun /usr/sbin/brctl addbr br0 /usr/sbin/brctl stp br0 off /bin/su - mandrake -c "/usr/bin/tunctl -u mandrake -t tap0" /bin/su - mandrake -c "/usr/bin/tunctl -u mandrake -t tap2" /bin/su - mandrake -c "/usr/bin/tunctl -u mandrake -t tap4" /bin/su - mandrake -c "/usr/bin/tunctl -u mandrake -t tap6" /sbin/ifconfig tap0 0.0.0.0 promisc up /sbin/ifconfig tap2 0.0.0.0 promisc up /sbin/ifconfig tap4 0.0.0.0 promisc up /sbin/ifconfig tap6 0.0.0.0 promisc up /usr/sbin/brctl addif br0 eth0 /usr/sbin/brctl addif br0 tap0 /usr/sbin/brctl addif br0 tap2 /usr/sbin/brctl addif br0 tap4 /usr/sbin/brctl addif br0 tap6 /sbin/ifconfig br0 11.22.33.7 netmask 255.255.255.0 up /sbin/route add default gw 11.22.33.1 /sbin/route add -host 11.22.33.7 br0 ---------------------------------------------------- the startup file -------------------------------------------------- #!/bin/bash #uml startvm # cd /home/vmdirectory echo the uml_console umid is "vm" # # the virtual machine uses file root_fs by default # that root_fs file is in /home/vmdirectory # and must be owned by the user starting the vm # or must be in the same group as that user and that # user has write priv to it. # # swapfile allows you to mount a swap as its own hard # drive # # the following line has wrapped # linux umid=vm mem=64M eth0=tuntap,tap2 con0=fd:0,fd:1 con=/dev/null ubd1=swapfile -------------------------------------------------------------- In the virtual machine, I found the following to be useful when running multiple virtual machine. The last two #'s are related to the ip addresses I'm running with: in /etc/rc.d/rc.local ifconfig eth0 hw ether FE:FD:00:00:33:7 --> This gives you a good unique etherent address (which matches the network address to some extent) and allows multiple machines to exist on the same network with some semblance of sanity as you bring machines up and down. -------------------------------------------------------- NOTE: Different kernels behave differently as UML kernels. Some work better than others. Be aware that a UML kernel may not boot. I've heard of problems with version 2.4.23. These may be stupid user tricks, maybe not. -------------------------------------------------------------- I run the uml machines in console windows under X. I do a start menu, run, /home/vimdirectory/startvm (and check "run in a console"). This gives me an interactive boot window that I can take up and down indefinitely. I've tried the demon that can provide tun/tap's, but I've had issues with it being unstable. That may be my fault. Also, bringing a machine up and down by forcing it down and then back up may hose the bridge interface and require a master machine reboot to bring that tun/tab (tap2 in this case) back to life. This happens once in a great while to me. On Mon, 19 Jan 2004, David Rees wrote: > Date: Mon, 19 Jan 2004 11:36:03 -0800 (PST) > From: David Rees > Reply-To: fedora-legacy-list at redhat.com > To: fedora-legacy-list at redhat.com > Subject: RE: mc packages need QA > > On Sun, January 18, 2004 at 7:19 pm, Arvand Sabetian wrote: > > > > I noticed that a lot of packages are being put out however some are not > > being tested (QAed?). This is probably the reason they are not being > > published even a week after they are created. My question is that do you > > think it is possible to run VMware (http://www.vmware.com/) and install RH > > 7.3/8.0/9.0 then test the packages using this? Or would the testing not be > > accurate as it is being done in VMWare? > > Another option besides VMware is UML (User Mode Linux, > http://user-mode-linux.sourceforge.net/). I've been trying to get this > setup so I can start getting familiar with the QA process. > > -Dave > > From jkeating at j2solutions.net Mon Jan 19 20:05:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 12:05:11 -0800 Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <400C1B54.3050408@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <200401190839.07327.jkeating@j2solutions.net> <400C1B54.3050408@togami.com> Message-ID: <200401191205.19628.jkeating@j2solutions.net> On Monday 19 January 2004 10:00, Warren Togami wrote: > You want to have convenience for yourself at the expense of several > GB's for the many mirrors that don't exclude or hardlink? I would > highly advocate for "smart by default". depends on your definition of "smart". Me, I think smart is a self hosting repository, that I can get all the needed packages from. Why should I limit my system so that mirror folks can be lazy about how they sync to us? Granted we should make it very clear in the mirror documentation how to avoid the SRPMS if they aren't wanted. > I meant to say that Legacy should only help to keep an eye for > security holes and just alert us. Watching the lists is the hardest > part. Legacy people already watch the list as part of their job, so > they can really help us in this regard. Oh, thats totally agreeable. > Adding products/components to the bugzilla is no problem. Just wait > until a day where it is 8AM and I had had a night of sleep... LOL! -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Mon Jan 19 20:08:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 12:08:03 -0800 Subject: Legacy mirror structure In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> <200401190824.08686.jkeating@j2solutions.net> Message-ID: <200401191208.03867.jkeating@j2solutions.net> On Monday 19 January 2004 11:50, Chuck Wolber wrote: > > How would you have two-path-monte going on? > > When you realize you were being too shortsighted and have to have two > paths to the same location so you don't break tools. Well yea, but specific to our system, how would we wind up at a two-path issue? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Mon Jan 19 20:17:53 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 19 Jan 2004 12:17:53 -0800 (PST) Subject: Legacy mirror structure In-Reply-To: <200401191208.03867.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190824.08686.jkeating@j2solutions.net> <200401191208.03867.jkeating@j2solutions.net> Message-ID: > On Monday 19 January 2004 11:50, Chuck Wolber wrote: > > > How would you have two-path-monte going on? > > > > When you realize you were being too shortsighted and have to have two > > paths to the same location so you don't break tools. > > Well yea, but specific to our system, how would we wind up at a two-path > issue? If we have to make a change later on. You can't just make a path change, or else you'll have a ton of nightly cronjobs breaking all over the place. You have to do it gradually with a bit of fanfare. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Mon Jan 19 20:19:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 12:19:44 -0800 Subject: Legacy mirror structure In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> <200401191208.03867.jkeating@j2solutions.net> Message-ID: <200401191219.44333.jkeating@j2solutions.net> On Monday 19 January 2004 12:17, Chuck Wolber wrote: > If we have to make a change later on. You can't just make a path > change, or else you'll have a ton of nightly cronjobs breaking all > over the place. You have to do it gradually with a bit of fanfare. Ok, but magic eight ball isn't helping out here. Given the current way that Fedora.redhat.com's mirror system is layed out, and given that their RHL tree is really not going to change, do you forsee anything that is going to catch us with my current proposal? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Mon Jan 19 21:10:53 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 19 Jan 2004 13:10:53 -0800 (PST) Subject: Legacy mirror structure In-Reply-To: <200401191219.44333.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401191208.03867.jkeating@j2solutions.net> <200401191219.44333.jkeating@j2solutions.net> Message-ID: On Mon, 19 Jan 2004, Jesse Keating wrote: > On Monday 19 January 2004 12:17, Chuck Wolber wrote: > > If we have to make a change later on. You can't just make a path > > change, or else you'll have a ton of nightly cronjobs breaking all > > over the place. You have to do it gradually with a bit of fanfare. > > Ok, but magic eight ball isn't helping out here. Given the current way > that Fedora.redhat.com's mirror system is layed out, and given that > their RHL tree is really not going to change, do you forsee anything > that is going to catch us with my current proposal? Other than my previous suggestions, no. But, my magic 8-ball seems to be a little off today as well... I still think $language and $arch are good ideas, if only because it gives us a vector to branch off of later on. We simply don't know what $stupid things we're going to be doing in the future. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Mon Jan 19 21:45:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Jan 2004 13:45:30 -0800 Subject: Legacy mirror structure In-Reply-To: References: <200401190018.35186.jkeating@j2solutions.net> <200401191219.44333.jkeating@j2solutions.net> Message-ID: <200401191345.36027.jkeating@j2solutions.net> On Monday 19 January 2004 13:10, Chuck Wolber wrote: > Other than my previous suggestions, no. But, my magic 8-ball seems to > be a little off today as well... > > I still think $language and $arch are good ideas, if only because it > gives us a vector to branch off of later on. We simply don't know > what $stupid things we're going to be doing in the future. Heh, frankly I think the splitting of $arch for i386, i586, i686 and whatnot were $stupid things to do in the first place. I'm glad to see that they have corrected this with Fedora, all updates are in the generic i386/ directory. We can still branch out for x86_64 and ppc at the higher level as I proposed. As notting mentioned, there is no separate $lang stuff anymore, it's all together now. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jan 20 12:15:57 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Jan 2004 13:15:57 +0100 Subject: Legacy mirror structure In-Reply-To: <200401190845.18176.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190810.41216.jkeating@j2solutions.net> <20040119173313.7370ae35@python.freshrpms.net> <200401190845.18176.jkeating@j2solutions.net> Message-ID: <20040120131557.249bb7da@python.freshrpms.net> Jesse Keating wrote : > Yes, difficult thing to think of. Perhaps it would be feasable for the > master mirror to hold the correct headers/ file that has SRPMS and debug > stuff, but have a mirror.headers/ directory that is the result of > ignoring the SRPMS and the debug stuff. I personally don't wish to > include debug stuff. If the end user wants debug, they can download the > SRPM and build it themselves. But a headers/ and a headers.nosrpms/ > would be useful for mirror folks. Well, currently, the (yum) headers for SRPMS are not used for anything AFAIK. And as for having them included on a single config line along with the binary packages, it may be better to have exactly the opposite. With apt for instance, you're much better off not having "rpm-src" lines enabled in your configuration if you don't plan on using "apt-get source" very often. You save bandwidth as well as execution time. Anyway, wouldn't it be better to directly concentrate on the integration of the new common repodata files? The logical evolution is that it'll become the main supported server-side metadata format, so IMHO it's the most important to start thinking of now. How will it handle binary vs. source sets of packages? AFAICT, it doesn't make any special difference between both, but as I said above, it may be interesting to decide to separate them if it can lower to amount of transfered data when minor changes occur (e.g. one new update). I think the solution I like most is : [...]/SRPMS/repodata/ [...]/SRPMS/*.rpm [...]/$basearch/repodata/ [...]/$basearch/*.rpm With a default configuration which only fetches metadata for $basearch packages but with the ability to easily enable fetching it for source packages too. Just as you said concerning the debug packages, that very few people actually need them, the same applies (in a different proportion) to source packages IMHO. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.10 0.48 0.56 From warren at togami.com Tue Jan 20 12:46:21 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Jan 2004 02:46:21 -1000 Subject: Legacy mirror structure In-Reply-To: <20040120131557.249bb7da@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190810.41216.jkeating@j2solutions.net> <20040119173313.7370ae35@python.freshrpms.net> <200401190845.18176.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> Message-ID: <400D231D.2090002@togami.com> Matthias Saou wrote: > Jesse Keating wrote : > > >>Yes, difficult thing to think of. Perhaps it would be feasable for the >>master mirror to hold the correct headers/ file that has SRPMS and debug >>stuff, but have a mirror.headers/ directory that is the result of >>ignoring the SRPMS and the debug stuff. I personally don't wish to >>include debug stuff. If the end user wants debug, they can download the >>SRPM and build it themselves. But a headers/ and a headers.nosrpms/ >>would be useful for mirror folks. > > > Well, currently, the (yum) headers for SRPMS are not used for anything > AFAIK. And as for having them included on a single config line along with > the binary packages, it may be better to have exactly the opposite. With > apt for instance, you're much better off not having "rpm-src" lines enabled > in your configuration if you don't plan on using "apt-get source" very > often. You save bandwidth as well as execution time. I totally agree here. "apt-get" source would also potentially fail on many of the RH packages due to the prevalent missing BuildRequires. Legacy's target users are NOT developers who use the SRPMS often. For this reason I would not include SRPMS for the base distribution nor the almost as numerous RH supplied updates. I would include only SRPMS of Legacy supplied updates, as Legacy QA and buildsystem necessitates fixing BuildRequires, so "apt-get source" at least has a chance of working properly (but it still is not very useful at all). You make mirroring faster by leaving out those THOUSANDS of SRPMS that 0.001% of the users would use. You make client usage faster by leaving it out. You make it far less of a burden in mirror administration by making Legacy as small as possible by default. > > Anyway, wouldn't it be better to directly concentrate on the integration of > the new common repodata files? The logical evolution is that it'll become > the main supported server-side metadata format, so IMHO it's the most > important to start thinking of now. +1 exactly > How will it handle binary vs. source sets of packages? AFAICT, it doesn't > make any special difference between both, but as I said above, it may be > interesting to decide to separate them if it can lower to amount of > transfered data when minor changes occur (e.g. one new update). > > I think the solution I like most is : > > [...]/SRPMS/repodata/ > [...]/SRPMS/*.rpm > [...]/$basearch/repodata/ > [...]/$basearch/*.rpm > Jesse was earlier grappling with the problem of the ugly symlink for a unified SRPMS for all archs. Using a structure like this would work wonderfully, while very conveniently placing all archs and the SRPMS at the same level. Something like: $distnumber/$repository/$basearch/*.rpm Example: 7.2/updates/SRPMS/repodata/ <--- XML metadata 7.2/updates/SRPMS/headers/ <--- yum native headers 7.2/updates/i386/repodata/ <--- XML metadata 7.2/updates/i386/headers/ <--- yum native headers 7.2/updates/base/ <--- non-flat apt genbasedir location (*) 7.2/legacy/SRPMS/repodata/ 7.2/legacy/SRPMS/headers/ 7.2/legacy/i386/repodata/ 7.2/legacy/i386/headers/ 7.2/legacy/base/ . . . 1/updates/SRPMS/repodata/ 1/updates/SRPMS/headers/ 1/updates/i386/repodata/ 1/updates/i386/headers/ 1/updates/x86_64/repodata/ 1/updates/x86_64/headers/ 1/updates/base/ Would something like this work? > With a default configuration which only fetches metadata for $basearch > packages but with the ability to easily enable fetching it for source > packages too. Just as you said concerning the debug packages, that very few > people actually need them, the same applies (in a different proportion) to > source packages IMHO. > > Matthias > I totally agree with everything Matthias has stated here. Warren * I am not sure if apt works this way or not. I have never used genbasedir without the --flat option. Anyone know if anything like this tree structure is possible for the native apt metadata? From tdiehl at rogueind.com Tue Jan 20 13:32:28 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 20 Jan 2004 08:32:28 -0500 (EST) Subject: Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure) In-Reply-To: <400C1B54.3050408@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <400BD08B.2060407@togami.com> <200401190839.07327.jkeating@j2solutions.net> <400C1B54.3050408@togami.com> Message-ID: On Mon, 19 Jan 2004, Warren Togami wrote: > Jesse Keating wrote: > > > > I'm somewhat tossing/turning over this one. I've ran across servers that > > don't have the SRPMS and it pisses me off that I have to hunt down another > > fast server that has my content. To make our master server self > > hosting(well a little beyond) I'd rather have it there, since we can plan > > for the space usage anyway. Individual mirrors can choose to > > exclude/hardlink this directory if they wish. > > You want to have convenience for yourself at the expense of several GB's > for the many mirrors that don't exclude or hardlink? I would highly > advocate for "smart by default". If they do not exclude or hardlink that is their problem. I agree with Jesse PLEASE include the SRPMS. It is a PITA to go looking for them if you need them. Just because not everyone uses them does not mean No one uses them. Disk is cheap and if someone has the space to do a mirror in the first place they most likely have the space for the SRPMS. If they do not how hard is it to exclude them from an rsync job? I fail to see what you are really trying to save. You know it is trivial to exclude things. Tom From jkeating at j2solutions.net Tue Jan 20 16:26:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 08:26:16 -0800 Subject: Legacy mirror structure In-Reply-To: <20040120131557.249bb7da@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190845.18176.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> Message-ID: <200401200826.17186.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 January 2004 04:15, Matthias Saou wrote: > Well, currently, the (yum) headers for SRPMS are not used for anything > AFAIK. And as for having them included on a single config line along > with the binary packages, it may be better to have exactly the opposite. > With apt for instance, you're much better off not having "rpm-src" lines > enabled in your configuration if you don't plan on using "apt-get > source" very often. You save bandwidth as well as execution time. Currently they are not used, but in the future yum will support source downloading. I think you might have finally convinced me to seperate out the SRPMS into their own repository. It's not going to be clean for the conf file, but we can comment them out to save the user bandwidth. I will however still put them on the server. > Anyway, wouldn't it be better to directly concentrate on the integration > of the new common repodata files? The logical evolution is that it'll > become the main supported server-side metadata format, so IMHO it's the > most important to start thinking of now. I have been thinking of this since day one, it's just that from all that I've heard, the repodata works a lot like yum's metadata, so this is how I structured the server. metadata does handle source rpms. > How will it handle binary vs. source sets of packages? AFAICT, it > doesn't make any special difference between both, but as I said above, > it may be interesting to decide to separate them if it can lower to > amount of transfered data when minor changes occur (e.g. one new > update). > > I think the solution I like most is : > > [...]/SRPMS/repodata/ > [...]/SRPMS/*.rpm > [...]/$basearch/repodata/ > [...]/$basearch/*.rpm I think you're missing a few directories there. Try this: [...]/SRPMS/repodata [...]/SRPMS/base/*.rpm [...]/SRPMS/updates-testing/*.rpm [...]/SRPMS/updates/*.rpm [...]/i386/repodata [...]/i386/base/*.rpm [...]/i386/updates-testing/*.rpm [...]/i386/updates/*.rpm I'm making an assumption here that the repo data can be ran at a higher level than yum-arch can, and hold info about different repo subdirs. > With a default configuration which only fetches metadata for $basearch > packages but with the ability to easily enable fetching it for source > packages too. Just as you said concerning the debug packages, that very > few people actually need them, the same applies (in a different > proportion) to source packages IMHO. Right, I think more people will be browsing the tree for SRPMS rather than using package tools. I'm fiddling with http://download.fedoralegacy.org today to make a real copy of my intended layout. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADVao4v2HLvE71NURAnZpAKCDwFmlL+sSsc/pehei90JKQiP1KQCggNi0 sr/cMGjtA1OumhkQfeHXbmA= =O8VV -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Jan 20 16:29:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 08:29:41 -0800 Subject: Legacy mirror structure In-Reply-To: <400D231D.2090002@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> <400D231D.2090002@togami.com> Message-ID: <200401200829.43316.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 January 2004 04:46, Warren Togami wrote: > I totally agree here. "apt-get" source would also potentially fail on > many of the RH packages due to the prevalent missing BuildRequires. > Legacy's target users are NOT developers who use the SRPMS often. > > For this reason I would not include SRPMS for the base distribution nor > the almost as numerous RH supplied updates. I would include only SRPMS > of Legacy supplied updates, as Legacy QA and buildsystem necessitates > fixing BuildRequires, so "apt-get source" at least has a chance of > working properly (but it still is not very useful at all). > > You make mirroring faster by leaving out those THOUSANDS of SRPMS that > 0.001% of the users would use. You make client usage faster by leaving > it out. You make it far less of a burden in mirror administration by > making Legacy as small as possible by default. I'm convienced to put the SRPMS in a different area for repot purposes, but I will not remove it from the server. I've had too many headaches with that. > Jesse was earlier grappling with the problem of the ugly symlink for a > unified SRPMS for all archs. Using a structure like this would work > wonderfully, while very conveniently placing all archs and the SRPMS at > the same level. No longer grappling, if I put SRPMS in their own repository. No longer need symlinks. > Something like: > $distnumber/$repository/$basearch/*.rpm > > Example: > 7.2/updates/SRPMS/repodata/ <--- XML metadata > 7.2/updates/SRPMS/headers/ <--- yum native headers > 7.2/updates/i386/repodata/ <--- XML metadata > 7.2/updates/i386/headers/ <--- yum native headers > 7.2/updates/base/ <--- non-flat apt genbasedir location (*) > 7.2/legacy/SRPMS/repodata/ > 7.2/legacy/SRPMS/headers/ > 7.2/legacy/i386/repodata/ > 7.2/legacy/i386/headers/ > 7.2/legacy/base/ > . . . > 1/updates/SRPMS/repodata/ > 1/updates/SRPMS/headers/ > 1/updates/i386/repodata/ > 1/updates/i386/headers/ > 1/updates/x86_64/repodata/ > 1/updates/x86_64/headers/ > 1/updates/base/ UGH! I don't like splitting inside the /updates dir the extra archs. I'd rather split it at a higher level. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADVd14v2HLvE71NURAp12AJ0cLFAQ0u/xuQi0BOGRJEzYJyaWigCfY7lh ISLBIpi9HIRFYFMBGNbVFwc= =tVgl -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jan 20 16:36:09 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Jan 2004 17:36:09 +0100 Subject: Legacy mirror structure In-Reply-To: <400D231D.2090002@togami.com> References: <200401190018.35186.jkeating@j2solutions.net> <200401190810.41216.jkeating@j2solutions.net> <20040119173313.7370ae35@python.freshrpms.net> <200401190845.18176.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> <400D231D.2090002@togami.com> Message-ID: <20040120173609.5f6a6242@python.freshrpms.net> Warren Togami wrote : > > I think the solution I like most is : > > > > [...]/SRPMS/repodata/ > > [...]/SRPMS/*.rpm > > [...]/$basearch/repodata/ > > [...]/$basearch/*.rpm > > > > Jesse was earlier grappling with the problem of the ugly symlink for a > unified SRPMS for all archs. Using a structure like this would work > wonderfully, while very conveniently placing all archs and the SRPMS at > the same level. > > Something like: > $distnumber/$repository/$basearch/*.rpm > > Example: > 7.2/updates/SRPMS/repodata/ <--- XML metadata > 7.2/updates/SRPMS/headers/ <--- yum native headers > 7.2/updates/i386/repodata/ <--- XML metadata > 7.2/updates/i386/headers/ <--- yum native headers > 7.2/updates/base/ <--- non-flat apt genbasedir location (*) > 7.2/legacy/SRPMS/repodata/ > 7.2/legacy/SRPMS/headers/ > 7.2/legacy/i386/repodata/ > 7.2/legacy/i386/headers/ > 7.2/legacy/base/ > . . . > 1/updates/SRPMS/repodata/ > 1/updates/SRPMS/headers/ > 1/updates/i386/repodata/ > 1/updates/i386/headers/ > 1/updates/x86_64/repodata/ > 1/updates/x86_64/headers/ > 1/updates/base/ > > Would something like this work? I would think so. Seems the cleanest to me, unless I'm missing something. (of course, we've already agreed that "legacy" would be "legacy-addons" instead, right? ;-)) > * I am not sure if apt works this way or not. I have never used > genbasedir without the --flat option. Anyone know if anything like this > tree structure is possible for the native apt metadata? I have quite bad memories of trying to get something decent out of apt when not using --flat. I think that here it would only work if one had : [...]/SRPMS.$repository [...]/$basearch/RPMS.$repository And IIRC, a "base" directory would go into each "$basearch" anyway. It basically just avoids an SRPMS.$repository inside each $basearch, a first good step, but some others would still be needed. I think it's possibly confusing and messes things up if included in the above with symlinks or something. The other alternatives I can see are : - Not support apt on the main download.fedoralegacy.org server, let "specialized" download servers like download.fedora.us or ayo do what they need by themselves if they want. - Support apt directly only once it uses the common repodata files and release "legacy-addons" apt packages only then. Both the above are compatible and would probably mean having yum be the only recommended update tool for now (for download made directly from download.fedoralegacy.org, that is). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.00 0.10 0.23 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jan 20 16:53:03 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Jan 2004 17:53:03 +0100 Subject: Legacy mirror structure In-Reply-To: <200401200826.17186.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190845.18176.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> <200401200826.17186.jkeating@j2solutions.net> Message-ID: <20040120175303.3ad89df8@python.freshrpms.net> Jesse Keating wrote : > > I think the solution I like most is : > > > > [...]/SRPMS/repodata/ > > [...]/SRPMS/*.rpm > > [...]/$basearch/repodata/ > > [...]/$basearch/*.rpm > > I think you're missing a few directories there. Try this: > > [...]/SRPMS/repodata > [...]/SRPMS/base/*.rpm > [...]/SRPMS/updates-testing/*.rpm > [...]/SRPMS/updates/*.rpm > > [...]/i386/repodata > [...]/i386/base/*.rpm > [...]/i386/updates-testing/*.rpm > [...]/i386/updates/*.rpm > > I'm making an assumption here that the repo data can be ran at a higher > level than yum-arch can, and hold info about different repo subdirs. Aha! So I guess the major question left is : - arch then module, e.g. redhat/7.3/i386/updates/ - or - - module then arch, e.g. redhat/7.3/updates/i386/ You seem to prefer the former, while the latter is the one closest to what Red Hat has been using for RHL and FC. Oh, and in the above, "base" should probably be avoided to not be confused with apt's special directory. The other suggestions I have (what I've been using) for it would be "os" or "core". I guess I just truncated my final suggestion too much, here would be a longer example : [...]/fedoralegacy/redhat/7.3/os/SRPMS/repodata/ [...]/fedoralegacy/redhat/7.3/os/SRPMS/*.rpm [...]/fedoralegacy/redhat/7.3/os/i386/repodata/ [...]/fedoralegacy/redhat/7.3/os/i386/*.rpm [...]/fedoralegacy/redhat/7.3/updates/SRPMS/repodata/ [...]/fedoralegacy/redhat/7.3/updates/SRPMS/*.rpm [...]/fedoralegacy/redhat/7.3/updates/i386/repodata/ [...]/fedoralegacy/redhat/7.3/updates/i386/*.rpm etc. with testing-updates and legacy-addons. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.01 0.07 0.14 From jkeating at j2solutions.net Tue Jan 20 16:59:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 08:59:54 -0800 Subject: Legacy mirror structure In-Reply-To: <20040120175303.3ad89df8@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200826.17186.jkeating@j2solutions.net> <20040120175303.3ad89df8@python.freshrpms.net> Message-ID: <200401200859.59949.jkeating@j2solutions.net> On Tuesday 20 January 2004 08:53, Matthias Saou wrote: > Aha! So I guess the major question left is : > > - arch then module, e.g. redhat/7.3/i386/updates/ > - or - > - module then arch, e.g. redhat/7.3/updates/i386/ > > You seem to prefer the former, while the latter is the one closest to > what Red Hat has been using for RHL and FC. Oh, and in the above, > "base" should probably be avoided to not be confused with apt's > special directory. The other suggestions I have (what I've been > using) for it would be "os" or "core". Well, it just looks cleaner to me in my yum conf if the only thing I have to change is the very end of the URL, changing "core" to "updates" to "updates-testing", rather than editing farther up the line prior to the $basearch. I'll listen to other opinions on the matter. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From sheltren at cs.ucsb.edu Tue Jan 20 17:08:30 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 20 Jan 2004 09:08:30 -0800 Subject: Legacy mirror structure In-Reply-To: <200401200859.59949.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200826.17186.jkeating@j2solutions.net> <20040120175303.3ad89df8@python.freshrpms.net> <200401200859.59949.jkeating@j2solutions.net> Message-ID: <1074618510.5657.3.camel@derelict> I like what's behind door number two. ie: redhat/7.3/updates/i386 It just makes more sense to me since that is what I'm used to seeing on redhat mirrors. -Jeff On Tue, 2004-01-20 at 08:59, Jesse Keating wrote: > On Tuesday 20 January 2004 08:53, Matthias Saou wrote: > > Aha! So I guess the major question left is : > > > > - arch then module, e.g. redhat/7.3/i386/updates/ > > - or - > > - module then arch, e.g. redhat/7.3/updates/i386/ > > > > You seem to prefer the former, while the latter is the one closest to > > what Red Hat has been using for RHL and FC. Oh, and in the above, > > "base" should probably be avoided to not be confused with apt's > > special directory. The other suggestions I have (what I've been > > using) for it would be "os" or "core". > > Well, it just looks cleaner to me in my yum conf if the only thing I > have to change is the very end of the URL, changing "core" to "updates" > to "updates-testing", rather than editing farther up the line prior to > the $basearch. I'll listen to other opinions on the matter. From jkeating at j2solutions.net Tue Jan 20 17:09:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 09:09:53 -0800 Subject: Legacy mirror structure In-Reply-To: <1074618510.5657.3.camel@derelict> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <1074618510.5657.3.camel@derelict> Message-ID: <200401200909.53543.jkeating@j2solutions.net> On Tuesday 20 January 2004 09:08, Jeff Sheltren wrote: > I like what's behind door number two. ie: > redhat/7.3/updates/i386 > > It just makes more sense to me since that is what I'm used to seeing > on redhat mirrors. grr, I hate seeing "well this is better because thats what I'm used to seeing". No offense, but just because thats what everybody does doesn't mean it's the most logical or technically clean. If it were reason enough, we'd _all_ be using AOL internet. We have the chance to do something the right way and the logical way, not just "the way that everybody else does things". -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From notting at redhat.com Tue Jan 20 17:22:29 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Jan 2004 12:22:29 -0500 Subject: Legacy mirror structure In-Reply-To: <20040120131557.249bb7da@python.freshrpms.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401190810.41216.jkeating@j2solutions.net> <20040119173313.7370ae35@python.freshrpms.net> <200401190845.18176.jkeating@j2solutions.net> <20040120131557.249bb7da@python.freshrpms.net> Message-ID: <20040120172229.GA22110@devserv.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Jesse Keating wrote : > > > Yes, difficult thing to think of. Perhaps it would be feasable for the > > master mirror to hold the correct headers/ file that has SRPMS and debug > > stuff, but have a mirror.headers/ directory that is the result of > > ignoring the SRPMS and the debug stuff. I personally don't wish to > > include debug stuff. If the end user wants debug, they can download the > > SRPM and build it themselves. But a headers/ and a headers.nosrpms/ > > would be useful for mirror folks. > > Well, currently, the (yum) headers for SRPMS are not used for anything > AFAIK. up2date has code to download the source RPMs for particular binary RPMs, it just hasn't been ported to the yum backend yet. What concerns me about multiple separate repositories for binaries, debuginfo, and source RPMs is just the proliferation of channels that a developer might need to subscribe to. Of course, this is a more general point rather than legacy-specific. Bill From sheltren at cs.ucsb.edu Tue Jan 20 17:28:41 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 20 Jan 2004 09:28:41 -0800 Subject: Legacy mirror structure In-Reply-To: <200401200909.53543.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <1074618510.5657.3.camel@derelict> <200401200909.53543.jkeating@j2solutions.net> Message-ID: <1074619720.5657.10.camel@derelict> Well, to be fair, it does make more sense to me to have the directory layout that way. If I want to mirror the updates I can do so by getting one directory (recursively): redhat/7.3/updates/ With the other layout, I'd have to grab multiple directories in order to have all the architectures available to me, ie: redhat/7.3/i386/updates redhat/7.3/x86_64/updates Which just seems plain silly if you ask me. Updates for one disto should all be under one directory or people (like me) will be confused. I could care less that 'everyone does it this way', it just happens to be the way that makes the most sense (to me) - I'm sorry I wasn't more clear in my last message about this point. -Jeff P.S. - you mean there are other ways to get on the Internet besides AOL? ;) On Tue, 2004-01-20 at 09:09, Jesse Keating wrote: > On Tuesday 20 January 2004 09:08, Jeff Sheltren wrote: > > I like what's behind door number two. ie: > > redhat/7.3/updates/i386 > > > > It just makes more sense to me since that is what I'm used to seeing > > on redhat mirrors. > > grr, I hate seeing "well this is better because thats what I'm used to > seeing". No offense, but just because thats what everybody does > doesn't mean it's the most logical or technically clean. If it were > reason enough, we'd _all_ be using AOL internet. We have the chance to > do something the right way and the logical way, not just "the way that > everybody else does things". From peter.abraham at dynamicnet.net Tue Jan 20 17:32:50 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Tue, 20 Jan 2004 12:32:50 -0500 Subject: /etc/yum.conf In-Reply-To: <200401200859.59949.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200826.17186.jkeating@j2solutions.net> <20040120175303.3ad89df8@python.freshrpms.net> <200401200859.59949.jkeating@j2solutions.net> Message-ID: <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> Greetings: Can some one please post their /etc/yum.conf they are using with Fedora for RedHat 7.3? Thank you. From jkeating at j2solutions.net Tue Jan 20 17:37:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 09:37:24 -0800 Subject: Legacy mirror structure In-Reply-To: <1074619720.5657.10.camel@derelict> References: <200401190018.35186.jkeating@j2solutions.net> <200401200909.53543.jkeating@j2solutions.net> <1074619720.5657.10.camel@derelict> Message-ID: <200401200937.24130.jkeating@j2solutions.net> On Tuesday 20 January 2004 09:28, Jeff Sheltren wrote: > Well, to be fair, it does make more sense to me to have the directory > layout that way. If I want to mirror the updates I can do so by > getting one directory (recursively): > redhat/7.3/updates/ > > With the other layout, I'd have to grab multiple directories in order > to have all the architectures available to me, ie: > redhat/7.3/i386/updates > redhat/7.3/x86_64/updates > > Which just seems plain silly if you ask me. Updates for one disto > should all be under one directory or people (like me) will be > confused. I could care less that 'everyone does it this way', it just > happens to be the way that makes the most sense (to me) - I'm sorry I > wasn't more clear in my last message about this point. Ah, ok. That does make a bit more sense that way. I'll arrange http://download.fedoralegacy.org/ to suit. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Jan 20 18:24:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 10:24:41 -0800 Subject: Final(?) Fedora Legacy Mirror Layout Message-ID: <200401201024.47392.jkeating@j2solutions.net> Ok, taken all feedback, and I've structured a mockup server: http://download.fedoralegacy.org Server actually has some content. 7.2 is almost fully populated, all releases have the updates-testing that I will announce momentarily. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jan 20 18:41:50 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Jan 2004 19:41:50 +0100 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201024.47392.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> Message-ID: <20040120194150.185960c9@python.freshrpms.net> Jesse Keating wrote : > Ok, taken all feedback, and I've structured a mockup server: > > http://download.fedoralegacy.org > > Server actually has some content. 7.2 is almost fully populated, all > releases have the updates-testing that I will announce momentarily. Strange mixture... each $basearch is in a directory for every one of "base, updates, testing-updates and legacy-addons, but directories named like that also exist in a "lower" SRPMS directory. Seems to me like you've mixed the "component/arch" (for binary packages) and "arch/component" (for sources) possibilities, thus making it even more confusing ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.39 0.45 0.39 From jkeating at j2solutions.net Tue Jan 20 18:40:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 10:40:02 -0800 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <20040120194150.185960c9@python.freshrpms.net> References: <200401201024.47392.jkeating@j2solutions.net> <20040120194150.185960c9@python.freshrpms.net> Message-ID: <200401201040.02119.jkeating@j2solutions.net> On Tuesday 20 January 2004 10:41, Matthias Saou wrote: > Strange mixture... each $basearch is in a directory for every one of > "base, updates, testing-updates and legacy-addons, but directories > named like that also exist in a "lower" SRPMS directory. Seems to me > like you've mixed the "component/arch" (for binary packages) and > "arch/component" (for sources) possibilities, thus making it even > more confusing ;-) Because I'm separating out SRPMS for each of the sections. I don't want to have just a big dumping of SRPMS for all the components in a single dir... -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Jan 20 18:47:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 10:47:01 -0800 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201040.02119.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> <20040120194150.185960c9@python.freshrpms.net> <200401201040.02119.jkeating@j2solutions.net> Message-ID: <200401201047.01077.jkeating@j2solutions.net> On Tuesday 20 January 2004 10:40, Jesse Keating wrote: > Because I'm separating out SRPMS for each of the sections. I don't > want to have just a big dumping of SRPMS for all the components in a > single dir... OOps! I see what you're saying. I fubar'd something there when I was moving stuff. Fixing.... -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From chuckw at quantumlinux.com Tue Jan 20 19:03:01 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 20 Jan 2004 11:03:01 -0800 (PST) Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201024.47392.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> Message-ID: > Ok, taken all feedback, and I've structured a mockup server: > > http://download.fedoralegacy.org > > Server actually has some content. 7.2 is almost fully populated, all > releases have the updates-testing that I will announce momentarily. Nice job Jesse. Now we need to set up rsync and anonymous FTP access to the repositories. I'm willing to jump in there and configure those if you don't mind. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Tue Jan 20 19:16:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 11:16:44 -0800 Subject: Fedora Legacy Testing Update: screen Message-ID: <200401201116.44724.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1187 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1187 2004-01-20 --------------------------------------------------------------------- Name : screen Versions : 7.2: 3.9.9-4, 7.3: 3.9.11-4, 8.0: 3.9.11-11 Summary : A screen manager that supports multiple logins on one terminal. Description : The screen utility allows you to have multiple logins on just one terminal. Screen is useful for users who telnet into a machine or are connected via a dumb terminal, but want to use more than just one login. Install the screen package if you need a screen manager that can support multiple logins on one terminal. --------------------------------------------------------------------- Update Information: Integer signedness error in ansi.c for GNU screen 4.0.1 and earlier, and 3.9.15 and earlier, allows local users to execute arbitrary code via a large number of ";" (semicolon) characters in escape sequences, which leads to a buffer overflow. --------------------------------------------------------------------- 7.2 changelog: * Fri Jan 02 2004 Jason Rohwedder 3.9.9-4.legacy - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 7.3 changelog: * Tue Jan 06 2004 Jason Rohwedder 3.9.11-4.legacy - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 8.0 changelog: * Wed Jan 07 2004 Christian Pearce 3.9.11-12.legacy - Spec updated and copied from Jason Rohwedder RedHat 7.2 and 7.3 spec files - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 - Added autoconf213 in BuildRequires --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 194fbeb6e1871aad733966eb03525ee3fa6b736e 7.2/SRPMS/updates-testing/screen-3.9.9-4.legacy.src.rpm 38752ec03ec07ab125ab495910861d0317dfe095 7.2/updates-testing/i386/screen-3.9.9-4.legacy.i386.rpm e22108165eeb8a4f2d6f078600117d2a3b5dc88d 7.3/SRPMS/updates-testing/screen-3.9.11-4.legacy.src.rpm 278a76f5b56d32bc983ab5dc388397c98dffe31c 7.3/updates-testing/i386/screen-3.9.11-4.legacy.i386.rpm 578b3166a0f647ac2a798ad81bdea43c9fe55c7b 8.0/SRPMS/updates-testing/screen-3.9.11-11.legacy.src.rpm c1422da61421e74a5a66e5404f1fcd33134c07e8 8.0/updates-testing/i386/screen-3.9.11-11.legacy.i386.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Jan 20 19:32:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 11:32:47 -0800 Subject: Fedora Legacy Test Update Notification: ethereal Message-ID: <200401201132.52161.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1193 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1193 2004-01-20 --------------------------------------------------------------------- Name : ethereal Versions : 0.9.16-0 Summary : Network traffic analyzer. Description : Ethereal is a network traffic analyzer for Unix-ish operating systems. This package lays base for libpcap, a packet capture and filtering library, contains command-line utilities, and contains plugins and documentation for ethereal. A graphical user interface is packaged separately to GTK+ package. --------------------------------------------------------------------- Update Information: CAN-2003-1012: The SMB dissector in Ethereal before 0.10.0 allows remote attackers to cause a denial of service via a malformed SMB packet that triggers a segmentation fault during processing of Selected packets. CAN-2003-1013: The Q.931 dissector in Ethereal before 0.10.0, and Tethereal, allows remote attackers to cause a denial of service (crash) via a malformed Q.931, which triggers a null dereference. --------------------------------------------------------------------- Changelog: * Wed Jan 07 2004 Christian Pearce - Security fix CAN-2003-1012, CAN-2003-1013. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 9f1a7186859a95604431f52e137943f4a256b89f 7.2/SRPMS/updates-testing/ethereal-0.9.16-0.72.2.legacy.src.rpm 01e991b44ca40f432b639a9cdd25f46ab60a85e7 7.2/updates-testing/i386/ethereal-0.9.16-0.72.2.legacy.i386.rpm c263966f199db31ec551d9dff07363830f575bff 7.2/updates-testing/i386/ethereal-gnome-0.9.16-0.72.2.legacy.i386.rpm 1aebaffacc86561fea139b3dae351722eda761b9 7.3/SRPMS/updates-testing/ethereal-0.9.16-0.73.2.legacy.src.rpm db5326236fe91e7c84be611bbfdafd689187b32b 7.3/updates-testing/i386/ethereal-0.9.16-0.73.2.legacy.i386.rpm d78ca86ff9ca7adb7c0d006c43fe84d138bc87e0 7.3/updates-testing/i386/ethereal-gnome-0.9.16-0.73.2.legacy.i386.rpm 14350e74f4e261002bab186c942bc6caa788fce3 8.0/SRPMS/updates-testing/ethereal-0.9.16-0.80.2.legacy.src.rpm dc94ba568db4239f67cb191d4cf43a1d2f5a4fb7 8.0/updates-testing/i386/ethereal-0.9.16-0.80.2.legacy.i386.rpm a17d1098baf6b4ba2a8588e933a17d96629401cc 8.0/updates-testing/i386/ethereal-gnome-0.9.16-0.80.2.legacy.i386.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Tue Jan 20 20:34:12 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Jan 2004 10:34:12 -1000 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201024.47392.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> Message-ID: <400D90C4.1090702@togami.com> Jesse Keating wrote: > Ok, taken all feedback, and I've structured a mockup server: > > http://download.fedoralegacy.org > > Server actually has some content. 7.2 is almost fully populated, all > releases have the updates-testing that I will announce momentarily. > I cannot say that I like the location of the SRPMS. In this far off location it cannot take advantage of native repository handling with apt's native genbasedir. It is also more difficult to browse it in relation to the binary RPMS built from it. Also it might make it easier to exclude all SRPMS with a single --exclude line in rsync, but this is usually not what mirror admins want. They would rather exclude only the os component and keep the rest. This would be easier and more intuitive if there is a SRPMS directory at the same level of each $basearch for each repository. Also if you intend on keeping RH's massive amount of existing "updates" SRPMS, there is no way of excluding those only. Warren From jkeating at j2solutions.net Tue Jan 20 20:34:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 12:34:38 -0800 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <400D90C4.1090702@togami.com> References: <200401201024.47392.jkeating@j2solutions.net> <400D90C4.1090702@togami.com> Message-ID: <200401201234.46724.jkeating@j2solutions.net> On Tuesday 20 January 2004 12:34, Warren Togami wrote: > I cannot say that I like the location of the SRPMS. In this far off > location it cannot take advantage of native repository handling with > apt's native genbasedir. It is also more difficult to browse it in > relation to the binary RPMS built from it. *grumble* can't have it both ways. People want it out of the repot target, you want it in or gone completely, I'm unwilling to give it up. I had hoped that we could have a compromise with what I set up. It's far enough removed that anybody that doesn't want to sync it doesn't have to sync it, yet it's there for those of us that care about it. > Also it might make it easier to exclude all SRPMS with a single > --exclude line in rsync, but this is usually not what mirror admins > want. They would rather exclude only the os component and keep the > rest. This would be easier and more intuitive if there is a SRPMS > directory at the same level of each $basearch for each repository. And then we get into duplicating the SRPMS, as the SRPMS are the same across the $basearches. Why duplicate? > Also if you intend on keeping RH's massive amount of existing > "updates" SRPMS, there is no way of excluding those only. no there isn't. I can't make things perfect. There is no perfect. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Tue Jan 20 20:43:43 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Jan 2004 10:43:43 -1000 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201234.46724.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> <400D90C4.1090702@togami.com> <200401201234.46724.jkeating@j2solutions.net> Message-ID: <400D92FF.9030005@togami.com> Jesse Keating wrote: > >>Also it might make it easier to exclude all SRPMS with a single >>--exclude line in rsync, but this is usually not what mirror admins >>want. They would rather exclude only the os component and keep the >>rest. This would be easier and more intuitive if there is a SRPMS >>directory at the same level of each $basearch for each repository. > > > And then we get into duplicating the SRPMS, as the SRPMS are the same > across the $basearches. Why duplicate? > What do you mean by "SRPMS are the same across the $basearches"? Warren From jkeating at j2solutions.net Tue Jan 20 20:42:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 12:42:50 -0800 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <400D92FF.9030005@togami.com> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> Message-ID: <200401201242.50490.jkeating@j2solutions.net> On Tuesday 20 January 2004 12:43, Warren Togami wrote: > What do you mean by "SRPMS are the same across the $basearches"? When we branch out to x86_64, the srpm for the i386 version is the same as the srpm for the x86_64, so why would we keep separate SRPM directories? Am I wrong here? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Tue Jan 20 21:00:41 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Jan 2004 11:00:41 -1000 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201242.50490.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> Message-ID: <400D96F9.5050304@togami.com> Jesse Keating wrote: > On Tuesday 20 January 2004 12:43, Warren Togami wrote: > >>What do you mean by "SRPMS are the same across the $basearches"? > > > When we branch out to x86_64, the srpm for the i386 version is the same > as the srpm for the x86_64, so why would we keep separate SRPM > directories? Am I wrong here? > No. My proposal is to put a SRPM directory at the same level of each $basearch directory. http://download.fedoralegacy.org/redhat/7.2/updates/i386/ http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ http://download.fedoralegacy.org/fedora/1/updates/x86_64/ http://download.fedoralegacy.org/fedora/1/updates/i386/ http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ http://download.fedoralegacy.org/fedora/1/legacy-addons/x86_64/ http://download.fedoralegacy.org/fedora/1/legacy-addons/i386/ http://download.fedoralegacy.org/fedora/1/legacy-addons/SRPMS/ This arrangement allows the SRPMS of each distribution to be at the same level as the binaries. I also believe that it is a good thing that it matches the current Fedora Core development tree mirror structure. They designed well that way, with far more contributors than legacy-list in the mirror-list-d discussion. The current location for SRPMS has no relative path relation to the binary locations. Furthermore it lacks any precedent. The above structure is the most logical if you intend on including all SRPMS, and mirror maintainers need to set exclusions for individual SRPMS directories. Warren From warren at togami.com Tue Jan 20 21:01:58 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Jan 2004 11:01:58 -1000 Subject: legacy-addons ---> legacy-utils? Message-ID: <400D9746.5020101@togami.com> I was thinking... would it not be better to change "legacy-addons" to be "legacy-utils" instead? To me "legacy-utils" better describes the both the intent and purpose of the few packages contained within. Warren From arvand at sbcglobal.net Tue Jan 20 21:27:27 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Tue, 20 Jan 2004 13:27:27 -0800 Subject: legacy-addons ---> legacy-utils? In-Reply-To: <400D9746.5020101@togami.com> Message-ID: <200401202127.i0KLR4MI171450@pimout3-ext.prodigy.net> I agree with this. This could confuse some people (did confuse me for a second). I think utils fits the purpose of it much better. Regards, Arvand Sabetian -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of Warren Togami Sent: Tuesday, January 20, 2004 1:02 PM To: fedora-legacy-list at redhat.com Subject: legacy-addons ---> legacy-utils? I was thinking... would it not be better to change "legacy-addons" to be "legacy-utils" instead? To me "legacy-utils" better describes the both the intent and purpose of the few packages contained within. Warren -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Tue Jan 20 21:34:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 13:34:03 -0800 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <400D96F9.5050304@togami.com> References: <200401201024.47392.jkeating@j2solutions.net> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> Message-ID: <200401201334.07858.jkeating@j2solutions.net> On Tuesday 20 January 2004 13:00, Warren Togami wrote: > This arrangement allows the SRPMS of each distribution to be at the > same level as the binaries. I also believe that it is a good thing > that it matches the current Fedora Core development tree mirror > structure. They designed well that way, with far more contributors > than legacy-list in the mirror-list-d discussion. > > The current location for SRPMS has no relative path relation to the > binary locations. Furthermore it lacks any precedent. > > The above structure is the most logical if you intend on including > all SRPMS, and mirror maintainers need to set exclusions for > individual SRPMS directories. > > Warren Ah, ok. that makes sense. I'll re-arrange today. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From drees at greenhydrant.com Tue Jan 20 21:40:37 2004 From: drees at greenhydrant.com (David Rees) Date: Tue, 20 Jan 2004 13:40:37 -0800 (PST) Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <400D96F9.5050304@togami.com> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> Message-ID: <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> On Tue, January 20, 2004 at 1:00 pm, Warren Togami wrote: > Jesse Keating wrote: >> On Tuesday 20 January 2004 12:43, Warren Togami wrote: >>> What do you mean by "SRPMS are the same across the $basearches"? >> >> When we branch out to x86_64, the srpm for the i386 version is the same >> as the srpm for the x86_64, so why would we keep separate SRPM >> directories? Am I wrong here? > > No. My proposal is to put a SRPM directory at the same level of each > $basearch directory. > > http://download.fedoralegacy.org/redhat/7.2/updates/i386/ > http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ > > http://download.fedoralegacy.org/fedora/1/updates/x86_64/ > http://download.fedoralegacy.org/fedora/1/updates/i386/ > http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ > > http://download.fedoralegacy.org/fedora/1/legacy-addons/x86_64/ > http://download.fedoralegacy.org/fedora/1/legacy-addons/i386/ > http://download.fedoralegacy.org/fedora/1/legacy-addons/SRPMS/ > > This arrangement allows the SRPMS of each distribution to be at the same > level as the binaries. I also believe that it is a good thing that it > matches the current Fedora Core development tree mirror structure. They > designed well that way, with far more contributors than legacy-list in > the mirror-list-d discussion. > > The current location for SRPMS has no relative path relation to the > binary locations. Furthermore it lacks any precedent. > > The above structure is the most logical if you intend on including all > SRPMS, and mirror maintainers need to set exclusions for individual > SRPMS directories. I agree with the proposed directory structure above, it does make the most sense. If people don't want to mirror SRPMS they can setup their rsync scripts to exclude them, it's trivial to do so. -Dave From jkeating at j2solutions.net Tue Jan 20 21:34:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 13:34:41 -0800 Subject: legacy-addons ---> legacy-utils? In-Reply-To: <400D9746.5020101@togami.com> References: <400D9746.5020101@togami.com> Message-ID: <200401201334.41241.jkeating@j2solutions.net> On Tuesday 20 January 2004 13:01, Warren Togami wrote: > I was thinking... would it not be better to change "legacy-addons" to > be "legacy-utils" instead? To me "legacy-utils" better describes the > both the intent and purpose of the few packages contained within. Sure. Anything is better than just "legacy". -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From cwfox at fujitsu.com Wed Jan 21 00:11:48 2004 From: cwfox at fujitsu.com (Camron W. Fox) Date: Tue, 20 Jan 2004 14:11:48 -1000 Subject: /etc/yum.conf In-Reply-To: <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> Message-ID: > -----Original Message----- > From: fedora-legacy-list-admin at redhat.com > [mailto:fedora-legacy-list-admin at redhat.com]On Behalf Of Peter M. > Abraham > Sent: Tuesday, January 20, 2004 07:33 > To: fedora-legacy-list at redhat.com > Subject: /etc/yum.conf > > > Greetings: > > Can some one please post their /etc/yum.conf they are using with > Fedora for > RedHat 7.3? > > Thank you. > Alle, I wouldn't mind seeing this as well. Best Regards, Camron Camron W. Fox Hilo Office High Performance Computing Group Fujitsu America, INC. E-mail: cwfox at fujitsu.com Phone: (808) 934-4102 Pager: (808) 934-1290 Cell: (808) 937-5026 From jkeating at j2solutions.net Wed Jan 21 00:11:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 16:11:03 -0800 Subject: /etc/yum.conf In-Reply-To: <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> Message-ID: <200401201611.04090.jkeating@j2solutions.net> On Tuesday 20 January 2004 09:32, Peter M. Abraham wrote: > Greetings: > > Can some one please post their /etc/yum.conf they are using with > Fedora for RedHat 7.3? I'm sorry, "With Fedora" ? Do you mean with Fedora Legacy? Since Fedora Legacy hasn't put out a full release package yet, I wouldn't worry about it. Once we are ready to put out packages, our website will cover how to configure yum. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Wed Jan 21 00:13:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 16:13:40 -0800 Subject: Fedora Legacy Test Update Notification: Screen (new path) Message-ID: <200401201613.41000.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1187 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1187 2004-01-20 --------------------------------------------------------------------- Name : screen Versions : 7.2: 3.9.9-4, 7.3: 3.9.11-4, 8.0: 3.9.11-11 Summary : A screen manager that supports multiple logins on one terminal. Description : The screen utility allows you to have multiple logins on just one terminal. Screen is useful for users who telnet into a machine or are connected via a dumb terminal, but want to use more than just one login. Install the screen package if you need a screen manager that can support multiple logins on one terminal. --------------------------------------------------------------------- Update Information: CAN-2003-0972: Integer signedness error in ansi.c for GNU screen 4.0.1 and earlier, and 3.9.15 and earlier, allows local users to execute arbitrary code via a large number of ";" (semicolon) characters in escape sequences, which leads to a buffer overflow. --------------------------------------------------------------------- 7.2 changelog: * Fri Jan 02 2004 Jason Rohwedder 3.9.9-4.legacy - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 7.3 changelog: * Tue Jan 06 2004 Jason Rohwedder 3.9.11-4.legacy - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 8.0 changelog: * Wed Jan 07 2004 Christian Pearce 3.9.11-12.legacy - Spec updated and copied from Jason Rohwedder RedHat 7.2 and 7.3 spec files - Integer signedness error -> buffer overflow patch - http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 - CAN-2003-0972 - Added autoconf213 in BuildRequires --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 194fbeb6e1871aad733966eb03525ee3fa6b736e 7.2/updates-testing/SRPMS/screen-3.9.9-4.legacy.src.rpm 38752ec03ec07ab125ab495910861d0317dfe095 7.2/updates-testing/i386/screen-3.9.9-4.legacy.i386.rpm e22108165eeb8a4f2d6f078600117d2a3b5dc88d 7.3/updates-testing/SRPMS/screen-3.9.11-4.legacy.src.rpm 278a76f5b56d32bc983ab5dc388397c98dffe31c 7.3/updates-testing/i386/screen-3.9.11-4.legacy.i386.rpm 578b3166a0f647ac2a798ad81bdea43c9fe55c7b 8.0/updates-testing/SRPMS/screen-3.9.11-11.legacy.src.rpm c1422da61421e74a5a66e5404f1fcd33134c07e8 8.0/updates-testing/i386/screen-3.9.11-11.legacy.i386.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Wed Jan 21 00:15:20 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 16:15:20 -0800 Subject: Fedora Legacy Test Update Notification: ethereal (new path) Message-ID: <200401201615.20798.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1193 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1193 2004-01-20 --------------------------------------------------------------------- Name : ethereal Versions : 0.9.16-0 Summary : Network traffic analyzer. Description : Ethereal is a network traffic analyzer for Unix-ish operating systems. This package lays base for libpcap, a packet capture and filtering library, contains command-line utilities, and contains plugins and documentation for ethereal. A graphical user interface is packaged separately to GTK+ package. --------------------------------------------------------------------- Update Information: CAN-2003-1012: The SMB dissector in Ethereal before 0.10.0 allows remote attackers to cause a denial of service via a malformed SMB packet that triggers a segmentation fault during processing of Selected packets. CAN-2003-1013: The Q.931 dissector in Ethereal before 0.10.0, and Tethereal, allows remote attackers to cause a denial of service (crash) via a malformed Q.931, which triggers a null dereference. --------------------------------------------------------------------- Changelog: * Wed Jan 07 2004 Christian Pearce - Security fix CAN-2003-1012, CAN-2003-1013. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 9f1a7186859a95604431f52e137943f4a256b89f 7.2/updates-testing/SRPMS/ethereal-0.9.16-0.72.2.legacy.src.rpm 01e991b44ca40f432b639a9cdd25f46ab60a85e7 7.2/updates-testing/i386/ethereal-0.9.16-0.72.2.legacy.i386.rpm c263966f199db31ec551d9dff07363830f575bff 7.2/updates-testing/i386/ethereal-gnome-0.9.16-0.72.2.legacy.i386.rpm 1aebaffacc86561fea139b3dae351722eda761b9 7.3/updates-testing/SRPMS/ethereal-0.9.16-0.73.2.legacy.src.rpm db5326236fe91e7c84be611bbfdafd689187b32b 7.3/updates-testing/i386/ethereal-0.9.16-0.73.2.legacy.i386.rpm d78ca86ff9ca7adb7c0d006c43fe84d138bc87e0 7.3/updates-testing/i386/ethereal-gnome-0.9.16-0.73.2.legacy.i386.rpm 14350e74f4e261002bab186c942bc6caa788fce3 8.0/updates-testing/SRPMS/ethereal-0.9.16-0.80.2.legacy.src.rpm dc94ba568db4239f67cb191d4cf43a1d2f5a4fb7 8.0/updates-testing/i386/ethereal-0.9.16-0.80.2.legacy.i386.rpm a17d1098baf6b4ba2a8588e933a17d96629401cc 8.0/updates-testing/i386/ethereal-gnome-0.9.16-0.80.2.legacy.i386.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Freedom_Lover at pobox.com Wed Jan 21 05:51:18 2004 From: Freedom_Lover at pobox.com (Todd) Date: Wed, 21 Jan 2004 00:51:18 -0500 Subject: QA format for bugzilla Message-ID: <20040121055118.GL13633@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a recommended format or template for adding comments on QA to bugzilla? If there isn't, can someone point me to some examples of what are considered good QA comments in bugzilla? I've gone through the QA Checklist[1] on the tcpdump SRPM that Christian posted a few days ago for RH7.3 and would like to post that data so the package can get closer to being put into updates-testing. [1] http://www.fedora.us/wiki/FedoraLegacy/QAChecklist - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Liberty is always dangerous, but it is the safest thing we have. -- Harry Emerson Fosdick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFADhNTuv+09NZUB1oRAipDAJ9Y/FTTE/I4AoWrvFMRHk3/4jn40wCglqKX uVzvyPP5uIz64HQeNTapzdo= =rQ1K -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Jan 21 06:04:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jan 2004 22:04:31 -0800 Subject: QA format for bugzilla In-Reply-To: <20040121055118.GL13633@psilocybe.teonanacatl.org> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> Message-ID: <200401202204.32436.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 January 2004 21:51, Todd wrote: > Is there a recommended format or template for adding comments on QA to > bugzilla? If there isn't, can someone point me to some examples of > what are considered good QA comments in bugzilla? > > I've gone through the QA Checklist[1] on the tcpdump SRPM that > Christian posted a few days ago for RH7.3 and would like to post that > data so the package can get closer to being put into updates-testing. > > [1] http://www.fedora.us/wiki/FedoraLegacy/QAChecklist Thank you for your work! I've been using the following format: {RHL release} {sha1sum or md5sum of the srpm} {srpmfilename} {Work performed, comments, suggestions} {Vote for Publish or not} Put all of this in a file and gpg --clearsign the file. Paste the results of the clearsign into bugzilla. Add yourself to the bugzilla CC list if you wish. 7.3 e22108165eeb8a4f2d6f078600117d2a3b5dc88d screen-3.9.11-4.legacy.src.rpm Package sums check out, verified patch against CAN article. Patch applies cleanly during build, build completes. ldd comparison from previous release of package to this release matches up. Basic functionality tests pass. I vote for PUBLISH Once again, thank you for your work! - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADhZv4v2HLvE71NURAhE7AJ9/l9fEr33nYSDNMw3W/rGJ2mSTRwCePJlW AUa2WtyCTzaU7QqMc0IZMss= =p7tM -----END PGP SIGNATURE----- From warren at togami.com Wed Jan 21 10:19:53 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 00:19:53 -1000 Subject: QA format for bugzilla In-Reply-To: <200401202204.32436.jkeating@j2solutions.net> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> <200401202204.32436.jkeating@j2solutions.net> Message-ID: <400E5249.3000403@togami.com> Jesse Keating wrote: > {RHL release} > {sha1sum or md5sum of the srpm} {srpmfilename} > {Work performed, comments, suggestions} > {Vote for Publish or not} > > Put all of this in a file and gpg --clearsign the file. Paste the results > of the clearsign into bugzilla. Add yourself to the bugzilla CC list if > you wish. > Perhaps include references & links to authoritative information, like upstream patches and advisories. This is the kind of information that the packager should post in their initial bugzilla report too, in order to aid reviewers in the verification process. Links to OTHER DISTRIBUTION sources/patches/advisories who patched the same thing would also be helpful in backing up a claim of "see, they did it, so we're probably okay doing it too." Warren From warren at togami.com Wed Jan 21 11:21:53 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 01:21:53 -1000 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> Message-ID: <400E60D1.6030208@togami.com> If everyone is happy with the mirror structure after these latest changes, then you should work on QA and publication of corresponding yum and apt packages ASAP. http://bugzilla.fedora.us/show_bug.cgi?id=1180 Make sure you sync the legacy apt to the latest version here, and perhaps talk to Panu about his /etc/apt/sources.list.d./mirror-selector.conf change since that is pretty fundamental beyond this current package. Then talk with the webmaster people about setting a permanent location on www.fedoralegacy.org for the mirror list. http://www.fedora.us/mirrorlists/ fedora.us is using these kind of filenames for our mirror list. I recommend using something similar like fedoralegacy.org-rh72-mirrors.list Warren From warren at togami.com Wed Jan 21 12:00:22 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 02:00:22 -1000 Subject: Proposal: Optional libsafe add-on? Message-ID: <400E69D6.4010502@togami.com> Proposal: Optional libsafe add-on? I personally have been using libsafe on all of my RH7.x, RH8 and RH9 servers with apparently no ill effects in these past years [1]. libsafe intercepts many of the potentially dangerous glibc calls like string operations, and replaces it with functionally equivalent functions. If it detects an overflow or format string exception, the process group is sent SIGKILL and a /var/log/secure entry is generated. The following list of functions is from the libsafe manpage. strcpy(char *dest, const char *src) strpcpy(char *dest, const char *src) wcscpy(wchar_t *dest, const wchar_t *src) wcpcpy(wchar_t *dest, const wchar_t *src) May overflow the dest buffer. strcat(char *dest, const char *src) wcscat(wchar_t *dest, const wchar_t *src) May overflow the dest buffer. getwd(char *buf) May overflow the buf buffer. gets(char *s) May overflow the s buffer. [vf]scanf(const char *format, ...) May overflow its arguments. realpath(char *path, char resolved_path[]) May overflow the path buffer. [v]sprintf(char *str, const char *format, ...) May overflow the str buffer. May exploit "%n". What I find especially attractive about libsafe is that it is exceedingly easy to install. Simply install the libsafe RPM and restart your daemons, and they should be protected. It is true that it is not COMPLETE protection, higher overhead than exec-shield, and not as paranoid protection as propolice. [2] However due to this easy-to-install-and-use nature and the fact that it provides SOME protection, I feel it is better than nothing. For Legacy I am thinking to either put libsafe into the legacy-utils channel for sysadmins to install at their option, or keep it on the webpage so they need to install it manually only after reading how it works, and associated warnings about potential BAD BEHAVIOR and to test again after uninstalling it if weird stuff happens. [3] The must-install-manually-from-webpage option may be best due to [1] footnote below. https://bugzilla.fedora.us/show_bug.cgi?id=163 The libsafe package needs fixing if Legacy wants to use it. It must remain the old fedora.us-style package naming in order to not conflict with fedora.us' libsafe. Thoughts? Warren Togami warren at togami.com [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89145 RH9's glibc introduced some behavior where libsafe would cause segfaults in this case of useradd where uninitialized memory was being read. It turned out that selinux also caused this segfault, so the problem has finally been patched in rawhide for FC2. If Legacy pushes an optional libsafe within the legacy-utils channel in April 2004 for RH9, it should require also optional shadow-utils upgrade to prevent this useradd segfault problem. QA needs to match ldd output in order to verify that no functionality was lost due to missing BuildRequires. [2] http://www.research.ibm.com/trl/projects/security/ssp/ propolice is IBM research's gcc extensions for all sorts of security protection stuff in the resulting binaries when coupled with patched glibc. They claim it is far more complete than stackguard compiler (Immunix) while lower overhead than any other protection mechanism. OpenBSD uses propolice compiler by default now I believe. [3] While I personally have never run into any bad behavior due to libsafe in RH7.x through RH9 other than the above shadow-utils problem, I personally use mainly software distributed in the RH core distribution and fedora.us. Java seems fine too. I have zero experience running stuff like Oracle or other massive proprietary software... but arguably those folks should have moved to RHEL or other better commercially supported distributions a long time ago anyway. From warren at togami.com Wed Jan 21 12:16:45 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 02:16:45 -1000 Subject: small correction Message-ID: <400E6DAD.6070709@togami.com> The FAQ says "Initially we will only be supporting x86 architectures. With the Fedora Core releases, x86_64 and amd64 architectures will become supported as well." x86_64 *is* the amd64 architecture, but RH and the kernel calls it x86_64. I would change the above sentence to read: "Initially we will only be supporting x86 architectures. With the Fedora Core releases, x86_64 (AMD64) architecture will also become supported, as well as other archs if they become mainstream Fedora Core in the future." From ingo at auroralinux.org Wed Jan 21 12:49:39 2004 From: ingo at auroralinux.org (Ingo T. Storm) Date: Wed, 21 Jan 2004 13:49:39 +0100 Subject: Final(?) Fedora Legacy Mirror Layout References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> Message-ID: <010301c3e01d$084970d0$be041dac@ingotee2> > > http://download.fedoralegacy.org/redhat/7.2/updates/i386/ > > http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ Please forgive me if this question is really stupid: I understand that i386 is a "$basearch" here, but is it really intentional that you have e.g. i686 and noarch packages in a directory "i386"? Ingo From warren at togami.com Wed Jan 21 13:40:09 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 03:40:09 -1000 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <010301c3e01d$084970d0$be041dac@ingotee2> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> <010301c3e01d$084970d0$be041dac@ingotee2> Message-ID: <400E8139.9070209@togami.com> Ingo T. Storm wrote: >>>http://download.fedoralegacy.org/redhat/7.2/updates/i386/ >>>http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ > > > Please forgive me if this question is really stupid: I understand that i386 > is a "$basearch" here, but is it really intentional that you have e.g. i686 > and noarch packages in a directory "i386"? > > Ingo Doesn't rawhide do this now? I suppose it could be renamed x86, but we've been calling it i386 for so long now... I personally don't feel strongly either way. Warren From andy.henson.fedora at zexia.co.uk Wed Jan 21 13:45:00 2004 From: andy.henson.fedora at zexia.co.uk (Andy Henson) Date: Wed, 21 Jan 2004 13:45 +0000 (GMT Standard Time) Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <010301c3e01d$084970d0$be041dac@ingotee2> Message-ID: > it really intentional that you have e.g. i686 and noarch packages in a directory "i386"? It's sensible because both i686 and noarch packages run on i386 base architecture machines. Andy From skvidal at phy.duke.edu Wed Jan 21 13:50:15 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 21 Jan 2004 08:50:15 -0500 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400E69D6.4010502@togami.com> References: <400E69D6.4010502@togami.com> Message-ID: <1074693014.9060.25.camel@binkley> On Wed, 2004-01-21 at 07:00, Warren Togami wrote: > Proposal: Optional libsafe add-on? > > I personally have been using libsafe on all of my RH7.x, RH8 and RH9 > servers with apparently no ill effects in these past years [1]. libsafe > intercepts many of the potentially dangerous glibc calls like string > operations, and replaces it with functionally equivalent functions. If > it detects an overflow or format string exception, the process group is > sent SIGKILL and a /var/log/secure entry is generated. The following > list of functions is from the libsafe manpage. Modifying the world as an 'option' for legacy updates seems like a bad idea, a confusing idea for users, and generally a waste of time. If I've got older machines I want them to be left alone and just have security patches applied. I don't want to be putting brand new things on there. -sv From warren at togami.com Wed Jan 21 14:12:07 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 04:12:07 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <1074693014.9060.25.camel@binkley> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> Message-ID: <400E88B7.3040204@togami.com> seth vidal wrote: > On Wed, 2004-01-21 at 07:00, Warren Togami wrote: > >>Proposal: Optional libsafe add-on? >> >>I personally have been using libsafe on all of my RH7.x, RH8 and RH9 >>servers with apparently no ill effects in these past years [1]. libsafe >>intercepts many of the potentially dangerous glibc calls like string >>operations, and replaces it with functionally equivalent functions. If >>it detects an overflow or format string exception, the process group is >> sent SIGKILL and a /var/log/secure entry is generated. The following >>list of functions is from the libsafe manpage. > > > Modifying the world as an 'option' for legacy updates seems like a bad > idea, a confusing idea for users, and generally a waste of time. If I've > got older machines I want them to be left alone and just have security > patches applied. I don't want to be putting brand new things on there. > > -sv > This is why I suggested putting it on the webpage with lots of documentation and manual installation only. The documentation would to people NOT to use it unless they really know what they are doing and willing to monitor their server for a while. Warren From skvidal at phy.duke.edu Wed Jan 21 14:11:20 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 21 Jan 2004 09:11:20 -0500 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400E88B7.3040204@togami.com> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> Message-ID: <1074694279.9060.37.camel@binkley> > > > > > > Modifying the world as an 'option' for legacy updates seems like a bad > > idea, a confusing idea for users, and generally a waste of time. If I've > > got older machines I want them to be left alone and just have security > > patches applied. I don't want to be putting brand new things on there. > > > > -sv > > > > This is why I suggested putting it on the webpage with lots of > documentation and manual installation only. The documentation would to > people NOT to use it unless they really know what they are doing and > willing to monitor their server for a while. > Why waste all the time building the packages and writing up the documentation? People should be working on new things for FC2 and not screwing around with old distributions. -sv From warren at togami.com Wed Jan 21 14:23:03 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 04:23:03 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <1074694279.9060.37.camel@binkley> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> <1074694279.9060.37.camel@binkley> Message-ID: <400E8B47.9010707@togami.com> seth vidal wrote: >>> >>>Modifying the world as an 'option' for legacy updates seems like a bad >>>idea, a confusing idea for users, and generally a waste of time. If I've >>>got older machines I want them to be left alone and just have security >>>patches applied. I don't want to be putting brand new things on there. >>> >>>-sv >>> >> >>This is why I suggested putting it on the webpage with lots of >>documentation and manual installation only. The documentation would to >>people NOT to use it unless they really know what they are doing and >>willing to monitor their server for a while. >> > > > Why waste all the time building the packages and writing up the > documentation? > > People should be working on new things for FC2 and not screwing around > with old distributions. > > -sv Shrug. Most of the work is already done, and it has worked great for me on these old distributions for years. I'm willing to do it. I am just wondering if folks here think it is a proper thing to offer on the Legacy web page or not. Warren From pearcec at commnav.com Wed Jan 21 15:18:26 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 15:18:26 GMT Subject: Proposal: Optional libsafe add-on? Message-ID: <47736.209.50.130.84.1074698306.commnav@home.commnav.com> I never used it but seems like a good idea. Especially if we are slowed in releases of a fixed. It might add some extra protection while we wait for a release. If libsafe in FC? -- Christian Pearce http://www.commnav.com Warren Togami said: > > seth vidal wrote: > >>> > >>>Modifying the world as an 'option' for legacy updates seems like a bad > >>>idea, a confusing idea for users, and generally a waste of time. If I've > >>>got older machines I want them to be left alone and just have security > >>>patches applied. I don't want to be putting brand new things on there. > >>> > >>>-sv > >>> > >> > >>This is why I suggested putting it on the webpage with lots of > >>documentation and manual installation only. The documentation would to > >>people NOT to use it unless they really know what they are doing and > >>willing to monitor their server for a while. > >> > > > > > > Why waste all the time building the packages and writing up the > > documentation? > > > > People should be working on new things for FC2 and not screwing around > > with old distributions. > > > > -sv > > Shrug. Most of the work is already done, and it has worked great for me > on these old distributions for years. I'm willing to do it. I am just > wondering if folks here think it is a proper thing to offer on the > Legacy web page or not. > > Warren > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From john.pybus at zoology.oxford.ac.uk Wed Jan 21 15:23:48 2004 From: john.pybus at zoology.oxford.ac.uk (John Pybus) Date: Wed, 21 Jan 2004 15:23:48 +0000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <1074694279.9060.37.camel@binkley> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> <1074694279.9060.37.camel@binkley> Message-ID: <400E9984.5060004@zoo.ox.ac.uk> seth vidal wrote: >>> >>>Modifying the world as an 'option' for legacy updates seems like a bad >>>idea, a confusing idea for users, and generally a waste of time. If I've >>>got older machines I want them to be left alone and just have security >>>patches applied. I don't want to be putting brand new things on there. >>> >>>-sv >>> >> >>This is why I suggested putting it on the webpage with lots of >>documentation and manual installation only. The documentation would to >>people NOT to use it unless they really know what they are doing and >>willing to monitor their server for a while. >> > > > Why waste all the time building the packages and writing up the > documentation? > > People should be working on new things for FC2 and not screwing around > with old distributions. Hmm, I feel moved to stick my oar in here: 1) People will work on what they're motivated to, regardless of how this fits redhat's, the Fedora Project's, or anyone else's, plans and aims, and whether this is the best overall use of resources or not. 2) There are still plenty of rh7.x/rh8 installations in the wild. It does the reputation of the RH/FC line (and linux as a whole) no good if these are rooted. The legacy project, and its aim of providing security updates to the original packages, only exists to support people in keeping their systems safe. By mitigating the consequences of many possible vulnerabilities, this package, potentially, contributes more to keeping legacy installations secure than a whole bunch of updated rpms. So, is it surprising that those responsible for legacy systems, who use and contribute to fedora-legacy, also care about other protective measures such as this? 3) Personally, I think this is great idea, and that Warren's proposal for a well described manual installation is spot on. Yours, John From jpdalbec at ysu.edu Wed Jan 21 15:32:39 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 21 Jan 2004 10:32:39 -0500 Subject: /etc/yum.conf In-Reply-To: <20040120214104.25015.83129.Mailman@listman.back-rdu.redhat.com> References: <20040120214104.25015.83129.Mailman@listman.back-rdu.redhat.com> Message-ID: <400E9B97.9030901@ysu.edu> > Date: Tue, 20 Jan 2004 12:32:50 -0500 > To: fedora-legacy-list at redhat.com > From: "Peter M. Abraham" > Subject: /etc/yum.conf > Reply-To: fedora-legacy-list at redhat.com > > Greetings: > > Can some one please post their /etc/yum.conf they are using with Fedora for > RedHat 7.3? > > Thank you. If you install the yum package from (e.g.) http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ /etc/yum.conf should be set up for you already. Failing that, you can use --- cut here --- # $Id: yum-rh.conf,v 1.2 2003/09/18 16:29:06 dude Exp $ [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release gpgcheck=1 tolerant=1 exactarch=1 [os] name=Fedora Project RHL 7.3 Stock OS Mirror Repository baseurl=http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.os [updates] name=Fedora Project RHL 7.3 Updates baseurl=http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.updates [legacy] name=Fedora Project RHL 7.3 Legacy Tools baseurl=http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy --- cut here --- You may wish to use a different mirror. HTH, John From warren at togami.com Wed Jan 21 15:40:41 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 05:40:41 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <47736.209.50.130.84.1074698306.commnav@home.commnav.com> References: <47736.209.50.130.84.1074698306.commnav@home.commnav.com> Message-ID: <400E9D79.6090607@togami.com> Christian Pearce wrote: > I never used it but seems like a good idea. Especially if we are > slowed in releases of a fixed. It might add some extra protection > while we wait for a release. If libsafe in FC? -- Christian Pearce > http://www.commnav.com > No, libsafe is unsuitable and unnecessary for FC because of exec-shield. I personally use it within FC1 chroots that are unprotected by exec-shield though. Have not run FC1 long enough with libsafe to determine if it is stable or not. Works for me in RH7.x, 8 and 9 though. Warren From warren at togami.com Wed Jan 21 15:42:01 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 05:42:01 -1000 Subject: /etc/yum.conf In-Reply-To: <400E9B97.9030901@ysu.edu> References: <20040120214104.25015.83129.Mailman@listman.back-rdu.redhat.com> <400E9B97.9030901@ysu.edu> Message-ID: <400E9DC9.5030107@togami.com> John Dalbec wrote: >> Date: Tue, 20 Jan 2004 12:32:50 -0500 >> To: fedora-legacy-list at redhat.com >> From: "Peter M. Abraham" >> Subject: /etc/yum.conf >> Reply-To: fedora-legacy-list at redhat.com >> >> Greetings: >> >> Can some one please post their /etc/yum.conf they are using with >> Fedora for RedHat 7.3? >> >> Thank you. > > > If you install the yum package from (e.g.) > http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ > /etc/yum.conf should be set up for you already. > Be aware that fedora.us 7.2 and 7.3 will disappear real soon. Use the now official and permanent download.fedoralegacy.org please. Warren From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 21 15:36:05 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Jan 2004 16:36:05 +0100 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <010301c3e01d$084970d0$be041dac@ingotee2> References: <200401201024.47392.jkeating@j2solutions.net> <200401201234.46724.jkeating@j2solutions.net> <400D92FF.9030005@togami.com> <200401201242.50490.jkeating@j2solutions.net> <400D96F9.5050304@togami.com> <3895.208.48.139.163.1074634837.squirrel@www.greenhydrant.com> <010301c3e01d$084970d0$be041dac@ingotee2> Message-ID: <20040121163605.25ee5063@python.freshrpms.net> Ingo T. Storm wrote : > > > http://download.fedoralegacy.org/redhat/7.2/updates/i386/ > > > http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/ > > Please forgive me if this question is really stupid: I understand that > i386 is a "$basearch" here, but is it really intentional that you have > e.g. i686 and noarch packages in a directory "i386"? That's typically the difference between "arch" and "basearch". If the structure had been divided per "arch" instead of "basearch", it would have made things unnecessarily complex for updates tools (and users) as someone with an i686 machine would have needed to configure his tool to fetch "i386", "i686" and "noarch". Think of the current Red Hat Linux "updates" tree where you need to fetch your i686 kernel in one directory, and the corresponding kernel-source in another. It's much easier to split per "basearch" and just put all x86 packages in "i386" and hardlink "noarch" binary packages across all directories. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.17 0.12 0.25 From jkeating at j2solutions.net Wed Jan 21 16:11:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 08:11:00 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400E69D6.4010502@togami.com> References: <400E69D6.4010502@togami.com> Message-ID: <200401210811.01546.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 04:00, Warren Togami wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=163 > The libsafe package needs fixing if Legacy wants to use it. It must > remain the old fedora.us-style package naming in order to not conflict > with fedora.us' libsafe. > > Thoughts? I personally don't like the idea of more addons for legacy systems. The goal has been to change as little as possible. Starting an addon trend may wind up getting us inundated with requests to add this, or update that. I do think that it would fit in with Fedora.us, although you've stated that you didn't want to do extras for the older releases. I suppose I'll leave it up to the community to see if anybody would be interested in seeing this show up on the page, but frankly, we've got enough to do w/out adding optional packages to the mix. There are plenty of packages to QA and a few updates-testing to test and get ready for full release. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADqSU4v2HLvE71NURAlRlAKCFZLHIuPR/jD7h3oj3bjLbsbdy8gCfV5Ae rA0CGZ/tdyC4cLpb6tz6DFE= =xqGs -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Jan 21 16:15:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 08:15:45 -0800 Subject: Any mirror changes? Message-ID: <200401210815.46836.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please browse http://download.fedoralegacy.org for any last layout changes. If nobody responds by this afternoon, I will consider the layout agreed upon, and changes will take an act of god. (; - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADqWx4v2HLvE71NURAmAEAKCeWOCf001iABXYUN1Swp4zo1BNUwCfaW1G iyerhO5Rl0Um1ahZd9IaSNA= =5H4f -----END PGP SIGNATURE----- From pearcec at commnav.com Wed Jan 21 16:32:06 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 16:32:06 GMT Subject: Any mirror changes? Message-ID: <48111.209.50.130.84.1074702726.commnav@home.commnav.com> As a bystander to this whole selection of mirroring setup process. I am happy with what turned out. Though I don't know all the implications. Nothing a little Cfengine can't fix. ;) PUBLISH Let's get this thing rolling. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Please browse http://download.fedoralegacy.org for any last layout changes. > If nobody responds by this afternoon, I will consider the layout agreed > upon, and changes will take an act of god. (; > > - -- > Jesse Keating RHCE MCSE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFADqWx4v2HLvE71NURAmAEAKCeWOCf001iABXYUN1Swp4zo1BNUwCfaW1G > iyerhO5Rl0Um1ahZd9IaSNA= > =5H4f > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From warren at togami.com Wed Jan 21 16:36:50 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 06:36:50 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <200401210811.01546.jkeating@j2solutions.net> References: <400E69D6.4010502@togami.com> <200401210811.01546.jkeating@j2solutions.net> Message-ID: <400EAAA2.3010803@togami.com> Jesse Keating wrote: > On Wednesday 21 January 2004 04:00, Warren Togami wrote: > >>>https://bugzilla.fedora.us/show_bug.cgi?id=163 >>>The libsafe package needs fixing if Legacy wants to use it. It must >>>remain the old fedora.us-style package naming in order to not conflict >>>with fedora.us' libsafe. >>> >>>Thoughts? > > > I personally don't like the idea of more addons for legacy systems. The > goal has been to change as little as possible. Starting an addon trend > may wind up getting us inundated with requests to add this, or update > that. I do think that it would fit in with Fedora.us, although you've > stated that you didn't want to do extras for the older releases. > libsafe I am suggesting as a special case NOT for the legacy-utils repository, but for advanced users on the web page only. It is not suitable for a fire-and-forget solution and must be monitored for a while. My earlier post suggested a very short list of extremely simple, yet useful add-ons for typical servers for the legacy-utils repository. legacy-utils add-on packages are only by consensus and can easily be shot down. This is the list of add-ons that I am proposing: bonnie++ Very useful stability test for servers chkrootkit Security checking for servers ddrescue Data recovery for servers hardlink Space consolidation for mirror servers iptstate Very simple Netfilter stateful top * > I suppose I'll leave it up to the community to see if anybody would be > interested in seeing this show up on the page, but frankly, we've got > enough to do w/out adding optional packages to the mix. There are plenty > of packages to QA and a few updates-testing to test and get ready for full > release. > You make a good point about 'plenty of other work to do', but in this case libsafe is already well tested and unchanged for almost a year. The only real reason I can see for not putting it somewhere on the Legacy webpage is if people find serious functionality regressions caused by libsafe on these distributions. I personally am not aware of any now, but I invite others post reproduction procedures here. * Might be unstable due to an old ncurses bug. Needs extensive testing before inclusion. Probably just kill this from the list to be on the safe side. Warren From heinlein at cse.ogi.edu Wed Jan 21 16:43:46 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Wed, 21 Jan 2004 08:43:46 -0800 (PST) Subject: Any mirror changes? In-Reply-To: <200401210815.46836.jkeating@j2solutions.net> References: <200401210815.46836.jkeating@j2solutions.net> Message-ID: On Wed, 21 Jan 2004, Jesse Keating wrote: > Please browse http://download.fedoralegacy.org for any last layout > changes. If nobody responds by this afternoon, I will consider the > layout agreed upon, and changes will take an act of god. (; Jesse -- It looks really good to me: easy to navigate, fairly self-explanatory for anyone who's worked with Red Hat systems to any extent, etc. So ... +1 from me. :-) -- Paul Heinlein From drees at greenhydrant.com Wed Jan 21 17:43:37 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 09:43:37 -0800 Subject: /etc/yum.conf In-Reply-To: <400E9DC9.5030107@togami.com> References: <20040120214104.25015.83129.Mailman@listman.back-rdu.redhat.com> <400E9B97.9030901@ysu.edu> <400E9DC9.5030107@togami.com> Message-ID: <400EBA49.7030906@greenhydrant.com> Warren Togami wrote, On 1/21/2004 7:42 AM: > John Dalbec wrote: >> If you install the yum package from (e.g.) >> http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ >> /etc/yum.conf should be set up for you already. > > Be aware that fedora.us 7.2 and 7.3 will disappear real soon. Use the > now official and permanent download.fedoralegacy.org please. Do you know if mirrors.kernel.org will also be mirroring download.fedoralegacy.org? It's consistently one of the highest available and fastest download sites for me. -Dave From jkeating at j2solutions.net Wed Jan 21 17:43:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 09:43:42 -0800 Subject: /etc/yum.conf In-Reply-To: <400EBA49.7030906@greenhydrant.com> References: <20040120214104.25015.83129.Mailman@listman.back-rdu.redhat.com> <400E9DC9.5030107@togami.com> <400EBA49.7030906@greenhydrant.com> Message-ID: <200401210943.42359.jkeating@j2solutions.net> On Wednesday 21 January 2004 09:43, David Rees wrote: > Do you know if mirrors.kernel.org will also be mirroring > download.fedoralegacy.org? It's consistently one of the highest > available and fastest download sites for me. I have not been in contact with them yet. I wanted to finalize the master mirror layout prior to contacting hosts for mirrors. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From drees at greenhydrant.com Wed Jan 21 17:50:24 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 09:50:24 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400E9984.5060004@zoo.ox.ac.uk> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> <1074694279.9060.37.camel@binkley> <400E9984.5060004@zoo.ox.ac.uk> Message-ID: <400EBBE0.1090608@greenhydrant.com> John Pybus wrote, On 1/21/2004 7:23 AM: > 1) People will work on what they're motivated to, regardless of how this > fits redhat's, the Fedora Project's, or anyone else's, plans and aims, > and whether this is the best overall use of resources or not. > > 2) There are still plenty of rh7.x/rh8 installations in the wild. It > does the reputation of the RH/FC line (and linux as a whole) no good if > these are rooted. The legacy project, and its aim of providing security > updates to the original packages, only exists to support people in > keeping their systems safe. By mitigating the consequences of many > possible vulnerabilities, this package, potentially, contributes more to > keeping legacy installations secure than a whole bunch of updated rpms. > So, is it surprising that those responsible for legacy systems, who > use and contribute to fedora-legacy, also care about other protective > measures such as this? > > 3) Personally, I think this is great idea, and that Warren's proposal > for a well described manual installation is spot on. What he said. ;) One thing to note: Warren, you mention that you would like to keep libsafe as a manual upgrade. I would prefer to see it in it's own channel in case we do need to upgrade it. Is the RPM mentioned in the libsafe bug report the one to check out? -Dave From warren at togami.com Wed Jan 21 17:53:32 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 07:53:32 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400EBBE0.1090608@greenhydrant.com> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> <1074694279.9060.37.camel@binkley> <400E9984.5060004@zoo.ox.ac.uk> <400EBBE0.1090608@greenhydrant.com> Message-ID: <400EBC9C.5040701@togami.com> David Rees wrote: > John Pybus wrote, On 1/21/2004 7:23 AM: > >> 1) People will work on what they're motivated to, regardless of how this >> fits redhat's, the Fedora Project's, or anyone else's, plans and aims, >> and whether this is the best overall use of resources or not. >> >> 2) There are still plenty of rh7.x/rh8 installations in the wild. It >> does the reputation of the RH/FC line (and linux as a whole) no good if >> these are rooted. The legacy project, and its aim of providing security >> updates to the original packages, only exists to support people in >> keeping their systems safe. By mitigating the consequences of many >> possible vulnerabilities, this package, potentially, contributes more to >> keeping legacy installations secure than a whole bunch of updated rpms. >> So, is it surprising that those responsible for legacy systems, who >> use and contribute to fedora-legacy, also care about other protective >> measures such as this? >> >> 3) Personally, I think this is great idea, and that Warren's proposal >> for a well described manual installation is spot on. > > > What he said. ;) > > One thing to note: Warren, you mention that you would like to keep > libsafe as a manual upgrade. I would prefer to see it in it's own > channel in case we do need to upgrade it. > > Is the RPM mentioned in the libsafe bug report the one to check out? > > -Dave Oh good idea, maybe apt/yum repository on www.fedoralegacy.org itself ONLY for libsafe. Yes please look at the bugzilla report. Only clean text replace for removal is necessary to publish that. Warren From drees at greenhydrant.com Wed Jan 21 17:55:05 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 09:55:05 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400EAAA2.3010803@togami.com> References: <400E69D6.4010502@togami.com> <200401210811.01546.jkeating@j2solutions.net> <400EAAA2.3010803@togami.com> Message-ID: <400EBCF9.7010407@greenhydrant.com> Warren Togami wrote, On 1/21/2004 8:36 AM: > > My earlier post suggested a very short list of extremely simple, yet > useful add-ons for typical servers for the legacy-utils repository. > legacy-utils add-on packages are only by consensus and can easily be > shot down. This is the list of add-ons that I am proposing: > > bonnie++ Very useful stability test for servers > chkrootkit Security checking for servers > ddrescue Data recovery for servers > hardlink Space consolidation for mirror servers > iptstate Very simple Netfilter stateful top * I feel that these utilities would be useful to have in the legacy-utils repository. -Dave From drees at greenhydrant.com Wed Jan 21 18:05:44 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 10:05:44 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400EBC9C.5040701@togami.com> References: <400E69D6.4010502@togami.com> <1074693014.9060.25.camel@binkley> <400E88B7.3040204@togami.com> <1074694279.9060.37.camel@binkley> <400E9984.5060004@zoo.ox.ac.uk> <400EBBE0.1090608@greenhydrant.com> <400EBC9C.5040701@togami.com> Message-ID: <400EBF78.1080105@greenhydrant.com> Warren Togami wrote, On 1/21/2004 9:53 AM: >> >> One thing to note: Warren, you mention that you would like to keep >> libsafe as a manual upgrade. I would prefer to see it in it's own >> channel in case we do need to upgrade it. >> >> Is the RPM mentioned in the libsafe bug report the one to check out? > > Oh good idea, maybe apt/yum repository on www.fedoralegacy.org itself > ONLY for libsafe. That sounds good, but I could also see us using the same repository for other RPMs which fall into the same boat as libsafe. It is probably safer to keep it separate. I wish that yum had the same capabilities as apt does when it comes to only using a repository for specific packages. [1] > Yes please look at the bugzilla report. Only clean text replace for > removal is necessary to publish that. Sorry if I'm being dense, but what does "Only clean text replace for removal" mean? -Dave [1] For example, on some Debian machines I run, I have the following line in my apt sources.list deb http://www.backports.org/debian stable smartmontools This allows me to grab smartmontools from the backports.org without grabbing the whole repository. From drees at greenhydrant.com Wed Jan 21 18:12:40 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 10:12:40 -0800 Subject: QA, GPG and "replay attack" notes Message-ID: <400EC118.9000502@greenhydrant.com> Just to bring this to everyone's attention, I made the mistake of publishing a few notes to bugs during the QA process which were vulnerable to "replay attacks". In other words, someone could cut and paste my short messages to misconstrue what I meant to say. Have a look at the tcpdump bug for what NOT to do: ;) https://bugzilla.fedora.us/show_bug.cgi?id=1222 It is mentioned in the Fedora QA process, however, I think it should be made to stand out a bit more as I think it is something easy to miss for someone new to the QA process and GPG in general. -Dave From jpdalbec at ysu.edu Wed Jan 21 18:19:22 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 21 Jan 2004 13:19:22 -0500 Subject: /etc/yum.conf In-Reply-To: <20040121161501.32131.7495.Mailman@listman.back-rdu.redhat.com> References: <20040121161501.32131.7495.Mailman@listman.back-rdu.redhat.com> Message-ID: <400EC2AA.3020109@ysu.edu> > Message: 20 > Date: Wed, 21 Jan 2004 10:32:39 -0500 > From: John Dalbec > To: fedora-legacy-list at redhat.com > Subject: Re: /etc/yum.conf > Reply-To: fedora-legacy-list at redhat.com > > >>Date: Tue, 20 Jan 2004 12:32:50 -0500 >>To: fedora-legacy-list at redhat.com >>From: "Peter M. Abraham" >>Subject: /etc/yum.conf >>Reply-To: fedora-legacy-list at redhat.com >> >>Greetings: >> >>Can some one please post their /etc/yum.conf they are using with Fedora for >>RedHat 7.3? >> >>Thank you. > > > If you install the yum package from (e.g.) > http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ > /etc/yum.conf should be set up for you already. > > Failing that, you can use > --- cut here --- > # $Id: yum-rh.conf,v 1.2 2003/09/18 16:29:06 dude Exp $ > > [main] > cachedir=/var/cache/yum > debuglevel=2 > logfile=/var/log/yum.log > pkgpolicy=newest > distroverpkg=redhat-release > gpgcheck=1 > tolerant=1 > exactarch=1 > > --- cut here --- > > You may wish to use a different mirror. > HTH, > John > > > > Date: Wed, 21 Jan 2004 05:42:01 -1000 > From: Warren Togami > To: fedora-legacy-list at redhat.com > Subject: Re: /etc/yum.conf > Reply-To: fedora-legacy-list at redhat.com > > John Dalbec wrote: > >>>Date: Tue, 20 Jan 2004 12:32:50 -0500 >>>To: fedora-legacy-list at redhat.com >>>From: "Peter M. Abraham" >>>Subject: /etc/yum.conf >>>Reply-To: fedora-legacy-list at redhat.com >>> >>>Greetings: >>> >>>Can some one please post their /etc/yum.conf they are using with >>>Fedora for RedHat 7.3? >>> >>>Thank you. >> >> >>If you install the yum package from (e.g.) >>http://mirrors.kernel.org/fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ >>/etc/yum.conf should be set up for you already. >> > > > Be aware that fedora.us 7.2 and 7.3 will disappear real soon. Use the > now official and permanent download.fedoralegacy.org please. Is that mirrored anywhere? Also it does not appear to have a yum RPM in the legacy-utils directory. I guess the relevant section of yum.conf should read: --- cut here --- [os] name=Fedora Project RHL 7.3 OS baseurl=http://download.fedoralegacy.org/redhat/7.3/os/i386 [updates] name=Fedora Project RHL 7.3 Updates baseurl=http://download.fedoralegacy.org/redhat/7.3/updates/i386 [legacy] name=Fedora Project RHL 7.3 Legacy Utilities baseurl=http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386 --- cut here --- HTH, John From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 21 18:30:28 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Jan 2004 19:30:28 +0100 Subject: Any mirror changes? In-Reply-To: <200401210815.46836.jkeating@j2solutions.net> References: <200401210815.46836.jkeating@j2solutions.net> Message-ID: <20040121193028.7471497a@python.freshrpms.net> Jesse Keating wrote : > Please browse http://download.fedoralegacy.org for any last layout > changes. If nobody responds by this afternoon, I will consider the > layout agreed upon, and changes will take an act of god. (; Seems to be what we agreed on. Good to go now :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.34 0.36 0.27 From jkeating at j2solutions.net Wed Jan 21 18:29:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 10:29:36 -0800 Subject: /etc/yum.conf In-Reply-To: <400EC2AA.3020109@ysu.edu> References: <20040121161501.32131.7495.Mailman@listman.back-rdu.redhat.com> <400EC2AA.3020109@ysu.edu> Message-ID: <200401211029.36814.jkeating@j2solutions.net> On Wednesday 21 January 2004 10:19, John Dalbec wrote: > Is that mirrored anywhere? Not just yet. Still waiting on final approval of directory layout. > Also it does not appear to have a yum RPM in the legacy-utils > directory. Correct. It's also missing all the SRPMS and stuff. I'm still populating the server. > I guess the relevant section of yum.conf should read: > --- cut here --- > [os] > name=Fedora Project RHL 7.3 OS > baseurl=http://download.fedoralegacy.org/redhat/7.3/os/i386 > > [updates] > name=Fedora Project RHL 7.3 Updates > baseurl=http://download.fedoralegacy.org/redhat/7.3/updates/i386 > > [legacy] > name=Fedora Project RHL 7.3 Legacy Utilities > baseurl=http://download.fedoralegacy.org/redhat/7.3/legacy-utils/i386 Change that slightly. For a generic listing example: [legacy-utils] name=Fedora Legacy Project RHL $releasever Legacy Utilities baseurl=http://download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch Note the use of $releasever and $basearch. These variables are figured out by yum at run time. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jpdalbec at ysu.edu Wed Jan 21 19:06:38 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 21 Jan 2004 14:06:38 -0500 Subject: Red Hat updates apache, elm, cvs, kdepim Message-ID: <400ECDBE.2080408@ysu.edu> http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci944702,00.html From pearcec at commnav.com Wed Jan 21 19:24:11 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 19:24:11 GMT Subject: Red Hat updates apache, elm, cvs, kdepim Message-ID: <48502.209.50.130.84.1074713051.commnav@home.commnav.com> Hmm apache needs updating I guess. We are on elm and cvs. I mentioned kdepim a while back. I am suprised we haven't see an update for apache in RedHat 9 come from RedHat yet. I am assuming this will be a Red Hat 8.0 only fix. I am going to do some poking around. httpd - was fixed a while back. https://rhn.redhat.com/errata/RHSA-2003-320.html elm and cvs are on the radar screen. kdepim. I forget what we said about this. I don't use kde so I am not planning to help with this one. -- Christian Pearce http://www.commnav.com John Dalbec said: > > http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci944702,00.html > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From Freedom_Lover at pobox.com Wed Jan 21 19:41:43 2004 From: Freedom_Lover at pobox.com (Todd) Date: Wed, 21 Jan 2004 14:41:43 -0500 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <48502.209.50.130.84.1074713051.commnav@home.commnav.com> References: <48502.209.50.130.84.1074713051.commnav@home.commnav.com> Message-ID: <20040121194143.GP13633@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Pearce wrote: > kdepim. I forget what we said about this. I don't use kde so I am > not planning to help with this one. According to http://www.kde.org/info/security/advisory-20040114-1.txt: 1. Systems affected: All versions of kdepim as distributed with KDE versions 3.1.0 through 3.1.4 inclusive. RH 7.x and 8.0 shipped KDE 3.0 or earlier. At least that's one that we don't have to deal with. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Government, in its last analysis, is organized force. -- President Woodrow Wilson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFADtX3uv+09NZUB1oRAqbLAKC2D6E3j2EfmIQ2DK7vbYZROnpqMQCg7XLv qv+R5bazAs7RNOtIkGwbj1E= =ohg0 -----END PGP SIGNATURE----- From pearcec at commnav.com Wed Jan 21 19:54:38 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 19:54:38 GMT Subject: Red Hat updates apache, elm, cvs, kdepim Message-ID: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> That is right. Some people mentioned looking at it to see if it effected an earlier version. I guess this is going to drop off the radar screen. I wonder if any other distributions patched for those versions. Seems like a red herring to me. -- Christian Pearce http://www.commnav.com Todd said: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christian Pearce wrote: > > kdepim. I forget what we said about this. I don't use kde so I am > > not planning to help with this one. > > According to http://www.kde.org/info/security/advisory-20040114-1.txt: > > 1. Systems affected: > > All versions of kdepim as distributed with KDE versions 3.1.0 > through 3.1.4 inclusive. > > RH 7.x and 8.0 shipped KDE 3.0 or earlier. At least that's one that > we don't have to deal with. > > - -- > Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp > ====================================================================== > Government, in its last analysis, is organized force. > -- President Woodrow Wilson > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. > > iD8DBQFADtX3uv+09NZUB1oRAqbLAKC2D6E3j2EfmIQ2DK7vbYZROnpqMQCg7XLv > qv+R5bazAs7RNOtIkGwbj1E= > =ohg0 > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From jkeating at j2solutions.net Wed Jan 21 19:53:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 11:53:18 -0800 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> References: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> Message-ID: <200401211153.18450.jkeating@j2solutions.net> On Wednesday 21 January 2004 11:54, Christian Pearce wrote: > That is right. Some people mentioned looking at it to see if it > effected an earlier version. I guess this is going to drop off the > radar screen. I wonder if any other distributions patched for those > versions. Seems like a red herring to me. We should write an advisory that this vul does not effect the releases we support. Thoughts on format? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Freedom_Lover at pobox.com Wed Jan 21 20:20:17 2004 From: Freedom_Lover at pobox.com (Todd) Date: Wed, 21 Jan 2004 15:20:17 -0500 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <200401211153.18450.jkeating@j2solutions.net> References: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> <200401211153.18450.jkeating@j2solutions.net> Message-ID: <20040121202017.GR13633@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > We should write an advisory that this vul does not effect the > releases we support. Thoughts on format? Doesn't the KDE advisory make that clear enough? Seems like there is already more than enough work just to keep up with the known updates. If there are folks insisting that the vulnerability affects KDE < 3.1 then let them do some work to show that and then it might be worth looking at. Putting out advisories that something *isn't* vulnerable seems useless at best and confusing at worst. To me anyway. It might be different if 8.0 had a vulnerable version and 7.x didn't. Then noting that the vuln didn't affect 7.x might be good to do in the advisory for the updated 8.0 packages. This case could happen with KDE packages after 9 goes EOL in April. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Hell hath no fury like a bureaucrat scorned. -- Dr. Milton Friedman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFADt8Auv+09NZUB1oRArf8AJ0Tjx5MICTWKuKMoabyGbiqAUn7XACg3aNd MltmvDu8hIai6PuA9cd/F+c= =e4mw -----END PGP SIGNATURE----- From pearcec at commnav.com Wed Jan 21 20:39:25 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 20:39:25 GMT Subject: Red Hat updates apache, elm, cvs, kdepim Message-ID: <49037.209.50.130.84.1074717565.commnav@home.commnav.com> I kind of see both sides of the problem. I do agree more with Todd, but I wonder if RedHat has faced this before. Did they release a vuln that effect RHL 9 and then mention it doesn't effect 7x and 8.0? I think this is a tweener problem, and we don't really need to come up with anything. IF we see it happening a lot or people are confused then lets act. People can read the mailing ilsts if curious. -- Christian Pearce http://www.commnav.com Todd said: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > > We should write an advisory that this vul does not effect the > > releases we support. Thoughts on format? > > Doesn't the KDE advisory make that clear enough? Seems like there is > already more than enough work just to keep up with the known updates. > If there are folks insisting that the vulnerability affects KDE < 3.1 > then let them do some work to show that and then it might be worth > looking at. > > Putting out advisories that something *isn't* vulnerable seems useless > at best and confusing at worst. To me anyway. It might be different > if 8.0 had a vulnerable version and 7.x didn't. Then noting that the > vuln didn't affect 7.x might be good to do in the advisory for the > updated 8.0 packages. This case could happen with KDE packages after > 9 goes EOL in April. > > - -- > Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp > ====================================================================== > Hell hath no fury like a bureaucrat scorned. > -- Dr. Milton Friedman > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. > > iD8DBQFADt8Auv+09NZUB1oRArf8AJ0Tjx5MICTWKuKMoabyGbiqAUn7XACg3aNd > MltmvDu8hIai6PuA9cd/F+c= > =e4mw > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From cwfox at fujitsu.com Wed Jan 21 20:51:53 2004 From: cwfox at fujitsu.com (Camron W. Fox) Date: Wed, 21 Jan 2004 10:51:53 -1000 Subject: GPG Updates needed??? Message-ID: Alle, Sorry if this shows up as a repost. So, I try to test my yum installation (from download.fedoralegacy.org) by installing xtraceroute and get the following: [root at hilo etc]# yum install xtraceroute Gathering package information from servers Getting headers from: Red Hat Linux 7.3 base Getting headers from: Fedora Legacy tools for Red Hat Linux 7.3 Getting headers from: Fedora Legacy Project RHL 7.3 Legacy Utilities Getting headers from: Red Hat Linux 7.3 updates Finding updated packages Downloading needed headers Resolving dependencies .Dependencies resolved I will do the following: [install: xtraceroute.i386] I will install/upgrade these to satisfy the dependencies: [deps: gtkglarea.i386] Is this ok [y/N]: y Getting gtkglarea-1.2.2-10.i386.rpm Error: GPG Signature check failed for /var/cache/yum/base/packages/gtkglarea-1.2.2-10.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/base/packages/gtkglarea-1.2.2-10.i386.rpm You may also want to check to make sure you have the right gpg keys Exiting. [root at hilo etc]# I ran a yum clean all and yum clean headers and tried again with no joy. I assumed (wrongly, obviously) that the keys were installed with yum. I perused the website and saw nothing regarding keys, nor did I find anything when I searched through the list. Obviously, I've missed something. Any help would be appreciated. Best Regards, Camron Camron W. Fox Hilo Office High Performance Computing Group Fujitsu America, INC. E-mail: cwfox at fujitsu.com From rohwedde at codegrinder.com Wed Jan 21 20:52:19 2004 From: rohwedde at codegrinder.com (Jason) Date: Wed, 21 Jan 2004 14:52:19 -0600 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <20040121202017.GR13633@psilocybe.teonanacatl.org> References: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> <200401211153.18450.jkeating@j2solutions.net> <20040121202017.GR13633@psilocybe.teonanacatl.org> Message-ID: <20040121205219.GS3353@codegrinder.com> On Wed, Jan 21, 2004 at 03:20:17PM -0500, Todd wrote: > Jesse Keating wrote: > > We should write an advisory that this vul does not effect the > > releases we support. Thoughts on format? > > Doesn't the KDE advisory make that clear enough? Seems like there is > already more than enough work just to keep up with the known updates. > If there are folks insisting that the vulnerability affects KDE < 3.1 > then let them do some work to show that and then it might be worth > looking at. > > Putting out advisories that something *isn't* vulnerable seems useless > at best and confusing at worst. To me anyway. It might be different > if 8.0 had a vulnerable version and 7.x didn't. Then noting that the > vuln didn't affect 7.x might be good to do in the advisory for the > updated 8.0 packages. This case could happen with KDE packages after > 9 goes EOL in April. I concur -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Freedom_Lover at pobox.com Wed Jan 21 21:18:26 2004 From: Freedom_Lover at pobox.com (Todd) Date: Wed, 21 Jan 2004 16:18:26 -0500 Subject: GPG Updates needed??? In-Reply-To: References: Message-ID: <20040121211826.GT13633@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Camron W. Fox wrote: > Sorry if this shows up as a repost. So, I try to test my yum > installation (from download.fedoralegacy.org) by installing > xtraceroute and get the following: > > [root at hilo etc]# yum install xtraceroute [...] > Error: GPG Signature check failed for > /var/cache/yum/base/packages/gtkglarea-1.2.2-10.i386.rpm > You may want to run yum clean or remove the file: > /var/cache/yum/base/packages/gtkglarea-1.2.2-10.i386.rpm > You may also want to check to make sure you have the right gpg keys > Exiting. The last message is the one you want to look over. Check that you have the right gpg keys installed on the gnupg keyring for root. > I ran a yum clean all and yum clean headers and tried again with no > joy. I assumed (wrongly, obviously) that the keys were installed > with yum. You might have used yum from FreshRPMS or another source. IIRC, yum from freshrpms did install the keys for redhat and freshrpms in %post. The yum you get from legacy does not do this. Which is good, IMO. I don't like software messing with my keyrings automatically. > Obviously, I've missed something. Any help would be appreciated. Just import the redhat key and you'll be good. You'll probably also want to check out and import the Fedora Legacy key as well. The redhat key is available many places: on your system: /usr/share/doc/redhat-release-7.3/RPM-GPG-KEY on the redhat website: http://www.redhat.com/solutions/security/news/publickey.html#key on keyservers: http://pgp.mit.edu:11371/pks/lookup?search=0x650d5882&op=index Same with the Fedora Legacy key. If you installed yum already, then it's installed in /usr/share/doc/yum-1.0.3/Fedora-GPG-KEY. It's also on the website and the keyservers. http://fedoralegacy.org/about/security.php http://pgp.mit.edu:11371/pks/lookup?search=0x731002FA&op=index HTH, - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== It is easier to fight for one's principles than to live up to them. -- Alfred Adler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFADuyiuv+09NZUB1oRAiflAKCWClGlAvH+avi/ugWdlYu6Xvl7jACfS2Ic QCmgDoTIeWjGqFfLEZj3oFs= =y1oA -----END PGP SIGNATURE----- From arvand at sbcglobal.net Wed Jan 21 21:45:49 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Wed, 21 Jan 2004 13:45:49 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400EBCF9.7010407@greenhydrant.com> Message-ID: <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> Just an idea but I think libsafe is more than just an add-on. It may actually save some systems from being rooted while FL gives out a patch for the vulnerable program. In my opinion it goes hand in hand with the Fedora Legacy aim to keep EOLed distributions secure. Regards, Arvand Sabetian -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of David Rees Sent: Wednesday, January 21, 2004 9:55 AM To: fedora-legacy-list at redhat.com Subject: Re: Proposal: Optional libsafe add-on? Warren Togami wrote, On 1/21/2004 8:36 AM: > > My earlier post suggested a very short list of extremely simple, yet > useful add-ons for typical servers for the legacy-utils repository. > legacy-utils add-on packages are only by consensus and can easily be > shot down. This is the list of add-ons that I am proposing: > > bonnie++ Very useful stability test for servers > chkrootkit Security checking for servers > ddrescue Data recovery for servers > hardlink Space consolidation for mirror servers > iptstate Very simple Netfilter stateful top * I feel that these utilities would be useful to have in the legacy-utils repository. -Dave -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From wstockal at compusmart.ab.ca Wed Jan 21 21:49:18 2004 From: wstockal at compusmart.ab.ca (William Stockall) Date: Wed, 21 Jan 2004 14:49:18 -0700 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <20040121205219.GS3353@codegrinder.com> References: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> <200401211153.18450.jkeating@j2solutions.net> <20040121202017.GR13633@psilocybe.teonanacatl.org> <20040121205219.GS3353@codegrinder.com> Message-ID: <400EF3DE.40602@compusmart.ab.ca> It might actually be useful here to get some indication that, although the package (never mind the version) is installed, we are not vulnerable for whatever reason. This is probably preferable to wondering if, perhaps, nobody noticed this particular package for this distribution. Will. Jason wrote: > On Wed, Jan 21, 2004 at 03:20:17PM -0500, Todd wrote: > >>Jesse Keating wrote: >> >>>We should write an advisory that this vul does not effect the >>>releases we support. Thoughts on format? >> >>Doesn't the KDE advisory make that clear enough? Seems like there is >>already more than enough work just to keep up with the known updates. >>If there are folks insisting that the vulnerability affects KDE < 3.1 >>then let them do some work to show that and then it might be worth >>looking at. >> >>Putting out advisories that something *isn't* vulnerable seems useless >>at best and confusing at worst. To me anyway. It might be different >>if 8.0 had a vulnerable version and 7.x didn't. Then noting that the >>vuln didn't affect 7.x might be good to do in the advisory for the >>updated 8.0 packages. This case could happen with KDE packages after >>9 goes EOL in April. > > > I concur From skvidal at phy.duke.edu Wed Jan 21 21:51:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 21 Jan 2004 16:51:51 -0500 Subject: Red Hat updates apache, elm, cvs, kdepim In-Reply-To: <400EF3DE.40602@compusmart.ab.ca> References: <48827.209.50.130.84.1074714878.commnav@home.commnav.com> <200401211153.18450.jkeating@j2solutions.net> <20040121202017.GR13633@psilocybe.teonanacatl.org> <20040121205219.GS3353@codegrinder.com> <400EF3DE.40602@compusmart.ab.ca> Message-ID: <1074721911.11653.30.camel@binkley> On Wed, 2004-01-21 at 16:49, William Stockall wrote: > It might actually be useful here to get some indication that, although > the package (never mind the version) is installed, we are not vulnerable > for whatever reason. This is probably preferable to wondering if, > perhaps, nobody noticed this particular package for this distribution. > > maybe that sort of action should be reserved for serious vulnerabilities. a vcf file import overflow in kdepim does not strike me as 'serious' if openssh is exploited by the opensshd in 7.3 isn't vulnerable, then sure - let people know about it. -sv From jkeating at j2solutions.net Wed Jan 21 22:15:00 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 14:15:00 -0800 Subject: When to bump the build? Message-ID: <200401211415.05181.jkeating@j2solutions.net> A recent problem found in the 8.0 build of tcpdump shows that autoconf213 is needed to complete the build correctly. Because of this, we need to modify the current candidate for publish in bugzilla. Since we will be modifying it, should we bump the build ID up one more on the package? I think yes, as it shows clearly a newer package within the ticket. I'm pretty sure that RH goes through a few bumps internally, as there can be a jump in the number from update to update. Thoughts? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pearcec at commnav.com Wed Jan 21 22:30:47 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 22:30:47 GMT Subject: When to bump the build? Message-ID: <49280.209.50.130.84.1074724247.commnav@home.commnav.com> Sucks, but clearly it is a different revision. I think we do this for people who are using this packages bleeding edge and want to be able to upgrade smoothly. The other thing we could do is have a testing.legacy in the tag. Allowing us to do what ever we want until we officially release. I think that is a headache though. Let just bump the rev if we have too. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > A recent problem found in the 8.0 build of tcpdump shows that > autoconf213 is needed to complete the build correctly. Because of > this, we need to modify the current candidate for publish in bugzilla. > Since we will be modifying it, should we bump the build ID up one more > on the package? I think yes, as it shows clearly a newer package > within the ticket. I'm pretty sure that RH goes through a few bumps > internally, as there can be a jump in the number from update to update. > > Thoughts? > > -- > Jesse Keating RHCE MCSE (geek.j2solutions.net) > Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating From pearcec at commnav.com Wed Jan 21 22:32:06 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 21 Jan 2004 22:32:06 GMT Subject: tcpdump update for RedHat 8.0 Message-ID: <49297.209.50.130.84.1074724326.commnav@home.commnav.com> http://bugzilla.fedora.us/show_bug.cgi?id=1222 tcpdump whated autoconf213. I added it to BuildRequires and autoheader is now autoheader-2.13. Please QA. -- Christian Pearce http://www.commnav.com From ms-nospam-0306 at arcor.de Wed Jan 21 22:41:25 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 21 Jan 2004 23:41:25 +0100 Subject: When to bump the build? In-Reply-To: <200401211415.05181.jkeating@j2solutions.net> References: <200401211415.05181.jkeating@j2solutions.net> Message-ID: <20040121234125.1ca8c2db.ms-nospam-0306@arcor.de> On Wed, 21 Jan 2004 14:15:00 -0800, Jesse Keating wrote: > A recent problem found in the 8.0 build of tcpdump shows that > autoconf213 is needed to complete the build correctly. Because of > this, we need to modify the current candidate for publish in bugzilla. > Since we will be modifying it, should we bump the build ID up one more > on the package? I think yes, as it shows clearly a newer package > within the ticket. I'm pretty sure that RH goes through a few bumps > internally, as there can be a jump in the number from update to update. > > Thoughts? Don't micro-moderate the package preparation process. Bumping the %release number during package reviews only adds convenience for the reviewers and can avoid confusion. Everyone else doesn't care. Bumping the %release prior to publishing an updated package only creates the need to add another separate spec changelog entry for every minor modification instead of squeezing all package changes into a single new changelog entry compared with the previously publicly released package revision. Bump the %release only after something has been published in either updates or updates-testing, so a sane upgrade path is guaranteed. Else it simply does not matter. Except if there are so many changes applied to a package, that small incremental steps (i.e. many package revisions) help in understanding the development of a package while it's in the QA queue. -- From jkeating at j2solutions.net Wed Jan 21 22:54:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 14:54:46 -0800 Subject: Fwd: [SECURITY] Fedora Core 1 Testing Update: slocate-2.7-4 Message-ID: <200401211454.46397.jkeating@j2solutions.net> We should look at legacy exposure to this flaw. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 5089 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From notting at redhat.com Wed Jan 21 23:16:20 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Jan 2004 18:16:20 -0500 Subject: Fwd: [SECURITY] Fedora Core 1 Testing Update: slocate-2.7-4 In-Reply-To: <200401211454.46397.jkeating@j2solutions.net> References: <200401211454.46397.jkeating@j2solutions.net> Message-ID: <20040121231619.GA21255@devserv.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: > We should look at legacy exposure to this flaw. Yes, older releases are vulnerable, although it's not *that* serious of a bug. Just --rebuilding the source RPM should work ok... if you don't have versioned automake, you may need the attached. Bill -------------- next part -------------- --- slocate-2.7/configure.foo 2004-01-21 15:02:56.000000000 -0500 +++ slocate-2.7/configure 2004-01-21 15:03:56.000000000 -0500 @@ -1470,17 +1470,17 @@ missing_dir=`cd $ac_aux_dir && pwd` -echo "$as_me:$LINENO: checking for working aclocal-${am__api_version}" >&5 -echo $ECHO_N "checking for working aclocal-${am__api_version}... $ECHO_C" >&6 +echo "$as_me:$LINENO: checking for working aclocal" >&5 +echo $ECHO_N "checking for working aclocal... $ECHO_C" >&6 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. -if (aclocal-${am__api_version} --version) < /dev/null > /dev/null 2>&1; then - ACLOCAL=aclocal-${am__api_version} +if (aclocal --version) < /dev/null > /dev/null 2>&1; then + ACLOCAL=aclocal echo "$as_me:$LINENO: result: found" >&5 echo "${ECHO_T}found" >&6 else - ACLOCAL="$missing_dir/missing aclocal-${am__api_version}" + ACLOCAL="$missing_dir/missing aclocal" echo "$as_me:$LINENO: result: missing" >&5 echo "${ECHO_T}missing" >&6 fi @@ -1500,17 +1500,17 @@ echo "${ECHO_T}missing" >&6 fi -echo "$as_me:$LINENO: checking for working automake-${am__api_version}" >&5 -echo $ECHO_N "checking for working automake-${am__api_version}... $ECHO_C" >&6 +echo "$as_me:$LINENO: checking for working automake" >&5 +echo $ECHO_N "checking for working automake... $ECHO_C" >&6 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. -if (automake-${am__api_version} --version) < /dev/null > /dev/null 2>&1; then - AUTOMAKE=automake-${am__api_version} +if (automake --version) < /dev/null > /dev/null 2>&1; then + AUTOMAKE=automake echo "$as_me:$LINENO: result: found" >&5 echo "${ECHO_T}found" >&6 else - AUTOMAKE="$missing_dir/missing automake-${am__api_version}" + AUTOMAKE="$missing_dir/missing automake" echo "$as_me:$LINENO: result: missing" >&5 echo "${ECHO_T}missing" >&6 fi From warren at togami.com Thu Jan 22 01:22:22 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 15:22:22 -1000 Subject: When to bump the build? In-Reply-To: <200401211415.05181.jkeating@j2solutions.net> References: <200401211415.05181.jkeating@j2solutions.net> Message-ID: <400F25CE.2080802@togami.com> Jesse Keating wrote: > A recent problem found in the 8.0 build of tcpdump shows that > autoconf213 is needed to complete the build correctly. Because of > this, we need to modify the current candidate for publish in bugzilla. > Since we will be modifying it, should we bump the build ID up one more > on the package? I think yes, as it shows clearly a newer package > within the ticket. I'm pretty sure that RH goes through a few bumps > internally, as there can be a jump in the number from update to update. > > Thoughts? > RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always bump the release number. For Legacy I would suggeset not bumping a number only for a rebuild on the higher distribution, but instead adding some sort of disttag. For example: foo-1.3.5-2.7.2.legacy foo-1.3.5-2.7.3.legacy foo-1.3.5-2.8.legacy Do this ONLY if the only spec change is the release number, and the versions were unified for the purpose of making it easier to maintain in the future. Also recall the earlier agreed upon policy that any upgrading of versions for the purpose of unifying versions across distributions must be explicitly communicated on the list and agreed upon by consensus. (By consensus, I would suggest making it among past contributors.) Warren From jkeating at j2solutions.net Thu Jan 22 01:24:26 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 17:24:26 -0800 Subject: When to bump the build? In-Reply-To: <400F25CE.2080802@togami.com> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> Message-ID: <200401211724.26692.jkeating@j2solutions.net> On Wednesday 21 January 2004 17:22, Warren Togami wrote: > RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always > bump the release number. > > For Legacy I would suggeset not bumping a number only for a rebuild > on the higher distribution, but instead adding some sort of disttag. > For example: > > foo-1.3.5-2.7.2.legacy > foo-1.3.5-2.7.3.legacy > foo-1.3.5-2.8.legacy yeah, this isn't the issue that I was talking about. A package was posted to bugzilla, we found a bug in it, fixed the bug, do we bump the build number on that package (and put it out of skew with the rest of the packages)? > Do this ONLY if the only spec change is the release number, and the > versions were unified for the purpose of making it easier to maintain > in the future. Also recall the earlier agreed upon policy that any > upgrading of versions for the purpose of unifying versions across > distributions must be explicitly communicated on the list and agreed > upon by consensus. > > (By consensus, I would suggest making it among past contributors.) Totally agreeable. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warren at togami.com Thu Jan 22 01:43:25 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 15:43:25 -1000 Subject: When to bump the build? In-Reply-To: <200401211724.26692.jkeating@j2solutions.net> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <200401211724.26692.jkeating@j2solutions.net> Message-ID: <400F2ABD.8050302@togami.com> Jesse Keating wrote: > On Wednesday 21 January 2004 17:22, Warren Togami wrote: > >>RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always >>bump the release number. >> >>For Legacy I would suggeset not bumping a number only for a rebuild >>on the higher distribution, but instead adding some sort of disttag. >> For example: >> >>foo-1.3.5-2.7.2.legacy >>foo-1.3.5-2.7.3.legacy >>foo-1.3.5-2.8.legacy > > > yeah, this isn't the issue that I was talking about. A package was > posted to bugzilla, we found a bug in it, fixed the bug, do we bump the > build number on that package (and put it out of skew with the rest of > the packages)? > Always bump numbers for any package that leaves your local machine. That is all I can recommend. Warren From skvidal at phy.duke.edu Thu Jan 22 01:39:34 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 21 Jan 2004 20:39:34 -0500 Subject: When to bump the build? In-Reply-To: <400F25CE.2080802@togami.com> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> Message-ID: <1074735573.15685.5.camel@binkley> On Wed, 2004-01-21 at 20:22, Warren Togami wrote: > Jesse Keating wrote: > > A recent problem found in the 8.0 build of tcpdump shows that > > autoconf213 is needed to complete the build correctly. Because of > > this, we need to modify the current candidate for publish in bugzilla. > > Since we will be modifying it, should we bump the build ID up one more > > on the package? I think yes, as it shows clearly a newer package > > within the ticket. I'm pretty sure that RH goes through a few bumps > > internally, as there can be a jump in the number from update to update. > > > > Thoughts? > > > > RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always > bump the release number. > rh has a policy now?? Wow - can any of the rest of us mere mortals get a copy of it? or is this like the rest of the policies I've heard of? There are as many policies as there are packagers? -sv From warren at togami.com Thu Jan 22 01:47:21 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 15:47:21 -1000 Subject: When to bump the build? In-Reply-To: <1074735573.15685.5.camel@binkley> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <1074735573.15685.5.camel@binkley> Message-ID: <400F2BA9.1010408@togami.com> seth vidal wrote: > On Wed, 2004-01-21 at 20:22, Warren Togami wrote: > >>Jesse Keating wrote: >> >>>A recent problem found in the 8.0 build of tcpdump shows that >>>autoconf213 is needed to complete the build correctly. Because of >>>this, we need to modify the current candidate for publish in bugzilla. >>>Since we will be modifying it, should we bump the build ID up one more >>>on the package? I think yes, as it shows clearly a newer package >>>within the ticket. I'm pretty sure that RH goes through a few bumps >>>internally, as there can be a jump in the number from update to update. >>> >>>Thoughts? >>> >> >>RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always >>bump the release number. >> > > > rh has a policy now?? Wow - can any of the rest of us mere mortals get a > copy of it? > > or is this like the rest of the policies I've heard of? There are as > many policies as there are packagers? > Well, it seems to be enforced by script that prepares package for their build system, so it is well understood. Warren From admin at cs.montana.edu Thu Jan 22 01:54:36 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 21 Jan 2004 18:54:36 -0700 (MST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> References: <400EBCF9.7010407@greenhydrant.com> <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> Message-ID: <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> Arvand Sabetian said: > Just an idea but I think libsafe is more than just an add-on. It may > actually save some systems from being rooted while FL gives out a patch > for > the vulnerable program. In my opinion it goes hand in hand with the Fedora > Legacy aim to keep EOLed distributions secure. libsafe is part of the patches directory for fedora. It will break some apps on 7.3 boxes. Think it broke the default cal program on 7.3. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From skvidal at phy.duke.edu Thu Jan 22 01:53:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 21 Jan 2004 20:53:40 -0500 Subject: When to bump the build? In-Reply-To: <400F2BA9.1010408@togami.com> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <1074735573.15685.5.camel@binkley> <400F2BA9.1010408@togami.com> Message-ID: <1074736420.15685.14.camel@binkley> > > rh has a policy now?? Wow - can any of the rest of us mere mortals get a > > copy of it? > > > > or is this like the rest of the policies I've heard of? There are as > > many policies as there are packagers? > > > > Well, it seems to be enforced by script that prepares package for their > build system, so it is well understood. so not so much policy as common use. -sv From admin at cs.montana.edu Thu Jan 22 02:01:25 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 21 Jan 2004 19:01:25 -0700 (MST) Subject: mirror difference between fedora.us and fedoralegacy.org updates Message-ID: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> updates for 7.3, www.fedora.us and www.fedoralegacy.org I was looking at the updates listed on www.fedora.us, and it had: http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ it had: yum Then when I looked at the updates listed for: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ it had: a zillion updates. I was using fedora.us as my legacy update, should I be using fedoralegacy.org as my update repository? Please advise. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From warren at togami.com Thu Jan 22 02:02:42 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 16:02:42 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> References: <400EBCF9.7010407@greenhydrant.com> <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> Message-ID: <400F2F42.9020404@togami.com> Lucas Albers wrote: > Arvand Sabetian said: > >>Just an idea but I think libsafe is more than just an add-on. It may >>actually save some systems from being rooted while FL gives out a patch >>for >>the vulnerable program. In my opinion it goes hand in hand with the Fedora >>Legacy aim to keep EOLed distributions secure. > > > libsafe is part of the patches directory for fedora. > It will break some apps on 7.3 boxes. > Think it broke the default cal program on 7.3. > Can you find references to this breakage? A reproduce procedure would be really helpful. Warren From drees at greenhydrant.com Thu Jan 22 02:12:21 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 18:12:21 -0800 (PST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400F2F42.9020404@togami.com> References: <400EBCF9.7010407@greenhydrant.com> <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> <400F2F42.9020404@togami.com> Message-ID: <4687.208.48.139.163.1074737541.squirrel@www.greenhydrant.com> On Wed, January 21, 2004 at 6:02 pm, Warren Togami wrote: >> libsafe is part of the patches directory for fedora. >> It will break some apps on 7.3 boxes. >> Think it broke the default cal program on 7.3. > > Can you find references to this breakage? A reproduce procedure would > be really helpful. I don't have a reference, but I was able to duplicate it: > rpm -q redhat-release redhat-release-7.3-1 > rpm -q libsafe libsafe-2.0-16.fdr.1 > rpm -qf `which cal` util-linux-2.11n-12.7.3 > cal Libsafe version 2.0.16 Detected an attempt to write across stack boundary. Terminating /usr/bin/cal. uid=500 euid=500 pid=25676 Call stack: 0x40015982 /lib/libsafe.so.2.0.16 0x400160a1 /lib/libsafe.so.2.0.16 0x8048f14 /usr/bin/cal 0x8048d3d /usr/bin/cal 0x42017584 /lib/i686/libc-2.2.5.so Overflow caused by wcscat() Killed > I'll have to look into it further. -Dave From drees at greenhydrant.com Thu Jan 22 02:13:49 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 18:13:49 -0800 (PST) Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> Message-ID: <4705.208.48.139.163.1074737629.squirrel@www.greenhydrant.com> On Wed, January 21, 2004 at 6:01 pm, Lucas Albers wrote: > > updates for 7.3, www.fedora.us and www.fedoralegacy.org > > I was looking at the updates listed on www.fedora.us, and it had: > http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ > it had: > yum > > Then when I looked at the updates listed for: > http://download.fedoralegacy.org/redhat/7.3/updates/i386/ > it had: > a zillion updates. > > I was using fedora.us as my legacy update, should I be using > fedoralegacy.org as my update repository? > > Please advise. Please read the FAQ. Specifically, "How do I update packages?". -Dave From drees at greenhydrant.com Thu Jan 22 02:17:27 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 21 Jan 2004 18:17:27 -0800 (PST) Subject: When to bump the build? In-Reply-To: <200401211724.26692.jkeating@j2solutions.net> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <200401211724.26692.jkeating@j2solutions.net> Message-ID: <4713.208.48.139.163.1074737847.squirrel@www.greenhydrant.com> On Wed, January 21, 2004 at 5:24 pm, Jesse Keating wrote: > On Wednesday 21 January 2004 17:22, Warren Togami wrote: >> RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always >> bump the release number. > > yeah, this isn't the issue that I was talking about. A package was > posted to bugzilla, we found a bug in it, fixed the bug, do we bump the > build number on that package (and put it out of skew with the rest of > the packages)? I think Warren would answer, YES. At least that's how I interpreted it. ;-) I don't see it being out of skew with the other packages being an issue. -Dave From notting at redhat.com Thu Jan 22 02:37:52 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Jan 2004 21:37:52 -0500 Subject: When to bump the build? In-Reply-To: <1074736420.15685.14.camel@binkley> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <1074735573.15685.5.camel@binkley> <400F2BA9.1010408@togami.com> <1074736420.15685.14.camel@binkley> Message-ID: <20040122023752.GA2840@devserv.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > > Well, it seems to be enforced by script that prepares package for their > > build system, so it is well understood. > > so not so much policy as common use. Well.... All builds in the build system must be unique. If you nuke a build before it actually gets pushed anywhere, you can get away with re-using a release number, but it's generally recommended to bump them. Bill From jkeating at j2solutions.net Thu Jan 22 02:54:19 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 18:54:19 -0800 Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> Message-ID: <200401211854.20810.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 18:01, Lucas Albers wrote: > updates for 7.3, www.fedora.us and www.fedoralegacy.org > > I was looking at the updates listed on www.fedora.us, and it had: > http://download.fedora.us/fedora/redhat/7.3/i386/RPMS.legacy/ > it had: > yum Fedora.us mirror has minimal packages, was a temporary tool. > Then when I looked at the updates listed for: > http://download.fedoralegacy.org/redhat/7.3/updates/i386/ > it had: > a zillion updates. download.fedoralegacy.org has all the RH published updates, as well as Legacy updates (when they get published). > > I was using fedora.us as my legacy update, should I be using > fedoralegacy.org as my update repository? > > Please advise. Cut over to fedoralegacy.org and it's mirror system (when we get it), as fedora.us's 7.2/7.3 stuff will be going away soon. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADztb4v2HLvE71NURAt3tAJwKCZHwnelDdY1qml50BYRf4/JNNwCgqijS pO6zeACPoZa6Yc8Xe4V6esQ= =HX91 -----END PGP SIGNATURE----- From admin at cs.montana.edu Thu Jan 22 03:37:58 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 21 Jan 2004 20:37:58 -0700 (MST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400F2F42.9020404@togami.com> References: <400EBCF9.7010407@greenhydrant.com> <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> <400F2F42.9020404@togami.com> Message-ID: <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> Warren Togami said: > Can you find references to this breakage? A reproduce procedure would > be really helpful. > > Warren Result: running cal program with libsafe installed dumps cal. Repro: on redhat 7.3 install util-linux-2.11n-12.7.3 install libsafe 2.0.16 reboot run /usr/bin/cal Look at stack dump. expected result: no crash fix: Recompile cal with new version (i recompiled from newer cal version) and problem goes away. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From admin at cs.montana.edu Thu Jan 22 03:40:26 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 21 Jan 2004 20:40:26 -0700 (MST) Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <200401211854.20810.jkeating@j2solutions.net> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401211854.20810.jkeating@j2solutions.net> Message-ID: <33122.216.166.133.165.1074742826.squirrel@webtest.cs.montana.edu> Jesse Keating said: > Cut over to fedoralegacy.org and it's mirror system (when we get it), as > fedora.us's 7.2/7.3 stuff will be going away soon. Well since fedora.us is not giving me a lot of updates. I cannot wait to switch. When will fedoralegacy.org go apt enabled? I assume it is not apt enabled because I dont' see any pkglist for the rpm packges on fedoralegacy.org. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From admin at cs.montana.edu Thu Jan 22 03:42:08 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 21 Jan 2004 20:42:08 -0700 (MST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <4687.208.48.139.163.1074737541.squirrel@www.greenhydrant.com> References: <400EBCF9.7010407@greenhydrant.com> <200401212145.i0LLjMlo010088@pimout4-ext.prodigy.net> <32869.216.166.133.165.1074736476.squirrel@webtest.cs.montana.edu> <400F2F42.9020404@togami.com> <4687.208.48.139.163.1074737541.squirrel@www.greenhydrant.com> Message-ID: <33126.216.166.133.165.1074742928.squirrel@webtest.cs.montana.edu> David Rees said: > I don't have a reference, but I was able to duplicate it: > I'll have to look into it further. With that said, that was the ONLY problem I encountered with libsafe. I have had it installed it on my primary server(for 6 months or so), and it has not caused ANY problems. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From jkeating at j2solutions.net Thu Jan 22 03:46:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 19:46:02 -0800 Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <33122.216.166.133.165.1074742826.squirrel@webtest.cs.montana.edu> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401211854.20810.jkeating@j2solutions.net> <33122.216.166.133.165.1074742826.squirrel@webtest.cs.montana.edu> Message-ID: <200401211946.03110.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 19:40, Lucas Albers wrote: > Well since fedora.us is not giving me a lot of updates. > I cannot wait to switch. > When will fedoralegacy.org go apt enabled? > > I assume it is not apt enabled because I dont' see any pkglist for the > rpm packges on fedoralegacy.org. It'll go apt when A) it's fully populated with all the rpms (the yum and apt rebuilds need to be built by me and signed w/ the legacy key), and B) somebody tells me how to build an Apt repo. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD0d64v2HLvE71NURAnRdAJ9FsKY8rih4tnk9l202nZ15IsEa9gCeOc4u KORPIKnaQef8cLPGHwrALZs= =s7ji -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jan 22 03:46:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 19:46:55 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> Message-ID: <200401211946.56300.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 19:37, Lucas Albers wrote: > Recompile cal with new version (i recompiled from newer cal version) and > problem goes away. So if we were to offer libsafe, we'd have to offer an upgraded cal as well. I wonder if any other packages will die.... - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD0ev4v2HLvE71NURAl1GAKCxeXgzeDzz+3CsNqxFanB5A1ZksgCfYOWW 0xhY8ZlQsxZPfIsH0QyMxWE= =4f1x -----END PGP SIGNATURE----- From warren at togami.com Thu Jan 22 04:16:07 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 18:16:07 -1000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <200401211946.56300.jkeating@j2solutions.net> References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> Message-ID: <400F4E87.8060108@togami.com> Jesse Keating wrote: > On Wednesday 21 January 2004 19:37, Lucas Albers wrote: > >>>Recompile cal with new version (i recompiled from newer cal version) and >>>problem goes away. > > > So if we were to offer libsafe, we'd have to offer an upgraded cal as well. > I wonder if any other packages will die.... > Not necessarily. Why? 1) How important is cal to servers? In all of my experience I didn't even know it existed until now... unless is it used in some system scripts or something? 2) Those who chose to use libsafe should do so only after reading the page describing what it does, and the potential risk. The web page would say very clearly that the server admin should TEST all of their software and keep an eye out for strange behavior rather than install libsafe and trust that it works. 3) If things that they need stop working, then they have a two options: Remove libsafe or patch the broken program. Perhaps if something more important than cal is found to be broken, then it can go into the minimal libsafe-specific apt/yum repository. shadow-utils for RH9 and FC1 would fall into this category for example. 4) List everything that is known to be broken by libsafe on the web page, and if it is considered a serious enough problem to patch it. From jkeating at j2solutions.net Thu Jan 22 04:31:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 20:31:06 -0800 Subject: Fedora Legacy Test Update Notification: elm Message-ID: <200401212031.07231.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1230 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1230 2004-01-21 - --------------------------------------------------------------------- Name : selm Versions : 7.2: 2.5.6-3, 7.3: 2.5.6-4 Summary : The elm mail user agent. Description : Elm is a terminal mode email user agent. Elm includes all standard mailhandling features, including MIME support via metamail. Elm is still used by some people, but is no longer in active development. If you have used Elm before and you are devoted to it, you should install the elm package. If you want to use metamail's MIME support, you also need to install the metamail package. Install the screen package if you need a screen manager that can support multiple logins on one terminal. - --------------------------------------------------------------------- Update Information: CAN-2003-0966: Buffer overflow in the frm command in elm 2.5.6 and earlier allows remote attackers to execute arbitrary code via a long Subject line. - --------------------------------------------------------------------- Changelog: * Wed Jan 21 2004 Jonny Strom - - 2.5.6, minor security fix CAN-2003-0966. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 638ec1d1bee210ac094a9264a09c4aba24708620 7.2/updates-testing/SRPMS/elm-2.5.6-3.legacy.src.rpm 58e7d0bbb603585ea19fd7a25abe2375e3e1d991 7.2/updates-testing/i386/elm-2.5.6-3.legacy.i386.rpm 6ae567ed110cdabb6229c4abd1582a3caba2fbde 7.3/updates-testing/SRPMS/elm-2.5.6-4.legacy.src.rpm 082bf0474105cd40f29419b37f431c9f7c48944d 7.3/updates-testing/i386/elm-2.5.6-4.legacy.i386.rpm - --------------------------------------------------------------------- Note: RHL 8.0 did not ship with elm. Please test and comment in bugzilla. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD1IK4v2HLvE71NURAsdyAKCd3MOdcFtZvmBtboiIC1hJrr40FACgw8fE PAdLGGUA3sAp4BwbtkPS0fU= =sIyi -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jan 22 04:35:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 20:35:36 -0800 Subject: Fedora Legacy Test Update Notification: elm In-Reply-To: <200401212031.07231.jkeating@j2solutions.net> References: <200401212031.07231.jkeating@j2solutions.net> Message-ID: <200401212035.37903.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 20:31, Jesse Keating wrote: > Fedora Legacy Test Update Notification > FEDORALEGACY-2004-1230 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1230 > 2004-01-21 > --------------------------------------------------------------------- > > Name : selm > Versions : 7.2: 2.5.6-3, 7.3: 2.5.6-4 Whoops, that should be "elm" not "selm" *sigh* - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD1MY4v2HLvE71NURAtfUAJ0U0NnE70aslsVXqEvVC6ezfNw8zwCeNSqZ /ebCbK/0Hs3Z5sHKvEh1P1A= =Hz55 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jan 22 04:42:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 20:42:22 -0800 Subject: Fedora Legacy Test Update Notification: tcpdump Message-ID: <200401212042.23941.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1222 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1222 2004-01-21 - --------------------------------------------------------------------- Name : tcpdump Versions : 7.2: 2.1a11-17.7.2.4, 7.3: 2.1a11-17.7.3.4, 2.1a11-17.7.3.5 Summary : A network traffic monitoring tool. Description : Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. - --------------------------------------------------------------------- Update Information: CAN-2003-0989: tcpdump before 3.8.1 allows remote attackers to cause a denial of service (infinite loop) via certain ISAKMP packets, a different vulnerability than CAN-2004-0057. CAN-2004-0055: The print_attr_string function in print-radius.c for tcpdump 3.8.1 and earlier allows remote attackers to cause a denial of service (segmentation fault) via a RADIUS attribute with a large length value. CAN-2004-0057: The rawprint function in the ISAKMP decoding routines (print-isakmp.c) for tcpdump 3.8.1 and earlier allows remote attackers to cause a denial of service (segmentation fault) via malformed ISAKMP packets that cause invalid "len" or "loc" values to be used in a loop, a different vulnerability than CAN-2003-0989. - --------------------------------------------------------------------- Changelog: 7.2, 7.3: * Fri Jan 16 2004 Christian Pearce -17.8.05 - - Added BuildRequires autoconf213. - - Changed autoheader to autoheader-2.12 - - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90208 * Fri Jan 16 2004 Christian Pearce -17.x.x.4 - - CAN-2003-0989 fix - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 - - CAN-2004-0055, CAN-2004-0057 fix - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 - - http://marc.theaimsgroup.com/?l=tcpdump-work - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates-testing/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates-testing/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates-testing/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates-testing/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates-testing/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates-testing/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates-testing/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates-testing/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD1Su4v2HLvE71NURAlQaAJ4kJWEQOpq6fQhVG3CxpqM4ZigqnACgrmx4 p+0GGuqK/4wba9AW0FJWCZg= =omjo -----END PGP SIGNATURE----- From warren at togami.com Thu Jan 22 04:54:12 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 18:54:12 -1000 Subject: Fedora Legacy Test Update Notification: tcpdump In-Reply-To: <200401212042.23941.jkeating@j2solutions.net> References: <200401212042.23941.jkeating@j2solutions.net> Message-ID: <400F5774.1070300@togami.com> Jesse Keating wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2004-1222 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1222 > 2004-01-21 > --------------------------------------------------------------------- > > Name : tcpdump > Versions : 7.2: 2.1a11-17.7.2.4, 7.3: 2.1a11-17.7.3.4, 2.1a11-17.7.3.5 May I recommend splitting each distribution onto its own line? On one line it could easily be unparsable by real humans. =) Missing "8.0"? Hmm, wrong v-r too... but further down in the md5sums section it is correct. Warren From jkeating at j2solutions.net Thu Jan 22 05:02:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 21:02:41 -0800 Subject: Fedora Legacy Test Update Notification: tcpdump In-Reply-To: <400F5774.1070300@togami.com> References: <200401212042.23941.jkeating@j2solutions.net> <400F5774.1070300@togami.com> Message-ID: <200401212102.42010.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 20:54, Warren Togami wrote: > May I recommend splitting each distribution onto its own line? On one > line it could easily be unparsable by real humans. =) > > Missing "8.0"? > > Hmm, wrong v-r too... but further down in the md5sums section it is > correct. Ugh, crap. You're right. It being so garbled, _I_ missed the v-r. I'll re-issue. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD1lx4v2HLvE71NURAkNLAJ9zWruWJSAJV0XaywSNjMkA6iDmWgCdF8I+ O8+SZ0X6umCS2BAKWD4hDVs= =KG4j -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jan 22 05:04:43 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 21:04:43 -0800 Subject: Fedora Legacy Test Update Notification: tcpdump (redux for version fubar) Message-ID: <200401212104.44841.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1222 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1222 2004-01-21 - --------------------------------------------------------------------- Name : tcpdump Version 7.2 : 2.1a11-17.7.2.4 Version 7.3 : 2.1a11-17.7.3.4 Version 8.0 : 2.1a11-17.7.3.5 Summary : A network traffic monitoring tool. Description : Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. - --------------------------------------------------------------------- Update Information: CAN-2003-0989: tcpdump before 3.8.1 allows remote attackers to cause a denial of service (infinite loop) via certain ISAKMP packets, a different vulnerability than CAN-2004-0057. CAN-2004-0055: The print_attr_string function in print-radius.c for tcpdump 3.8.1 and earlier allows remote attackers to cause a denial of service (segmentation fault) via a RADIUS attribute with a large length value. CAN-2004-0057: The rawprint function in the ISAKMP decoding routines (print-isakmp.c) for tcpdump 3.8.1 and earlier allows remote attackers to cause a denial of service (segmentation fault) via malformed ISAKMP packets that cause invalid "len" or "loc" values to be used in a loop, a different vulnerability than CAN-2003-0989. - --------------------------------------------------------------------- Changelog: 7.2, 7.3: * Fri Jan 16 2004 Christian Pearce -17.8.05 - - Added BuildRequires autoconf213. - - Changed autoheader to autoheader-2.12 - - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90208 * Fri Jan 16 2004 Christian Pearce -17.x.x.4 - - CAN-2003-0989 fix - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 - - CAN-2004-0055, CAN-2004-0057 fix - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 - - http://marc.theaimsgroup.com/?l=tcpdump-work - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates-testing/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates-testing/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates-testing/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates-testing/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates-testing/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates-testing/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates-testing/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates-testing/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm - --------------------------------------------------------------------- Please test and comment in bugzilla. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD1nr4v2HLvE71NURAshIAJsHNJBrVCPk1F/D7tkjFDKcs+IGmgCgumcr m4IRBWknIf+Shyn/YuHcTiI= =yO8V -----END PGP SIGNATURE----- From warren at togami.com Thu Jan 22 05:39:38 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Jan 2004 19:39:38 -1000 Subject: Fedora Legacy Test Update Notification: tcpdump (redux for version fubar) In-Reply-To: <200401212104.44841.jkeating@j2solutions.net> References: <200401212104.44841.jkeating@j2solutions.net> Message-ID: <400F621A.5080409@togami.com> Jesse Keating wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2004-1222 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1222 > 2004-01-21 > --------------------------------------------------------------------- > > Name : tcpdump > Version 7.2 : 2.1a11-17.7.2.4 > Version 7.3 : 2.1a11-17.7.3.4 > Version 8.0 : 2.1a11-17.7.3.5 8.0's packages don't match the filenames at the bottom. Warren From chuckw at quantumlinux.com Thu Jan 22 05:40:22 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 21 Jan 2004 21:40:22 -0800 (PST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400F4E87.8060108@togami.com> References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> <400F4E87.8060108@togami.com> Message-ID: > 1) How important is cal to servers? In all of my experience I didn't > even know it existed until now... unless is it used in some system > scripts or something? How else do you do date math in your shell scripts? -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From johannes at erdfelt.com Thu Jan 22 05:43:06 2004 From: johannes at erdfelt.com (Johannes Erdfelt) Date: Wed, 21 Jan 2004 21:43:06 -0800 Subject: Proposal: Optional libsafe add-on? In-Reply-To: References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> <400F4E87.8060108@togami.com> Message-ID: <20040122054306.GC18917@sventech.com> On Wed, Jan 21, 2004, Chuck Wolber wrote: > > 1) How important is cal to servers? In all of my experience I didn't > > even know it existed until now... unless is it used in some system > > scripts or something? > > How else do you do date math in your shell scripts? farley:~% echo $((1+2)) 3 farley:~% echo $((21/7)) 3 I've never used it personally either. *shrug* Not to say I think it should be dropped or kept either way, just pointing out you can do math in shells :) JE From jkeating at j2solutions.net Thu Jan 22 05:47:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 21 Jan 2004 21:47:35 -0800 Subject: Fedora Legacy Test Update Notification: tcpdump (redux for version fubar) In-Reply-To: <400F621A.5080409@togami.com> References: <200401212104.44841.jkeating@j2solutions.net> <400F621A.5080409@togami.com> Message-ID: <200401212147.36171.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 January 2004 21:39, Warren Togami wrote: > > Version 8.0 : 2.1a11-17.7.3.5 > > 8.0's packages don't match the filenames at the bottom. GRRRR! I looked at that line 4 times and saw no problem... *sigh* Notting tells me that you are allowed to release the tool that can generate these. I think I've proven myself unable to get these things right with my feeble eyes. Care to hook a brutha up? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD2P34v2HLvE71NURAgQpAJ9jsedGw9N+3JhciPSoyqTWihmCTgCfU8K/ /dE2yN5EDzL1hS6/CkGKq6U= =MmhM -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Thu Jan 22 05:49:38 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 21 Jan 2004 21:49:38 -0800 (PST) Subject: Proposal: Optional libsafe add-on? In-Reply-To: <20040122054306.GC18917@sventech.com> References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> <400F4E87.8060108@togami.com> <20040122054306.GC18917@sventech.com> Message-ID: On Wed, 21 Jan 2004, Johannes Erdfelt wrote: > > How else do you do date math in your shell scripts? > > farley:~% echo $((1+2)) > 3 > farley:~% echo $((21/7)) > 3 > > I've never used it personally either. *shrug* > > Not to say I think it should be dropped or kept either way, just > pointing out you can do math in shells :) I didn't say math, I said "date math". They're two *VERY* different things. Calculating a date is a non-trivial thing unless you're a savant. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From ms-nospam-0306 at arcor.de Thu Jan 22 08:34:52 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 09:34:52 +0100 Subject: When to bump the build? In-Reply-To: <400F25CE.2080802@togami.com> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> Message-ID: <20040122093452.76ed02dc.ms-nospam-0306@arcor.de> On Wed, 21 Jan 2004 15:22:22 -1000, Warren Togami wrote: > RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always > bump the release number. Uhm, that is certainly due to different requirements of their automated build system. -- From john.pybus at zoology.oxford.ac.uk Thu Jan 22 10:13:20 2004 From: john.pybus at zoology.oxford.ac.uk (John Pybus) Date: Thu, 22 Jan 2004 10:13:20 +0000 Subject: Proposal: Optional libsafe add-on? In-Reply-To: References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> <400F4E87.8060108@togami.com> <20040122054306.GC18917@sventech.com> Message-ID: <400FA240.7090505@zoo.ox.ac.uk> Chuck Wolber wrote: > On Wed, 21 Jan 2004, Johannes Erdfelt wrote: > > >>>How else do you do date math in your shell scripts? > I didn't say math, I said "date math". They're two *VERY* different > things. Calculating a date is a non-trivial thing unless you're a savant. But not one that cal is particularly helpful with. All that cal can do is print a tabulated calander for a particular month or year. I personally make use of gnu 'date' in scripts. Yours, John From warren at togami.com Thu Jan 22 11:34:55 2004 From: warren at togami.com (Warren Togami) Date: Thu, 22 Jan 2004 01:34:55 -1000 Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <200401211946.03110.jkeating@j2solutions.net> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401211854.20810.jkeating@j2solutions.net> <33122.216.166.133.165.1074742826.squirrel@webtest.cs.montana.edu> <200401211946.03110.jkeating@j2solutions.net> Message-ID: <400FB55F.3060405@togami.com> Is everything that you need copied from fedora.us 7.2 and 7.3? Can I delete those trees now? Warren From lowen at pari.edu Thu Jan 22 15:36:34 2004 From: lowen at pari.edu (Lamar Owen) Date: Thu, 22 Jan 2004 10:36:34 -0500 Subject: When to bump the build? In-Reply-To: <20040122093452.76ed02dc.ms-nospam-0306@arcor.de> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <20040122093452.76ed02dc.ms-nospam-0306@arcor.de> Message-ID: <200401221036.34535.lowen@pari.edu> On Thursday 22 January 2004 03:34 am, Michael Schwendt wrote: > On Wed, 21 Jan 2004 15:22:22 -1000, Warren Togami wrote: > > RH's policy is ANY PACKAGE THAT LEAVES YOUR LOCAL SYSTEM must always > > bump the release number. > > Uhm, that is certainly due to different requirements of their automated > build system. But if you do not bump the release number, you get into a situation of WHICH version of the release is really the release. The release number is just that; a serial number of which release it is from the build machine. Streamlining changes within a release number is a pain. If you must, for pre-releases use decimal releases. I try to do that upstream with the PostgreSQL packages; the first set off the press is release 0.1PGDG, up to the point I feel it is worthy of real release. In my case, all I can do for PostgreSQL is push these prereleases out to the ftp server, since there is no fancy release management system in place. When the QA has reached the level I desire (which means that it built and ran successfully on all target platforms, which for me goes all the way back to RH6.2), I bump it to a -1PGDG release. Sometimes that doesn't occur until the next PostgreSQL minor is released, so I release the -1PGDG in the next minor series. The decimal release number states what the intent is. Lining this up with the way the RH errata releases have been done is going to be interesting at best. But having two packages with identical E:V-R but different contents is terrible, even if it is within the QA queue. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From jkeating at j2solutions.net Thu Jan 22 16:05:43 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 08:05:43 -0800 Subject: mirror difference between fedora.us and fedoralegacy.org updates In-Reply-To: <400FB55F.3060405@togami.com> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401211946.03110.jkeating@j2solutions.net> <400FB55F.3060405@togami.com> Message-ID: <200401220805.44380.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 January 2004 03:34, Warren Togami wrote: > Is everything that you need copied from fedora.us 7.2 and 7.3? Can I > delete those trees now? Not exactly. I need to pull down the legacy-utils and build them and sign them w/ the fedora legacy key. By EOD today you should be able to remove them. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD/TX4v2HLvE71NURAhTgAJwKhGlrFJn8CFuGpBYwYrCvpEEEQQCgtcoz 6gl8b2uOVOhAmpDTz1KStMA= =WTv+ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Jan 22 16:08:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 08:08:18 -0800 Subject: Fedora Legacy Test Update Notification: elm (re-issue to add signed packages for 7.3) Message-ID: <200401220808.19921.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1230 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1230 2004-01-22 - --------------------------------------------------------------------- Name : elm Version 7.2 : 2.5.6-3 Version 7.3 : 2.5.6-4 Summary : The elm mail user agent. Description : Elm is a terminal mode email user agent. Elm includes all standard mailhandling features, including MIME support via metamail. Elm is still used by some people, but is no longer in active development. If you have used Elm before and you are devoted to it, you should install the elm package. If you want to use metamail's MIME support, you also need to install the metamail package. Install the screen package if you need a screen manager that can support multiple logins on one terminal. - --------------------------------------------------------------------- Update Information: CAN-2003-0966: Buffer overflow in the frm command in elm 2.5.6 and earlier allows remote attackers to execute arbitrary code via a long Subject line. - --------------------------------------------------------------------- Changelog: * Wed Jan 21 2004 Jonny Strom - - 2.5.6, minor security fix CAN-2003-0966. - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ (sha1sums) 638ec1d1bee210ac094a9264a09c4aba24708620 7.2/updates-testing/SRPMS/elm-2.5.6-3.legacy.src.rpm 58e7d0bbb603585ea19fd7a25abe2375e3e1d991 7.2/updates-testing/i386/elm-2.5.6-3.legacy.i386.rpm 29d060d14c7fda79e26db4a8b5022e4f74efb826 7.3/updates-testing/SRPMS/elm-2.5.6-4.legacy.src.rpm 1146719b902bee3221cc8fdd571675497cd602bd 7.3/updates-testing/i386/elm-2.5.6-4.legacy.i386.rpm - --------------------------------------------------------------------- Notes: RHL 8.0 did not ship with elm. This is a re-issue to fix the fact that the 7.3 rpms were not gpg signed. Now they've been signed and therefor the sha1sums have changed. Please test and comment in bugzilla. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAD/Vy4v2HLvE71NURAkznAKCGhzJ9VVarHpygqiX+4mAseby0dwCgtOTt p4sHUGfDmdGhWx/wJhClK+E= =Ur97 -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Thu Jan 22 16:31:32 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 22 Jan 2004 10:31:32 -0600 Subject: Proposal: Optional libsafe add-on? In-Reply-To: <400F4E87.8060108@togami.com> References: <400EBCF9.7010407@greenhydrant.com> <400F2F42.9020404@togami.com> <33117.216.166.133.165.1074742678.squirrel@webtest.cs.montana.edu> <200401211946.56300.jkeating@j2solutions.net> <400F4E87.8060108@togami.com> Message-ID: <20040122103132.2mec4084044wg0c8@mail.ph.utexas.edu> Quoting Warren Togami : > 1) How important is cal to servers? In all of my experience I didn't > even know it existed until now... unless is it used in some system > scripts or something? Shouldn't matter. While the FL focus is on servers, we shouldn't limit it to what we consider server-worthy. See the previous thread about people using mp3 programs on their servers to find out why. I think FL will suffer or die if we take a strict "servers don't use XXX so we don't need to worry about XXX" approach. > 2) Those who chose to use libsafe should do so only after reading the > page describing what it does, and the potential risk. The web page > would say very clearly that the server admin should TEST all of their > software and keep an eye out for strange behavior rather than install > libsafe and trust that it works. This I agree with. If we want to release it with a warning about the possible problems, then fine. -- Eric Rostetter From ms-nospam-0306 at arcor.de Thu Jan 22 16:39:12 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 17:39:12 +0100 Subject: When to bump the build? In-Reply-To: <200401221036.34535.lowen@pari.edu> References: <200401211415.05181.jkeating@j2solutions.net> <400F25CE.2080802@togami.com> <20040122093452.76ed02dc.ms-nospam-0306@arcor.de> <200401221036.34535.lowen@pari.edu> Message-ID: <20040122173912.4ddeec87.ms-nospam-0306@arcor.de> On Thu, 22 Jan 2004 10:36:34 -0500, Lamar Owen wrote: > But if you do not bump the release number, you get into a situation of WHICH > version of the release is really the release. In a bugzilla ticket, the most recent package update comment from the packager contains the name and a link to the most recent package revision which will be reviewed. In an approval, the reviewed and approved package is specified with a clearsigned MD5 fingerprint. There are no ambiguities. It's mandatory that a package update request starts with a release number which is high enough. But changes applied to the package during the review phase need not increase the release number. However, most packages do increase the release number with every package revision. So, this whole discussion is wasted time [until we have different requirements due to an automated build system or package submission process]. > But having two packages with identical E:V-R but different contents is > terrible, even if it is within the QA queue. Even more terrible is the difference between theory and practice. I've reviewed and approved a high number of packages at fedora.us, and it is a pain to request another package update just because with his latest package modification, the packager forgot to increase the release number once more or didn't add a changelog entry for trivial fixes. Requesting a new package just for an increased release number would be one of the things that make us few QA people look like we're the pedantic bad guys who turn package submission and approval into an overly tiresome process. If an updated package builds and works as expected and has a release number which is high enough for it to not cause any conflicts when published, I don't care whether each package update increased the release number. It has happened before, it will happen again, please make the packager's job easier. Encourage packager to increase the release number strictly, but don't make it mandatory until there is a specific requirement for it to be mandatory. -- From rohwedde at codegrinder.com Thu Jan 22 16:42:53 2004 From: rohwedde at codegrinder.com (Jason) Date: Thu, 22 Jan 2004 10:42:53 -0600 Subject: Final(?) Fedora Legacy Mirror Layout In-Reply-To: <200401201024.47392.jkeating@j2solutions.net> References: <200401201024.47392.jkeating@j2solutions.net> Message-ID: <20040122164253.GT3353@codegrinder.com> On Tue, Jan 20, 2004 at 10:24:41AM -0800, Jesse Keating wrote: > Ok, taken all feedback, and I've structured a mockup server: > > http://download.fedoralegacy.org > Maybe, I'm out of touch with creating apt repositories, but is it possible to use genbasedir with directories that aren't of the name RPMS.xyz or SRPMS.xyz ? -jason -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Thu Jan 22 16:51:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 08:51:53 -0800 Subject: When to bump the build? In-Reply-To: <20040122173912.4ddeec87.ms-nospam-0306@arcor.de> References: <200401211415.05181.jkeating@j2solutions.net> <200401221036.34535.lowen@pari.edu> <20040122173912.4ddeec87.ms-nospam-0306@arcor.de> Message-ID: <200401220851.58652.jkeating@j2solutions.net> On Thursday 22 January 2004 08:39, Michael Schwendt wrote: > Encourage packager to increase the release number strictly, but don't > make it mandatory until there is a specific requirement for it to be > mandatory. Sounds like a good policy to me. +1 -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From lowen at pari.edu Thu Jan 22 18:00:45 2004 From: lowen at pari.edu (Lamar Owen) Date: Thu, 22 Jan 2004 13:00:45 -0500 Subject: When to bump the build? In-Reply-To: <20040122173912.4ddeec87.ms-nospam-0306@arcor.de> References: <200401211415.05181.jkeating@j2solutions.net> <200401221036.34535.lowen@pari.edu> <20040122173912.4ddeec87.ms-nospam-0306@arcor.de> Message-ID: <200401221300.45331.lowen@pari.edu> On Thursday 22 January 2004 11:39 am, Michael Schwendt wrote: > process. If an updated package builds and works as expected and has a > release number which is high enough for it to not cause any conflicts when > published, I don't care whether each package update increased the release > number. It has happened before, it will happen again, please make the > packager's job easier. I would say that the packaging guidelines should mention that it is a good idea to increment the release every time a package is uploaded. Like you say below: > Encourage packager to increase the release number strictly, but don't make > it mandatory until there is a specific requirement for it to be mandatory. I can agree wholeheartedly with this; it is a good idea; as long as people voluntarily follow this then no mandates are necessary. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From francis.stevens at bristow.co.uk Thu Jan 22 18:02:11 2004 From: francis.stevens at bristow.co.uk (Francis Stevens) Date: Thu, 22 Jan 2004 18:02:11 +0000 (GMT) Subject: When to bump the build? Message-ID: <20040122180211.26BBB551EEF@skirnir.bristow.co.uk> I am on leave until Monday 26th January, if you require urgent assistance please contact techsupport at bristow.co.uk FAS From arvand at sbcglobal.net Thu Jan 22 19:49:22 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Thu, 22 Jan 2004 11:49:22 -0800 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability Message-ID: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> Hello, Would this affect 7.x and 8.0? Regards, Arvand -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated slocate packages fix vulnerability Advisory ID: RHSA-2004:040-01 Issue date: 2004-01-21 Updated on: 2004-01-21 Product: Red Hat Linux Keywords: Cross references: Obsoletes: CVE Names: CAN-2003-0848 - --------------------------------------------------------------------- 1. Topic: Updated slocate packages are now available that fix a heap overflow vulnerability. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 3. Problem description: Slocate is a security-enhanced version of locate, designed to find files on a system via a central database. Patrik Hornik discovered a vulnerability in Slocate versions up to and including 2.7 where a carefully crafted database could overflow a heap-based buffer. A local user could exploit this vulnerability to gain "slocate" group privileges and then read the entire slocate database. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0848 to this issue. Users of Slocate should upgrade to these erratum packages, which contain a patch from Kevin Lindsay that causes slocate to drop privileges before reading a user-supplied database. 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 Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. If up2date fails to connect to Red Hat Network due to SSL Certificate Errors, you need to install a version of the up2date client with an updated certificate. The latest version of up2date is available from the Red Hat FTP site and may also be downloaded directly from the RHN website: https://rhn.redhat.com/help/latest-up2date.pxt 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 114014 - CAN-2003-0858 slocate buffer overflow 6. RPMs required: Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/slocate-2.7-2.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/slocate-2.7-2.i386.rpm 7. Verification: MD5 sum Package Name - -------------------------------------------------------------------------- e3a6fc1f4a5330433d1e7f3c0f56b050 9/en/os/SRPMS/slocate-2.7-2.src.rpm 37c73b3b4cc7bc8791f48abfac99c63e 9/en/os/i386/slocate-2.7-2.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available from https://www.redhat.com/security/keys.html 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 md5sum with the following command: md5sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0848 9. Contact: The Red Hat security contact is . More contact details at https://www.redhat.com/solutions/security/news/contact.html Copyright 2003 Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFAD/yuXlSAg2UNWIIRAuzgAKChfJgomxyclmW2/eVPyiJLG0iu5ACgll9R LMEjNSrwhGcrPqy2zCwA+zY= =ZglC -----END PGP SIGNATURE----- _______________________________________________ Redhat-watch-list mailing list To unsubscribe, visit: https://www.redhat.com/mailman/listinfo/redhat-watch-list From skvidal at phy.duke.edu Thu Jan 22 19:47:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 22 Jan 2004 14:47:17 -0500 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> Message-ID: <1074800837.16387.78.camel@binkley> On Thu, 2004-01-22 at 14:49, Arvand Sabetian wrote: > Hello, > > Would this affect 7.x and 8.0? > yes it does - we talked about it yesterday.. if you want to work on it - that'd be cool. -sv From ms-nospam-0306 at arcor.de Thu Jan 22 19:54:49 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 20:54:49 +0100 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> Message-ID: <20040122205449.7dd23cb3.ms-nospam-0306@arcor.de> On Thu, 22 Jan 2004 11:49:22 -0800, Arvand Sabetian wrote: > Would this affect 7.x and 8.0? Quoting: http://marc.theaimsgroup.com/?l=bugtraq&m=106546447321274&w=2 : Who is affected? : ---------------- : : Affected are all RedHat distributions up to version 9.0 including. : : slocate version 2.6 and below is vulnerable. slocate version 2.7 and : all packages based on this version are not vulnerable. rh73 has slocate-2.6-1, for instance. -- From ms-nospam-0306 at arcor.de Thu Jan 22 20:22:48 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 21:22:48 +0100 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <1074800837.16387.78.camel@binkley> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> Message-ID: <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> On Thu, 22 Jan 2004 14:47:17 -0500, seth vidal wrote: > On Thu, 2004-01-22 at 14:49, Arvand Sabetian wrote: > > Hello, > > > > Would this affect 7.x and 8.0? > > > > yes it does - we talked about it yesterday.. > > > if you want to work on it - that'd be cool. What would you suggest? (The security patch is for slocate 2.6) rh72: slocate-2.6-1 rh73: slocate-2.6-1 rh80: slocate-2.6-4 Upgrade rh72/rh73 to rh80's version plus the patch? Or upgrade rh72/rh73/rh80 to rh9's erratum which is slocate 2.7? -- From peter.peltonen at iki.fi Thu Jan 22 20:29:12 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 22 Jan 2004 22:29:12 +0200 Subject: no yum headers for rh8.0 os and updates at fedora.us? In-Reply-To: <200401220805.44380.jkeating@j2solutions.net> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401211946.03110.jkeating@j2solutions.net> <400FB55F.3060405@togami.com> <200401220805.44380.jkeating@j2solutions.net> Message-ID: <40103298.40403@iki.fi> Hi, There seems to be no yum headers for rh8.0 os and updates at fedora.us: http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.os/ http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.updates/ The RPMS.legacy dir has the headers and they also exist for 7.x legacy, os and updates channels. Or am I missing something obivious here? I also found it confusing that the packages in the legacy channel were signed with the fedora and not with he legacy GPG key: ---- [root at palermo asc]# rpm --checksig -v /var/cache/yum/legacy/packages/rpm-4.1.1-1.8x.i386.rpm /var/cache/yum/legacy/packages/rpm-4.1.1-1.8x.i386.rpm: Header V3 DSA signature: OK, key ID 8df56d05 Header SHA1 digest: OK (01746a3fe9d53fe63473215b6564ce315ef40cda) MD5 digest: OK (3504db31fd4668c33c6f15dce62151ec) V3 DSA signature: OK, key ID 8df56d05 [root at palermo asc]# gpg --list-keys fedora pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) sub 2048g/D12E351D 2004-01-19 pub 1024D/8DF56D05 2003-03-27 Fedora Linux (RPMS) sub 2048g/6E208B8B 2003-03-27 ---- Regards, Peter From jkeating at j2solutions.net Thu Jan 22 20:24:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 12:24:36 -0800 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> Message-ID: <200401221224.41115.jkeating@j2solutions.net> On Thursday 22 January 2004 12:22, Michael Schwendt wrote: > What would you suggest? (The security patch is for slocate 2.6) > > rh72: slocate-2.6-1 > rh73: slocate-2.6-1 > rh80: slocate-2.6-4 > > Upgrade rh72/rh73 to rh80's version plus the patch? > Or upgrade rh72/rh73/rh80 to rh9's erratum which is slocate 2.7? It had been advised tome that there are multiple bugfixes that went into 2.7, that we should consider if we were going to maintain 2.6. I suggest that since this is a low priority security flaw, we take the time to examine slocate and see if anything will break if we upgrade it to 2.7. If nothing breaks, I recommend that we upgrade and unify it across our platforms. Thoughts? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Jan 22 20:26:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 12:26:24 -0800 Subject: no yum headers for rh8.0 os and updates at fedora.us? In-Reply-To: <40103298.40403@iki.fi> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401220805.44380.jkeating@j2solutions.net> <40103298.40403@iki.fi> Message-ID: <200401221226.24183.jkeating@j2solutions.net> On Thursday 22 January 2004 12:29, Peter Peltonen wrote: > There seems to be no yum headers for rh8.0 os and updates at > fedora.us: > > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.os/ > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.updates/ > > The RPMS.legacy dir has the headers and they also exist for 7.x > legacy, os and updates channels. Or am I missing something obivious > here? > > > I also found it confusing that the packages in the legacy channel > were signed with the fedora and not with he legacy GPG key: there is some confusion going on. We're cutting over from fedora.us's tree to http://download.fedoralegacy.org. I'm currently building the apt repository and populating the directories. I'll announce to the list when it's ready. I should have it ready by tonight, in time to push out our first couple releases. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From ms-nospam-0306 at arcor.de Thu Jan 22 20:34:28 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 21:34:28 +0100 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <200401221224.41115.jkeating@j2solutions.net> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> <200401221224.41115.jkeating@j2solutions.net> Message-ID: <20040122213428.6501e8e4.ms-nospam-0306@arcor.de> On Thu, 22 Jan 2004 12:24:36 -0800, Jesse Keating wrote: > It had been advised tome that there are multiple bugfixes that went into > 2.7, that we should consider if we were going to maintain 2.6. I > suggest that since this is a low priority security flaw, we take the > time to examine slocate and see if anything will break if we upgrade it > to 2.7. If nothing breaks, I recommend that we upgrade and unify it > across our platforms. > > Thoughts? In the meantime, here's an updated slocate 2.6 package: https://bugzilla.fedora.us/show_bug.cgi?id=1232 Will compare with 2.7 later. -- From jonny.strom at netikka.fi Thu Jan 22 20:49:23 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 22 Jan 2004 22:49:23 +0200 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <20040122213428.6501e8e4.ms-nospam-0306@arcor.de> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> <200401221224.41115.jkeating@j2solutions.net> <20040122213428.6501e8e4.ms-nospam-0306@arcor.de> Message-ID: <40103753.7090208@netikka.fi> Michael Schwendt wrote: > On Thu, 22 Jan 2004 12:24:36 -0800, Jesse Keating wrote: > > >>It had been advised tome that there are multiple bugfixes that went into >>2.7, that we should consider if we were going to maintain 2.6. I >>suggest that since this is a low priority security flaw, we take the >>time to examine slocate and see if anything will break if we upgrade it >>to 2.7. If nothing breaks, I recommend that we upgrade and unify it >>across our platforms. >> >>Thoughts? > > > In the meantime, here's an updated slocate 2.6 package: > > https://bugzilla.fedora.us/show_bug.cgi?id=1232 > > Will compare with 2.7 later. > Thanks! I was just working on the backport I guess I can stop that now when it is already done :) Johnny From peter.peltonen at iki.fi Thu Jan 22 20:51:33 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 22 Jan 2004 22:51:33 +0200 Subject: no yum headers for rh8.0 os and updates at fedora.us? In-Reply-To: <200401221226.24183.jkeating@j2solutions.net> References: <32899.216.166.133.165.1074736885.squirrel@webtest.cs.montana.edu> <200401220805.44380.jkeating@j2solutions.net> <40103298.40403@iki.fi> <200401221226.24183.jkeating@j2solutions.net> Message-ID: <401037D5.6010102@iki.fi> Jesse Keating wrote: > there is some confusion going on. We're cutting over from fedora.us's > tree to http://download.fedoralegacy.org. I'm currently building the > apt repository and populating the directories. I'll announce to the > list when it's ready. I should have it ready by tonight, in time to > push out our first couple releases. Ok. As soon as the change is ready I'd suggest updating the download page http://www.fedoralegacy.org/download/ which lead me pointing my yum at fedora.us. Or is it so that fedora.us will be mirroring fedoralegacy.org and I just have to wait and everything will be working ok with my current setup? Regards, Peter From heinlein at cse.ogi.edu Thu Jan 22 21:06:38 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Thu, 22 Jan 2004 13:06:38 -0800 (PST) Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <200401221224.41115.jkeating@j2solutions.net> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> <200401221224.41115.jkeating@j2solutions.net> Message-ID: On Thu, 22 Jan 2004, Jesse Keating wrote: > I suggest that since this is a low priority security flaw, we take > the time to examine slocate and see if anything will break if we > upgrade it to 2.7. If nothing breaks, I recommend that we upgrade > and unify it across our platforms. +1 --Paul Heinlein From ms-nospam-0306 at arcor.de Thu Jan 22 21:21:28 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 22 Jan 2004 22:21:28 +0100 Subject: FW: [RHSA-2004:040-01] Updated slocate packages fix vulnerability In-Reply-To: <200401221224.41115.jkeating@j2solutions.net> References: <200401221948.i0MJmmMI205924@pimout3-ext.prodigy.net> <1074800837.16387.78.camel@binkley> <20040122212248.54b42b6e.ms-nospam-0306@arcor.de> <200401221224.41115.jkeating@j2solutions.net> Message-ID: <20040122222128.5f5b94aa.ms-nospam-0306@arcor.de> On Thu, 22 Jan 2004 12:24:36 -0800, Jesse Keating wrote: > It had been advised tome that there are multiple bugfixes that went into > 2.7, that we should consider if we were going to maintain 2.6. I > suggest that since this is a low priority security flaw, we take the > time to examine slocate and see if anything will break if we upgrade it > to 2.7. If nothing breaks, I recommend that we upgrade and unify it > across our platforms. > > Thoughts? Added a 2.7-0.7.3 src.rpm to the same ticket: https://bugzilla.fedora.us/show_bug.cgi?id=1232 Had to fix Red Hat's 2.7-2 erratum with regard to automake regeneration for rh72 to rh80. -- From jkeating at j2solutions.net Fri Jan 23 00:51:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 16:51:37 -0800 Subject: download.fedoralegacy.org cutover Message-ID: <200401221651.41904.jkeating@j2solutions.net> I'm almost ready for the cut-over. The only thing that is missing is the legacy-addons content. Yum needs to be rebuilt to have legacy's GPG key, as well as point to download.fedoralegacy.org instead of download.fedora.us. Whoever was working on yum, can they please publish it? BTW, apt is live with download.fedoralegacy.org. rpm http://download.fedoralegacy.org/apt redhat/7.2/i386 os updates updates-testing legacy-utils rpm-src http://download.fedoralegacy.org/apt redhat/7.2/i386 os updates updates-testing legacy-utils Of course, replace "7.2" with your actual release. Can somebody please verify that apt is working correctly? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Fri Jan 23 04:55:34 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 22 Jan 2004 22:55:34 -0600 Subject: download.fedoralegacy.org cutover In-Reply-To: <200401221651.41904.jkeating@j2solutions.net> References: <200401221651.41904.jkeating@j2solutions.net> Message-ID: <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> Quoting Jesse Keating : > I'm almost ready for the cut-over. The only thing that is missing is I've made what I assume are the needed/correct changes to the web site in CVS. Feel free to pull from CVS to the web site when you make the change over. Or let me know and I'll do it when I get the okay and the time. Once done, please check the changes and comment/correct. The pages affected are the faq page and the download page. -- Eric Rostetter From jkeating at j2solutions.net Fri Jan 23 06:34:29 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Jan 2004 22:34:29 -0800 Subject: [FLSA-2004:1230] Updated elm resolves security vulnerability Message-ID: <200401222234.37331.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated elm resolves security vulnerability Advisory ID: FLSA:1230 Issue date: 2004-01-22 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1230 CVE Names: CAN-2003-0966 - ----------------------------------------------------------------------- 1. Topic: Updated elm packages are now available that fix a security vulnerability which may allow remote attackers to execute arbitrary code via a long Subject line. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 3. Problem description: Elm is a terminal mode email user agent. The frm command is provided as part of the Elm packages and gives a summary list of the sender and subject of selected messages in a mailbox or folder. A buffer overflow vulnerability was found in the frm command. An attacker could create a message with an overly long Subject line such that when the frm command is run by a victim arbitrary code is executed. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0966 to this issue. Users of the frm command should update to these erratum packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Paul Rubin for discovering and disclosing this issue, and Jonny Strom for providing a backported fix for Red Hat Linux 7.2 and 7.3. All users are advised to upgrade to these errata packages, which contain a backported security patch that 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1230 - elm security fix in rh7x http://bugzilla.redhat.com - 112078 - CAN-2003-0966 buffer overflow in frm command 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/elm-2.5.6-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/elm-2.5.6-3.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/elm-2.5.6-4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/elm-2.5.6-4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 638ec1d1bee210ac094a9264a09c4aba24708620 7.2/updates/SRPMS/elm-2.5.6-3.legacy.src.rpm 58e7d0bbb603585ea19fd7a25abe2375e3e1d991 7.2/updates/i386/elm-2.5.6-3.legacy.i386.rpm 29d060d14c7fda79e26db4a8b5022e4f74efb826 7.3/updates/SRPMS/elm-2.5.6-4.legacy.src.rpm 1146719b902bee3221cc8fdd571675497cd602bd 7.3/updates/i386/elm-2.5.6-4.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0966 http://rhn.redhat.com/errata/RHSA-2004-009.html https://bugzilla.fedora.us/show_bug.cgi?id=1230 9. Contact: The Fedora Legacy security contact is . More project details at https://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAEMB74v2HLvE71NURAlAzAJ9wVlGlHcrNhZRFoSCZ81IsaO9eIwCdFuaf IVw7KAQfnTKdGMzgJDh4+Ps= =FzYs -----END PGP SIGNATURE----- From jpdalbec at ysu.edu Fri Jan 23 14:41:18 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 23 Jan 2004 09:41:18 -0500 Subject: (Belated) Self-intro: John Dalbec Message-ID: <4011328E.8010404@ysu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. John Dalbec 2. USA, Youngstown (Ohio) 3. Software Specialist/Sysadmin 4. Youngstown State University 5. Your goals in the Fedora Project * Which packages do you want to see published? Security updates. * Do you want to do QA? I guess. I'm still not sure how much testing is needed. 6. Historical qualifications * What other projects have you worked on in the past? I've sent patches to Red Hat's bugzilla for a few issues. * What computer languages and other skills do you know? C, C++, Perl * Why should we trust you? <--- too blunt? As a sysadmin I think I've developed a healthy paranoia. 7. GPG KEYID and fingerprint pub 1024D/5740EDAB 2004-01-23 John Dalbec (Fedora-Legacy key) Key fingerprint = F168 3810 A415 288A 2179 F191 24BE 00FA 5740 EDAB sub 1024g/457CBBCD 2004-01-23 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFAETFuJL4A+ldA7asRAjNQAJsESCsVvV8hA4dSqaqAvEWKaAdUUgCdHcY9 PiEuiTOWARxVHriNZXH1Dn0= =N4f8 -----END PGP SIGNATURE----- From gmott at ntlworld.com Fri Jan 23 16:34:02 2004 From: gmott at ntlworld.com (g) Date: Fri, 23 Jan 2004 16:34:02 +0000 Subject: /etc/yum.conf In-Reply-To: <200401201611.04090.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> Message-ID: <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> hello legacists, it seems like this list is a "devel" list. is there or should there be a separate "users" list? > On Tuesday 20 January 2004 09:32, Peter M. Abraham wrote: > > Can some one please post their /etc/yum.conf they are using with > > Fedora for RedHat 7.3? i just installed 7.2 from CD, then yum from 7.2 legacy, with rpm-* and popt by hand from 7.2 updates, to satisy yum dependencies (tho i ended up using --nodeps, not caring about gnorpm et al, and presuming it'd all come down once i ran yum update). even after importing the various keys, it took me awhile to get gpg keys working. turned out it was because i use a superuser account other than "root". when i deleted ~/.gnupg and linked it to /root/.gnupg, yum gpg keys were fine. yum update then ran successfully. #/etc/yum.conf: [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest exactarch=1 exclude= # Added this because some mirrors go down and then retying takes forever. retries=1 [base] name=Red Hat Linux $releasever base baseurl=http://ftp-stud.fht-esslingen.de/fedora/fedora/redhat/$releasever/$basearch/RPMS.os gpgcheck=1 [updates] name=Red Hat Linux $releasever updates baseurl=http://ftp-stud.fht-esslingen.de/fedora/fedora/redhat/$releasever/$basearch/RPMS.updates gpgcheck=1 [legacy] name=Fedora Legacy tools for Red Hat Linux $releasever baseurl=http://ftp-stud.fht-esslingen.de/fedora/fedora/redhat/$releasever/$basearch/RPMS.legacy gpgcheck=1 From jkeating at j2solutions.net Fri Jan 23 22:13:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Jan 2004 14:13:32 -0800 Subject: download.fedoralegacy.org cutover In-Reply-To: <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> References: <200401221651.41904.jkeating@j2solutions.net> <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> Message-ID: <200401231413.36711.jkeating@j2solutions.net> On Thursday 22 January 2004 20:55, Eric Rostetter wrote: > I've made what I assume are the needed/correct changes to the web > site in CVS. Feel free to pull from CVS to the web site when you > make the change over. Or let me know and I'll do it when I get the > okay and the time. > > Once done, please check the changes and comment/correct. The pages > affected are the faq page and the download page. Please deploy the webpage. I've put the updated yum in the 7.2 and 7.3 repositories, updated yum and apt metadata. We're ready to go live! Which reminds me. we need an 8.0 build of yum that has the updated stuff. *grumble* -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Fri Jan 23 22:44:01 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 23 Jan 2004 16:44:01 -0600 Subject: download.fedoralegacy.org cutover In-Reply-To: <200401231413.36711.jkeating@j2solutions.net> References: <200401221651.41904.jkeating@j2solutions.net> <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> <200401231413.36711.jkeating@j2solutions.net> Message-ID: <20040123164401.lyzoggsw84g4g0oc@mail.ph.utexas.edu> Quoting Jesse Keating : > Please deploy the webpage. I've put the updated yum in the 7.2 and 7.3 > repositories, updated yum and apt metadata. We're ready to go live! Done. let me know if there are any problems with the changes, additions to be made, etc. -- Eric Rostetter From jkeating at j2solutions.net Fri Jan 23 22:42:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Jan 2004 14:42:13 -0800 Subject: download.fedoralegacy.org cutover In-Reply-To: <20040123164401.lyzoggsw84g4g0oc@mail.ph.utexas.edu> References: <200401221651.41904.jkeating@j2solutions.net> <200401231413.36711.jkeating@j2solutions.net> <20040123164401.lyzoggsw84g4g0oc@mail.ph.utexas.edu> Message-ID: <200401231442.13658.jkeating@j2solutions.net> On Friday 23 January 2004 14:44, Eric Rostetter wrote: > Done. let me know if there are any problems with the changes, > additions to be made, etc. For now lets remove the link to the fedora.us mirror list, as they aren't a fedoralegacy mirror list. We'll have our own mirror structure. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Jan 23 23:37:25 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Jan 2004 15:37:25 -0800 Subject: State of Fedora Legacy Message-ID: <200401231537.25673.jkeating@j2solutions.net> Hello all! With the release of our first update, I thought I'd take a moment to speak(!!) to all of you. First off, Thank you EVER so much for all the support you've given this project, and all the help that you've given to get us to the point we are now. This project really couldn't have gone anywhere without the community, and it's very heartwarming to see the community come through. In a short amount of time we got a LOT of work done. We have a wonderful website, thanks to the hard work of Eric Rostetter, with other contributors as well. We have a functioning bugzilla system thanks to Warren and the Fedora.us folks. We have Mailing lists thanks to Red Hat folks, a master mirror layout, complete with yum and apt support thanks to Legacy folk's input, and the input from external resources, and now we have packages published, and waiting for final verification to be published, thanks to the hardwork of many of you. As we look forward, I'd like to direct attention at creating some good documentation content, building upon and clarifying a lot of what exists for fedora.us, but made specific and clear for Fedora Legacy. We have lots of verification to do, for the packages in updates-testing. As soon as we can verify those, they can be published as well. We need people to continue to report security notices to this list, so that we can evaluate the exposure of our supported releases. And we need people to spread the word, that the Fedora Legacy project is alive, is kicking, and is not going AWAY! So in closing, keep up the good work, and spread the news, we are ALIVE! Thank you EVERYBODY! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From heinlein at cse.ogi.edu Fri Jan 23 23:49:01 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Fri, 23 Jan 2004 15:49:01 -0800 (PST) Subject: State of Fedora Legacy In-Reply-To: <200401231537.25673.jkeating@j2solutions.net> References: <200401231537.25673.jkeating@j2solutions.net> Message-ID: On Fri, 23 Jan 2004, Jesse Keating wrote: > First off, Thank you EVER so much for all the support you've given > this project, Thank YOU, Jesse. Your work is much appreciated. -- Paul Heinlein From fedora-legacy-list at arrrrrr.com Sat Jan 24 01:08:24 2004 From: fedora-legacy-list at arrrrrr.com (Ryan Finnie) Date: Fri, 23 Jan 2004 17:08:24 -0800 (PST) Subject: party-updates mailing lists update Message-ID: FYI, Panu Matilainen send a message to this list on the 16th ("[Fwd: [WBEL-devel] Rebuilt Progeny RPMs for RHL 7.2/7.3/8.0]", sorry I can't reference it, I just subscribed). I just wanted to let you know that if you tried to subscribe to the party-announce at lists.colobox.com list and it bounced, try again. It was a DNS problem and has hence been fixed. For those who care, lists.colobox.com was a CNAME for colobox.com, and appearantly some MTAs don't care much for that setup, and, in this case, will rewrite the To: address from party-announce-subscribe at lists.colobox.com to party-announce-subscribe at colobox.com, which of course fails. Cheers! RF From mattdm at mattdm.org Sat Jan 24 04:19:17 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Jan 2004 23:19:17 -0500 Subject: State of Fedora Legacy In-Reply-To: References: <200401231537.25673.jkeating@j2solutions.net> Message-ID: <20040124041917.GA6458@jadzia.bu.edu> On Fri, Jan 23, 2004 at 03:49:01PM -0800, Paul Heinlein wrote: > > First off, Thank you EVER so much for all the support you've given > > this project, > Thank YOU, Jesse. Your work is much appreciated. Yeah, I'm going to have to me-too this. Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From maillist at jasonlim.com Sat Jan 24 04:32:17 2004 From: maillist at jasonlim.com (Jason Lim) Date: Sat, 24 Jan 2004 12:32:17 +0800 Subject: State of Fedora Legacy References: <200401231537.25673.jkeating@j2solutions.net> Message-ID: <049601c3e233$0c750170$0900a8c0@SYSTEM9> > On Fri, 23 Jan 2004, Jesse Keating wrote: > > > First off, Thank you EVER so much for all the support you've given > > this project, > > Thank YOU, Jesse. Your work is much appreciated. > > -- Paul Heinlein Hear Hear! Jas From chuckw at quantumlinux.com Sat Jan 24 06:11:52 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 23 Jan 2004 22:11:52 -0800 (PST) Subject: State of Fedora Legacy In-Reply-To: <20040124041917.GA6458@jadzia.bu.edu> Message-ID: On Fri, 23 Jan 2004, Matthew Miller wrote: > On Fri, Jan 23, 2004 at 03:49:01PM -0800, Paul Heinlein wrote: > > > First off, Thank you EVER so much for all the support you've given > > > this project, > > Thank YOU, Jesse. Your work is much appreciated. > > Yeah, I'm going to have to me-too this. Thanks! Heh, yeah me 3. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Sat Jan 24 09:21:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 01:21:11 -0800 Subject: Fedora Legacy Test Update Notification: cvs Message-ID: <200401240121.18041.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORA-2004-1207 2004-01-24 - --------------------------------------------------------------------- Name : cvs Version 7.2 : 1.11.1p1-9.7.legacy Version 7.3 : 1.11.1p1-9.7.legacy Version 7.2 : 1.11.2-9.legacy Summary : A version control system. Description : CVS (Concurrent Version System) is a version control system that can record the history of your files (usually, but not always, source code). CVS only stores the differences between versions, instead of every version of every file you have ever created. CVS also keeps a log of who, when, and why changes occurred. CVS is very helpful for managing releases and controlling the concurrent editing of source files among multiple authors. Instead of providing version control for a collection of files in a single directory, CVS provides version control for a hierarchical collection of directories consisting of revision controlled files. These directories and files can then be combined together to form a software release. - --------------------------------------------------------------------- Update Information: CAN-2003-0977: CVS server before 1.11.10 may allow attackers to cause the CVS server to create directories and files in the file system root directory via malformed module requests. 2003-12-18: Stable CVS Version 1.11.11 Released! (security update) Contributed by: Derek Price Stable CVS 1.11.11 has been released. Stable releases contain only bug fixes from previous versions of CVS. This release adds code to the CVS server to prevent it from continuing as root after a user login, as an extra failsafe against a compromise of the CVSROOT/passwd file. Previously, any user with the ability to write the CVSROOT/passwd file could execute arbitrary code as the root user on systems with CVS pserver access enabled. We recommend this upgrade for all CVS servers! - --------------------------------------------------------------------- Changelog: * Mon Jan 12 2004 Jason Rohwedder 1.11.1p1-9.7.legacy - - applied cvs-1.11.9-absolute-modules.patch - - to make Seth's previous changelog true :) - - He actually patched - - http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 * Mon Jan 12 2004 Seth Vidal - - apply security patch for CAN-2003-0977 * Tue Dec 30 2003 Seth Vidal 1.11.1p1-8.7.duke.1 - - apply security patch for: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0977 - - second patch to make the above build - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad 7.2/updates-testing/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm 469e08276fd61a06f816d4d7df68bc6c85a98560 7.2/updates-testing/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm 46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad 7.3/updates-testing/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm 1dfba0ce740a20bd0977eede82f606ea2f907b00 7.3/updates-testing/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm 31e98f14255c132d3f548a51096b0c444a45797a 8.0/updates-testing/SRPMS/cvs-1.11.2-9.legacy.src.rpm e415df08fdfd35216c68651aa5214e7ecdb04268 8.0/updates-testing/i386/cvs-1.11.2-9.legacy.i386.rpm Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. - --------------------------------------------------------------------- Please test and comment. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAEjkN4v2HLvE71NURAiFHAJ91TtcDliZTgLkVp5ZAQcVGJXU54gCfRgsQ CcxdIc3lZNe4NY7cA/68cYY= =m7BJ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 24 09:26:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 01:26:58 -0800 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200401240121.18041.jkeating@j2solutions.net> References: <200401240121.18041.jkeating@j2solutions.net> Message-ID: <200401240126.59180.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 01:21, Jesse Keating wrote: > Version 7.2 : 1.11.1p1-9.7.legacy > Version 7.3 : 1.11.1p1-9.7.legacy > Version 7.2 : 1.11.2-9.legacy Make that: Version 7.2 : 1.11.1p1-9.7.legacy Version 7.3 : 1.11.1p1-9.7.legacy Version 8.0 : 1.11.2-9.legacy one of these frickin days I'll get an announcement out w/OUT typos. *sigh* - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAEjpi4v2HLvE71NURAkB8AKCkdzA7BD4LiT1xUiBnKXBwbKrKEgCgikAM Km4WTdmld8a/3E8fmprItVk= =PBbn -----END PGP SIGNATURE----- From admin at cs.montana.edu Sat Jan 24 09:39:32 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Sat, 24 Jan 2004 02:39:32 -0700 (MST) Subject: download.fedoralegacy.org cutover In-Reply-To: <200401221651.41904.jkeating@j2solutions.net> References: <200401221651.41904.jkeating@j2solutions.net> Message-ID: <4267.216.166.133.165.1074937172.squirrel@webtest.cs.montana.edu> Jesse Keating said: > I'm almost ready for the cut-over. The only thing that is missing is > the legacy-addons content. Yum needs to be rebuilt to have legacy's > GPG key, as well as point to download.fedoralegacy.org instead of > download.fedora.us. Whoever was working on yum, can they please > publish it? > > BTW, apt is live with download.fedoralegacy.org. > I downloaded and installed all the updates, now I just need to rsync fedorlegacy to my local mirror for updates on my campus. I think I have about 400 redhat boxes on my campus I need to keep up to date. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From chuckw at quantumlinux.com Sat Jan 24 09:58:47 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 24 Jan 2004 01:58:47 -0800 (PST) Subject: download.fedoralegacy.org cutover In-Reply-To: <4267.216.166.133.165.1074937172.squirrel@webtest.cs.montana.edu> References: <200401221651.41904.jkeating@j2solutions.net> <4267.216.166.133.165.1074937172.squirrel@webtest.cs.montana.edu> Message-ID: On Sat, 24 Jan 2004, Lucas Albers wrote: > > I downloaded and installed all the updates, now I just need to rsync > fedorlegacy to my local mirror for updates on my campus. I think I have > about 400 redhat boxes on my campus I need to keep up to date. I offered to set up and maintain rsyncd as well as ftpd on the FL server, but I have not heard back from Jesse. Jesse: Has this already been done? -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From maillist at jasonlim.com Sat Jan 24 10:50:24 2004 From: maillist at jasonlim.com (Jason Lim) Date: Sat, 24 Jan 2004 18:50:24 +0800 Subject: download.fedoralegacy.org cutover References: <200401221651.41904.jkeating@j2solutions.net> <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> Message-ID: <009b01c3e267$fca02b50$0900a8c0@SYSTEM9> > Once done, please check the changes and comment/correct. The pages affected > are the faq page and the download page. Is it me, or is: http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/ empty? No yum? Jas From shugal at gmx.de Sat Jan 24 15:30:15 2004 From: shugal at gmx.de (Martin Stricker) Date: Sat, 24 Jan 2004 16:30:15 +0100 Subject: download.fedoralegacy.org cutover References: <200401221651.41904.jkeating@j2solutions.net> <20040122225534.2680gw0ww0cg4wko@mail.ph.utexas.edu> <009b01c3e267$fca02b50$0900a8c0@SYSTEM9> Message-ID: <40128F87.E0D5BFA8@gmx.de> Jason Lim wrote: > Is it me, or is: > http://download.fedoralegacy.org/redhat/8.0/legacy-utils/i386/ > empty? No yum? See one of the earlier mails in this thread: yum for RHL8.0-legacy still needs to be build. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Linux Migration Project: http://www.linux-migration.org/ Red Hat Linux 9 for low memory: http://www.rule-project.org/ Registered Linux user #210635: http://counter.li.org/ From SNielsen at comscore.com Sat Jan 24 16:36:22 2004 From: SNielsen at comscore.com (Nielsen, Steve) Date: Sat, 24 Jan 2004 11:36:22 -0500 Subject: mirror site questions for legacy RPMs Message-ID: <66E9FEE99E96034ABB4DE197A927DBF1134535@csiadmail01.office.comscore.com> A couple of questions: I checked the mirror list on fedoralegacy.org (it points to fedora.us mirror wiki) and none of the mirrors listed have the legacy RPMs yet. How long does it usually take for the RPMs to start appearing on the mirrors? Will the new layout of the fedora legacy RPMs become the defacto standard for everything or just the legacy RPMs? IOW, will the layout for the current "production" fedora core 1 + updates + extras on fedora.us adopt this layout as well? I think having a consistent layout for everything makes sense and reduces administrative headache. Steve From jkeating at j2solutions.net Sat Jan 24 17:57:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 09:57:47 -0800 Subject: download.fedoralegacy.org cutover In-Reply-To: References: <200401221651.41904.jkeating@j2solutions.net> <4267.216.166.133.165.1074937172.squirrel@webtest.cs.montana.edu> Message-ID: <200401240957.53716.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 01:58, Chuck Wolber wrote: > I offered to set up and maintain rsyncd as well as ftpd on the FL > server, but I have not heard back from Jesse. > > Jesse: Has this already been done? No, not yet. I may work with you on this, but the plan was to get a mockup running, and transfer it to a REAL mirror server. This is somewhat a temporary target of the download.fedoralegacy.org dns record. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAErIh4v2HLvE71NURAhjVAJ9fotLXChIQaln7rTz5P081/SXP8QCfclMj ClVf1B2q59slM+QHzDNH1Wo= =5hQO -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 24 18:02:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 10:02:44 -0800 Subject: mirror site questions for legacy RPMs In-Reply-To: <66E9FEE99E96034ABB4DE197A927DBF1134535@csiadmail01.office.comscore.com> References: <66E9FEE99E96034ABB4DE197A927DBF1134535@csiadmail01.office.comscore.com> Message-ID: <200401241002.44209.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 08:36, Nielsen, Steve wrote: > I checked the mirror list on fedoralegacy.org (it points to fedora.us > mirror wiki) and none of the mirrors listed have the legacy RPMs yet. > How long does it usually take for the RPMs to start appearing on the > mirrors? Fedoralegacy.org is no longer directly using fedora.us as it's repository, nor fedora.us's mirror systems. fedoralegacy is creating it's own mirror system, of which fedora.us may be a mirror. > Will the new layout of the fedora legacy RPMs become the defacto > standard for everything or just the legacy RPMs? IOW, will the layout > for the current "production" fedora core 1 + updates + extras on > fedora.us adopt this layout as well? I think having a consistent > layout for everything makes sense and reduces administrative > headache. I cannot say what fedora.us will do with their structure. It's rather up in the air with the impending status of Fedora Extras and Alternatives. Fedoralegacy.org will continue the the same layout for all the releases we support. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAErNE4v2HLvE71NURArepAJwK6BS6WNuc4MM9bFpU5LwPy6OVLQCgsJsm qZqkfTgZ+ItHnvskYit3egc= =TKow -----END PGP SIGNATURE----- From SNielsen at comscore.com Sat Jan 24 18:27:24 2004 From: SNielsen at comscore.com (Nielsen, Steve) Date: Sat, 24 Jan 2004 13:27:24 -0500 Subject: mirror site questions for legacy RPMs Message-ID: <66E9FEE99E96034ABB4DE197A927DBF1D17E1F@csiadmail01.office.comscore.com> The docs on fedoralegacy point to fedora.us as the mirror to use. Just a little confusing. Do you know what the timings are for the fedoralegacy mirrors to be up and running and available? Will ftp, http and rsync be available ? Steve -----Original Message----- From: Jesse Keating [mailto:jkeating at j2solutions.net] Sent: Saturday, January 24, 2004 12:03 PM To: fedora-legacy-list at redhat.com Subject: Re: mirror site questions for legacy RPMs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 08:36, Nielsen, Steve wrote: > I checked the mirror list on fedoralegacy.org (it points to fedora.us > mirror wiki) and none of the mirrors listed have the legacy RPMs yet. > How long does it usually take for the RPMs to start appearing on the > mirrors? Fedoralegacy.org is no longer directly using fedora.us as it's repository, nor fedora.us's mirror systems. fedoralegacy is creating it's own mirror system, of which fedora.us may be a mirror. > Will the new layout of the fedora legacy RPMs become the defacto > standard for everything or just the legacy RPMs? IOW, will the layout > for the current "production" fedora core 1 + updates + extras on > fedora.us adopt this layout as well? I think having a consistent > layout for everything makes sense and reduces administrative > headache. I cannot say what fedora.us will do with their structure. It's rather up in the air with the impending status of Fedora Extras and Alternatives. Fedoralegacy.org will continue the the same layout for all the releases we support. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAErNE4v2HLvE71NURArepAJwK6BS6WNuc4MM9bFpU5LwPy6OVLQCgsJsm qZqkfTgZ+ItHnvskYit3egc= =TKow -----END PGP SIGNATURE----- -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Sat Jan 24 18:44:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 10:44:17 -0800 Subject: mirror site questions for legacy RPMs In-Reply-To: <66E9FEE99E96034ABB4DE197A927DBF1D17E1F@csiadmail01.office.comscore.com> References: <66E9FEE99E96034ABB4DE197A927DBF1D17E1F@csiadmail01.office.comscore.com> Message-ID: <200401241044.19490.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 10:27, Nielsen, Steve wrote: > The docs on fedoralegacy point to fedora.us as > the mirror to use. Just a little confusing. Do you > know what the timings are for the fedoralegacy mirrors > to be up and running and available? Will ftp, http and > rsync be available ? Unfortunately I do not know how soon mirrors will come online. I had hoped to hear back from my prospective master mirror by now, but it hasn't happened. Yes, http, ftp, and rsync will be available on the master mirror. In the mean time, since only http is available, you can use the lftp command to mirror the content: lftp http://download.fedoralegacy.org/redhat Then give it the "mirror . ." command, which will mirror the current directory tree on the server to your current local directory. lftp is really a wonderful tool (; - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAEr0B4v2HLvE71NURAh/rAKC7ff1Z+H9mroHyBqqEz3GH29LdWACgxsk6 zeWnnRKb7/Zfe3bcmtMUCb4= =0A3u -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Sun Jan 25 02:44:12 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Sat, 24 Jan 2004 20:44:12 -0600 Subject: download.fedoralegacy.org cutover In-Reply-To: <200401231442.13658.jkeating@j2solutions.net> References: <200401221651.41904.jkeating@j2solutions.net> <200401231413.36711.jkeating@j2solutions.net> <20040123164401.lyzoggsw84g4g0oc@mail.ph.utexas.edu> <200401231442.13658.jkeating@j2solutions.net> Message-ID: <20040124204412.gkc8ssgcs4sw4oc8@mail.ph.utexas.edu> Quoting Jesse Keating : > On Friday 23 January 2004 14:44, Eric Rostetter wrote: > > Done. let me know if there are any problems with the changes, > > additions to be made, etc. > > For now lets remove the link to the fedora.us mirror list, as they > aren't a fedoralegacy mirror list. We'll have our own mirror > structure. Done. -- Eric Rostetter From jedgecombe at carolina.rr.com Sun Jan 25 03:42:23 2004 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Sat, 24 Jan 2004 22:42:23 -0500 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200401240121.18041.jkeating@j2solutions.net> References: <200401240121.18041.jkeating@j2solutions.net> Message-ID: <40133B1F.2030503@carolina.rr.com> Should these notifications be sent to security lists such as bugtraq? Jason Edgecombe Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >- --------------------------------------------------------------------- >Fedora Legacy Test Update Notification >FEDORA-2004-1207 >2004-01-24 >- --------------------------------------------------------------------- > >Name : cvs >Version 7.2 : 1.11.1p1-9.7.legacy >Version 7.3 : 1.11.1p1-9.7.legacy >Version 7.2 : 1.11.2-9.legacy >Summary : A version control system. >Description : >CVS (Concurrent Version System) is a version control system that can >record the history of your files (usually, but not always, source >code). CVS only stores the differences between versions, instead of >every version of every file you have ever created. CVS also keeps a log >of who, when, and why changes occurred. > >CVS is very helpful for managing releases and controlling the >concurrent editing of source files among multiple authors. Instead of >providing version control for a collection of files in a single >directory, CVS provides version control for a hierarchical collection >of directories consisting of revision controlled files. These >directories and files can then be combined together to form a software >release. > >- --------------------------------------------------------------------- >Update Information: > >CAN-2003-0977: >CVS server before 1.11.10 may allow attackers to cause the CVS server to >create directories and files in the file system root directory via >malformed module requests. > >2003-12-18: Stable CVS Version 1.11.11 Released! (security update) > >Contributed by: Derek Price > >Stable CVS 1.11.11 has been released. Stable releases contain only bug >fixes from previous versions of CVS. This release adds code to the CVS >server to prevent it from continuing as root after a user login, as an >extra failsafe against a compromise of the CVSROOT/passwd file. >Previously, any user with the ability to write the CVSROOT/passwd file >could execute arbitrary code as the root user on systems with CVS pserver >access enabled. We recommend this upgrade for all CVS servers! > >- --------------------------------------------------------------------- >Changelog: > >* Mon Jan 12 2004 Jason Rohwedder >1.11.1p1-9.7.legacy > >- - applied cvs-1.11.9-absolute-modules.patch >- - to make Seth's previous changelog true :) >- - He actually patched >- - http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 > >* Mon Jan 12 2004 Seth Vidal > >- - apply security patch for CAN-2003-0977 > >* Tue Dec 30 2003 Seth Vidal 1.11.1p1-8.7.duke.1 > >- - apply security patch for: >http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0977 >- - second patch to make the above build > >- --------------------------------------------------------------------- >This update can be downloaded from: > http://download.fedoralegacy.org/redhat/ > >46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad >7.2/updates-testing/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm >469e08276fd61a06f816d4d7df68bc6c85a98560 >7.2/updates-testing/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm > >46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad >7.3/updates-testing/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm >1dfba0ce740a20bd0977eede82f606ea2f907b00 >7.3/updates-testing/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm > >31e98f14255c132d3f548a51096b0c444a45797a >8.0/updates-testing/SRPMS/cvs-1.11.2-9.legacy.src.rpm >e415df08fdfd35216c68651aa5214e7ecdb04268 >8.0/updates-testing/i386/cvs-1.11.2-9.legacy.i386.rpm > >Please note that this update is also available via yum and apt. Many >people find this an easier way to apply updates. To use yum issue: > >yum update > >or to use apt: > >apt-get update; apt-get upgrade > >This will start an interactive process that will result in the appropriate >RPMs being upgraded on your system. This assumes that you have yum or >apt-get configured for obtaining Fedora Legacy content. Please visit >http://www.fedoralegacy.org/download for directions on how to configure >yum and apt-get. >- --------------------------------------------------------------------- > >Please test and comment. > >- -- >Jesse Keating RHCE (http://geek.j2solutions.net) >Fedora Legacy Team (http://www.fedoralegacy.org) >Mondo DevTeam (www.mondorescue.org) >GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) > >Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.3 (GNU/Linux) > >iD8DBQFAEjkN4v2HLvE71NURAiFHAJ91TtcDliZTgLkVp5ZAQcVGJXU54gCfRgsQ >CcxdIc3lZNe4NY7cA/68cYY= >=m7BJ >-----END PGP SIGNATURE----- > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > From jkeating at j2solutions.net Sun Jan 25 04:04:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 24 Jan 2004 20:04:06 -0800 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <40133B1F.2030503@carolina.rr.com> References: <200401240121.18041.jkeating@j2solutions.net> <40133B1F.2030503@carolina.rr.com> Message-ID: <200401242004.07170.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 January 2004 19:42, Jason Edgecombe wrote: > Should these notifications be sent to security lists such as bugtraq? Test releases no. The one official release I put out, elm, I did send off to bugtraq. I'm not subscribed to bugtraq, and I think the queue gods ate my mail. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAE0A24v2HLvE71NURAo4KAJsGwZ1TCc7yWc5vs6l2IwD7mV2YNQCfZ9Bc nakXyjIryIMZQqqYRsr/Vas= =Rhix -----END PGP SIGNATURE----- From wipe_out at users.sourceforge.net Sun Jan 25 09:53:47 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Sun, 25 Jan 2004 09:53:47 +0000 Subject: A new person.. Message-ID: <4013922B.3040701@users.sourceforge.net> Hi All, This looks like an interesting project.. Especially since my web server is still on RH7.2 and I have been dreading trying to upgrade it because it has so much stuff on it.. I installed the YUM RPM from http://download.fedoralegacy.org/redhat/7.2/legacy-utils/i386/yum-1.0.3-5.0.7.x.legacy.noarch.rpm ... Is this correct? I then ran "yum check-update".. It downloaded all the headers but there was nothing to update.. Did I do somthing wrong?? I am sure there have been at least one or two updates that would affect RH7.2 since RH stopped its support.. Or has the legacy project not started yet?? Appologies if my questions have been asked many times before.. Later.. From cra at WPI.EDU Sun Jan 25 15:30:06 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 25 Jan 2004 10:30:06 -0500 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200401242004.07170.jkeating@j2solutions.net> References: <200401240121.18041.jkeating@j2solutions.net> <40133B1F.2030503@carolina.rr.com> <200401242004.07170.jkeating@j2solutions.net> Message-ID: <20040125153006.GE16948@angus.ind.WPI.EDU> On Sat, Jan 24, 2004 at 08:04:06PM -0800, Jesse Keating wrote: > Test releases no. The one official release I put out, elm, I did send off > to bugtraq. I'm not subscribed to bugtraq, and I think the queue gods ate > my mail. I'm subscribed if you would like me to send it. From jkeating at j2solutions.net Sun Jan 25 17:12:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 25 Jan 2004 09:12:06 -0800 Subject: A new person.. In-Reply-To: <4013922B.3040701@users.sourceforge.net> References: <4013922B.3040701@users.sourceforge.net> Message-ID: <200401250912.06591.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 January 2004 01:53, WipeOut wrote: > I installed the YUM RPM from > http://download.fedoralegacy.org/redhat/7.2/legacy-utils/i386/yum-1.0 >.3-5.0.7.x.legacy.noarch.rpm ... Is this correct? yes it is. > I then ran "yum check-update".. It downloaded all the headers but > there was nothing to update.. Did I do somthing wrong?? I am sure > there have been at least one or two updates that would affect RH7.2 > since RH stopped its support.. Or has the legacy project not started > yet?? > > Appologies if my questions have been asked many times before.. We have only fully released one package thus far, elm. There are 4~ packages that are in updates-testing phase right now, that need verification in production environments before I'll fully release them. your yum config file includes support for updates-testing, but it is commented out by default. If you wish to help us verify packages, please uncomment the lines /etc/yum.conf, and report success/failure to our bugzilla system for the packages you test. And welcome! - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAE/jm4v2HLvE71NURAhbtAJ9VQpeLwt5/n1yxhc7riWT23QxZFwCfd4// yDGbiqxzaZfHWF4yASqdREY= =QgQD -----END PGP SIGNATURE----- From jedgecombe at carolina.rr.com Sun Jan 25 17:14:41 2004 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Sun, 25 Jan 2004 12:14:41 -0500 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <200401242004.07170.jkeating@j2solutions.net> References: <200401240121.18041.jkeating@j2solutions.net> <40133B1F.2030503@carolina.rr.com> <200401242004.07170.jkeating@j2solutions.net> Message-ID: <4013F981.4010906@carolina.rr.com> Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Saturday 24 January 2004 19:42, Jason Edgecombe wrote: > > >>Should these notifications be sent to security lists such as bugtraq? >> >> > >Test releases no. The one official release I put out, elm, I did send off >to bugtraq. I'm not subscribed to bugtraq, and I think the queue gods ate >my mail. > > Ah, I didn't notice that is was a test update. Is there an fedora-lagacy-announce list that only has the non-test updates? Maybe we could have anything sent to that list automatically forward to bugtraq. It seems like everything from the redhat-watch-list gets on bugtraq. Either human, or automatic is fine with me. Jason Edgecombe From jkeating at j2solutions.net Sun Jan 25 17:17:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 25 Jan 2004 09:17:59 -0800 Subject: Fedora Legacy Test Update Notification: cvs In-Reply-To: <4013F981.4010906@carolina.rr.com> References: <200401240121.18041.jkeating@j2solutions.net> <200401242004.07170.jkeating@j2solutions.net> <4013F981.4010906@carolina.rr.com> Message-ID: <200401250917.59271.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 January 2004 09:14, Jason Edgecombe wrote: > Is there an fedora-lagacy-announce list that only has the non-test > updates? Maybe we could have anything sent to that list automatically > forward to bugtraq. It seems like everything from the > redhat-watch-list gets on bugtraq. Yes, there is fedora-legacy-announce at redhat.com where I send just package release announcements (which I also send to this list). - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAE/pH4v2HLvE71NURAs6GAKCMd/GW76JUbXSpKF7u8ms/+64TbgCfWziz 5MH1k1QRUBHgsRZDU5DQ6HM= =sI45 -----END PGP SIGNATURE----- From jedgecombe at carolina.rr.com Sun Jan 25 17:22:30 2004 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Sun, 25 Jan 2004 12:22:30 -0500 Subject: Self Introduction Message-ID: <4013FB56.2020803@carolina.rr.com> My name is Jason Edgecombe I work at the University of North Carolina at Charlotte in the USA. My job is web developer. I write server-side scripts (php, java, perl) and co-admin our three departmental linux servers (2 RedHat 7.3 and one RH 9 box) I work for the College of Arts & Sciences within the University. I recently transferred from a different department where I was departmental tech support and admin for multiple linux servers, a 16 node linux beowulf cluster, and a few IRIX boxes for 3 years. From fedora-legacy at share-foo.com Sun Jan 25 19:54:00 2004 From: fedora-legacy at share-foo.com (Ray Ferguson) Date: Sun, 25 Jan 2004 13:54:00 -0600 Subject: Found a bug in redhat-8.0 Python, Fixed (i think). RPMs linked. Message-ID: <200401251354.10071.fedora-legacy@share-foo.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Raymond (Ray) Edward Ferguson 2. US Madison Wisconsin 3. Operations Engineer 4. Berbee Information Networks 5. I probably won't make many contributions (leaning toward progeny). I may change my mind on contributing though if I have spare time since this seems like a good place to get some programming exposure. 6. I've written/maintain a couple of ldap related squirrelmail plugins and a php based subnet calculator in the public domain, but I'm not a (real) programmer. 7. Key fingerprint = 99B5 73CF 0AEA B5DF 3BAE 6E2A 346E 424F 7108 7365 Key ID = 71087365 It sure looks like I found a problem RedHat knew about, fixed in 7.3 then forgot about in 8.0. I don't have an RH9 box to test on, but the problem is fixed in RHES3. urllib2 (part of the python package) does not support non-annymous ftp in RH8. This was fixed in an update released for RH7.3 as per the change log here: http://www2.linuxforum.net/RPM/redhat/updates/7.3/en/os/i386/python2-2.2.2-11.7.3.i386.html However, that fix never made into RH8. As such, specifying a url like this ftp://user:pass at server/path in yum.conf does not work on RH8. I took apart the RH7.3 rpm and grabed the patch to fix nonanonftp, added it to thr RH8 sources, updated the spec file and built the rpms. Yum seems to work peachy w/ nonanonymous ftp now. The related RPMs will are at http://share-foo.com/rpms/ . I've attempted to conform to your packaging guidlines. Let me know if I've made mistakes. - -ray. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFB7dNG5CT3EIc2URAg3qAJ9jZpeiBTBKSLemAlECBg5/vm5tGQCeP0XM qbwuzFGBxEZPVzwQWY1HvPI= =+VTE -----END PGP SIGNATURE----- From drees at greenhydrant.com Sun Jan 25 20:09:27 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 25 Jan 2004 12:09:27 -0800 Subject: Verifying Question... Message-ID: <40142277.4010806@greenhydrant.com> I just wanted to clarify the process of verifying packages after they've gone through the QA process. Is there any steps should a person take to verify a binary package besides the ones mentioned on http://www.fedora.us/wiki/PackageSubmissionQAPolicy? It seems that something more should be done besides download and verify functionality, add clear-signed comment to te bug. Perhaps like checking the size of the files or the file list compared to the packages that were QAd, or something... If the two steps above are OK, I'll get to verifying the packages that are waiting for verification as it seems very easy to do compared to getting a package to the PUBLISH state. -Dave From jkeating at j2solutions.net Sun Jan 25 20:13:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 25 Jan 2004 12:13:46 -0800 Subject: Verifying Question... In-Reply-To: <40142277.4010806@greenhydrant.com> References: <40142277.4010806@greenhydrant.com> Message-ID: <200401251213.48021.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 January 2004 12:09, David Rees wrote: > Is there any steps should a person take to verify a binary package > besides the ones mentioned on > http://www.fedora.us/wiki/PackageSubmissionQAPolicy? It seems that > something more should be done besides download and verify functionality, > add clear-signed comment to te bug. Perhaps like checking the size of > the files or the file list compared to the packages that were QAd, or > something... > > If the two steps above are OK, I'll get to verifying the packages that > are waiting for verification as it seems very easy to do compared to > getting a package to the PUBLISH state. ldd output of the old binary(s) against ldd of the new ones is good. Also, just using it in production for your every day tasks is the big thing. The majority of the scruitiny goes into the package to get to the PUBLISH state. The VERIFY state is a final passing test before we push it fully public. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFCN64v2HLvE71NURAvVPAKC3gJAkXRL1ubD8uhHHe0gZiZ/pegCfb9bj snNib3aodBybJEd6KaI3uC4= =fhlY -----END PGP SIGNATURE----- From drees at greenhydrant.com Sun Jan 25 20:23:24 2004 From: drees at greenhydrant.com (David Rees) Date: Sun, 25 Jan 2004 12:23:24 -0800 Subject: Verifying Question... In-Reply-To: <200401251213.48021.jkeating@j2solutions.net> References: <40142277.4010806@greenhydrant.com> <200401251213.48021.jkeating@j2solutions.net> Message-ID: <401425BC.1010601@greenhydrant.com> Jesse Keating wrote, On 1/25/2004 12:13 PM: > > ldd output of the old binary(s) against ldd of the new ones is good. > > Also, just using it in production for your every day tasks is the big > thing. The majority of the scruitiny goes into the package to get to the > PUBLISH state. The VERIFY state is a final passing test before we push it > fully public. Thanks Jesse, I'll get to verifying some packages, then. -Dave From ms-nospam-0306 at arcor.de Sun Jan 25 22:30:41 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 25 Jan 2004 23:30:41 +0100 Subject: rh80 builds not stripped Message-ID: <20040125233041.05e27691.ms-nospam-0306@arcor.de> Not sure whether the attached patch has been applied to the rh80 build system of fedora.us (haven't payed attention to the size of the rh80 builds), but in case anyone runs into huge unstripped library builds on rh80, attached patch is one way to fix that. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-rpm-config.rh80.patch Type: application/octet-stream Size: 2692 bytes Desc: not available URL: From peter.abraham at dynamicnet.net Sun Jan 25 22:35:25 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Sun, 25 Jan 2004 17:35:25 -0500 Subject: Will the files for legacy RedHat 7.3 be back on line? In-Reply-To: <200401241044.19490.jkeating@j2solutions.net> References: <66E9FEE99E96034ABB4DE197A927DBF1D17E1F@csiadmail01.office.comscore.com> <200401241044.19490.jkeating@j2solutions.net> Message-ID: <6.0.1.1.2.20040125173422.01c3af60@mail.dynamicnet.net> Greetings: http://download.fedora.us/fedora/redhat/ show RedHat 8 and 9. RedHat 7.3, which was present in the recent past, is now gone. Will RedHat 7.3 be put back on-line? If so, when? Thank you! From skvidal at phy.duke.edu Sun Jan 25 22:45:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 25 Jan 2004 17:45:36 -0500 Subject: Will the files for legacy RedHat 7.3 be back on line? In-Reply-To: <6.0.1.1.2.20040125173422.01c3af60@mail.dynamicnet.net> References: <66E9FEE99E96034ABB4DE197A927DBF1D17E1F@csiadmail01.office.comscore.com> <200401241044.19490.jkeating@j2solutions.net> <6.0.1.1.2.20040125173422.01c3af60@mail.dynamicnet.net> Message-ID: <1075070736.8079.45.camel@binkley> On Sun, 2004-01-25 at 17:35, Peter M. Abraham wrote: > Greetings: > > http://download.fedora.us/fedora/redhat/ show RedHat 8 and 9. > > RedHat 7.3, which was present in the recent past, is now gone. > > Will RedHat 7.3 be put back on-line? If so, when? > > Thank you! go to download.fedoralegacy.org -sv From jensknutson at yahoo.com Mon Jan 26 01:07:21 2004 From: jensknutson at yahoo.com (Jens Knutson) Date: Sun, 25 Jan 2004 19:07:21 -0600 Subject: A couple quick kernel questions... Message-ID: <1075079241.1492.404.camel@localhost.localdomain> Just 2 quick kernel questions: (I promise, I searched the archives already! :-) 1) The kernel documentation for CONFIG_SCSI_MULTI_LUN says that "The vast majority of SCSI devices have only one LUN, and so most people can say N here and should in fact do so, because it is safer." Well, I've discovered that my "6-in-1" CF/MMC/etc card reader, and all others like it, require CONFIG_SCSI_MULTI_LUN to be set to Y to work properly. What is it about the option that makes it "unsafe", and will this go away in the near future? (crosses fingers...) 2) I've been using the Rawhide 2.6 kernels for a couple weeks, and I love them! One thing I found that made a big interactivity difference was the CFQ I/O scheduler from Andrew Morton's -mm patch set. Since this is selectable at boot, is it possible that we'll see CFQ in Fedora Core 2 test kernels? Patching each new release sucks. ;-) Thanks! - jck -- "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about." -- Albert Einstein From whooperhsd3 at earthlink.net Mon Jan 26 02:12:09 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Sun, 25 Jan 2004 21:12:09 -0500 (EST) Subject: A couple quick kernel questions... In-Reply-To: <1075079241.1492.404.camel@localhost.localdomain> References: <1075079241.1492.404.camel@localhost.localdomain> Message-ID: <64757.65.40.134.77.1075083129.squirrel@65.40.134.77> Jens Knutson said: > Just 2 quick kernel questions: (I promise, I searched the archives > already! :-) I don't think you have. Neither of these questions have anything to do with Fedora-Legacy. I suggest trying your questions in fedora-devel. -- William Hooper From fedora-legacy at share-foo.com Mon Jan 26 03:52:26 2004 From: fedora-legacy at share-foo.com (Ray Ferguson) Date: Sun, 25 Jan 2004 21:52:26 -0600 Subject: Found a bug in redhat-8.0 Python, Fixed (i think). RPMs linked. In-Reply-To: <200401251354.10071.fedora-legacy@share-foo.com> References: <200401251354.10071.fedora-legacy@share-foo.com> Message-ID: <200401252152.34014.fedora-legacy@share-foo.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not sure what the policy is on this, but it looks like the only RPM that needs an update to fix this is the main python rpm. However, the srpm makes a bunch of rpms. - -ray. On Sunday 25 January 2004 1:54 pm, Ray Ferguson wrote: > 1. Raymond (Ray) Edward Ferguson > 2. US Madison Wisconsin > 3. Operations Engineer > 4. Berbee Information Networks > 5. I probably won't make many contributions (leaning toward progeny). I > may change my mind on contributing though if I have spare time since this > seems like a good place to get some programming exposure. > 6. I've written/maintain a couple of ldap related squirrelmail plugins and > a php based subnet calculator in the public domain, but I'm not a (real) > programmer. > 7. Key fingerprint = 99B5 73CF 0AEA B5DF 3BAE 6E2A 346E 424F 7108 7365 > Key ID = 71087365 > > > It sure looks like I found a problem RedHat knew about, fixed in 7.3 then > forgot about in 8.0. I don't have an RH9 box to test on, but the problem > is fixed in RHES3. > > urllib2 (part of the python package) does not support non-annymous ftp in > RH8. This was fixed in an update released for RH7.3 as per the change log > here: > > > http://www2.linuxforum.net/RPM/redhat/updates/7.3/en/os/i386/python2-2.2.2- >11.7.3.i386.html > > However, that fix never made into RH8. As such, specifying a url like > this > > ftp://user:pass at server/path > > in yum.conf does not work on RH8. > > I took apart the RH7.3 rpm and grabed the patch to fix nonanonftp, added > it to thr RH8 sources, updated the spec file and built the rpms. Yum seems > to work peachy w/ nonanonymous ftp now. > > The related RPMs will are at http://share-foo.com/rpms/ . I've attempted > to conform to your packaging guidlines. Let me know if I've made mistakes. > > -ray. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFI7/NG5CT3EIc2URAvi3AKCPToFAhgI6PsyRUdkK7VSr0kCKnACgghGP 890F7CIqwUPoQvpFrbkoAK0= =4mT9 -----END PGP SIGNATURE----- From brian.t.brunner at gai-tronics.com Mon Jan 26 14:25:32 2004 From: brian.t.brunner at gai-tronics.com (Brian T. Brunner) Date: Mon, 26 Jan 2004 09:25:32 -0500 Subject: State of Fedora Legacy Message-ID: In behalf of the silent watchers, Meee 4. I don't know if we'll ever shift from 9 to Fedora, but knowing you guys are there keeps alive the hope that RH9 has a successor worthy of the name. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 >>> chuckw at quantumlinux.com 01/24/04 01:11AM >>> On Fri, 23 Jan 2004, Matthew Miller wrote: > On Fri, Jan 23, 2004 at 03:49:01PM -0800, Paul Heinlein wrote: > > > First off, Thank you EVER so much for all the support you've given > > > this project, > > Thank YOU, Jesse. Your work is much appreciated. > > Yeah, I'm going to have to me-too this. Thanks! Heh, yeah me 3. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated ********************************************************************** From Freedom_Lover at pobox.com Mon Jan 26 17:50:37 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 26 Jan 2004 12:50:37 -0500 Subject: libstdc++3-devel-3.0.4-1.i386.rpm in 7.2 updates doesn't verify Message-ID: <20040126175037.GC21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was setting up a 7.2 playground in VMware so I could try to QA and verify packages for both 7.2 and 7.3 (and 8.0 once yum gets rebuilt for it, but that's another thread to start). While running yum update after the install, I found a problem with one of the files in the download.fedoralegacy.org archive. # yum update [...] Getting libstdc++3-devel-3.0.4-1.i386.rpm Error: MD5 Signature check failed for /var/cache/yum/updates/packages/libstdc++3-devel-3.0.4-1.i386.rpm You may want to run yum clean or remove the file: /var/cache/yum/updates/packages/libstdc++3-devel-3.0.4-1.i386.rpm Exiting. Downloading the file manually I still can't get it to verify: # rpm -Kv libstdc++3-devel-3.0.4-1.i386.rpm libstdc++3-devel-3.0.4-1.i386.rpm: MD5 sum mismatch Expected: 11dd881955f196fc7159415f49399a31 Saw : b136a51a08ac3d96ddf145bd14b9086e gpg: Signature made Sun 10 Mar 2002 10:37:55 PM EST using DSA key ID DB42A60E gpg: BAD signature from "Red Hat, Inc " I pulled down the all the binary updates for 7.2 and verified them. The only one that has a problem is libstdc++3-devel-3.0.4-1.i386.rpm. Can anyone confirm this? If it is corrupted, it'd be good to get the right file in place before mirrors start syncing against the download server. It might even be good to check out the bad package more closely to see if it was an intentional corruption. At least one other mirror has the corrupt rpm (speakeasy.rpmfind.net). I imagine there are others. I got a good version from: ftp://rpmfind.net/linux/redhat/updates/7.2/en/os/i386 - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== It is hard to fight an enemy who has outposts in your head. -- Sally Kempton -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAFVNtuv+09NZUB1oRAnijAKCiIu8EeOxizKthm6veMxrrdjFpTQCgmc5w MyP57lQRhw185kWFr3m4YJs= =85Nt -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 26 18:01:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jan 2004 10:01:24 -0800 Subject: libstdc++3-devel-3.0.4-1.i386.rpm in 7.2 updates doesn't verify In-Reply-To: <20040126175037.GC21263@psilocybe.teonanacatl.org> References: <20040126175037.GC21263@psilocybe.teonanacatl.org> Message-ID: <200401261001.28454.jkeating@j2solutions.net> On Monday 26 January 2004 09:50, Todd wrote: > I pulled down the all the binary updates for 7.2 and verified them. > The only one that has a problem is libstdc++3-devel-3.0.4-1.i386.rpm. > Can anyone confirm this? Thank you for checking. I did check that file on the server, and it was infact corrupted. > If it is corrupted, it'd be good to get the right file in place > before mirrors start syncing against the download server. It might > even be good to check out the bad package more closely to see if it > was an intentional corruption. I have replaced the file with one directly from updates.redhat.com and it does check out. yum headers and apt metadata have been re-generated. > At least one other mirror has the corrupt rpm > (speakeasy.rpmfind.net). I imagine there are others. I got a good > version from: > > ftp://rpmfind.net/linux/redhat/updates/7.2/en/os/i386 I originally pulled some of these updates from http://www.rpmfind.net so it's possible that this is where it came from. updates.redhat.com was not responding at the time. once again, thank you for finding this issue! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Freedom_Lover at pobox.com Mon Jan 26 18:26:06 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 26 Jan 2004 13:26:06 -0500 Subject: libstdc++3-devel-3.0.4-1.i386.rpm in 7.2 updates doesn't verify In-Reply-To: <200401261001.28454.jkeating@j2solutions.net> References: <20040126175037.GC21263@psilocybe.teonanacatl.org> <200401261001.28454.jkeating@j2solutions.net> Message-ID: <20040126182606.GD21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > I have replaced the file with one directly from updates.redhat.com > and it does check out. yum headers and apt metadata have been > re-generated. Damn, that's quick Jesse! You must never sleep. :) > I originally pulled some of these updates from > http://www.rpmfind.net so it's possible that this is where it came > from. updates.redhat.com was not responding at the time. Yeah, they were too busy for me to connect to as I was drafting the email earlier. > once again, thank you for finding this issue! No problem. I hope to get these test VM's going and be able to do some timely testing. We'll see how that goes. Thanks for your efforts and the quick turn around time! - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs. -- P.J. O'Rourke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAFVu+uv+09NZUB1oRArVjAKDyqPsT/dePK0ZnRF3cc+VAKIk/wQCfblMa Kfh1g7IV1bsbWooeFq5TAwI= =TUCU -----END PGP SIGNATURE----- From Freedom_Lover at pobox.com Mon Jan 26 18:46:09 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 26 Jan 2004 13:46:09 -0500 Subject: yum and rpm updates for 8.0 Message-ID: <20040126184609.GE21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm setting up some virtual machines to do testing. I'm curious what has to happen to get yum and the rpm updates from fedora.us into the legacy-utils channel on fedoralegacy.org. I didn't notice any bugzilla entries for this. If there's something I can do to help out there, point me in the right direction. If I could check a package against 7.2, 7.3, and 8.0 all at the same time, I think it'd be easier for me. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The only reason we still have elections in this country is to see if the pollsters were right. -- Ed Rollins -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAFWBxuv+09NZUB1oRAnwRAJ4iAKi6VqZwvIsOJF2yxgaVH8mimwCg6Vwk 0TItgUgIw0403Z5scdHkJr4= =argS -----END PGP SIGNATURE----- From jkeating at j2solutions.net Mon Jan 26 18:45:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jan 2004 10:45:32 -0800 Subject: libstdc++3-devel-3.0.4-1.i386.rpm in 7.2 updates doesn't verify In-Reply-To: <20040126182606.GD21263@psilocybe.teonanacatl.org> References: <20040126175037.GC21263@psilocybe.teonanacatl.org> <200401261001.28454.jkeating@j2solutions.net> <20040126182606.GD21263@psilocybe.teonanacatl.org> Message-ID: <200401261045.36425.jkeating@j2solutions.net> On Monday 26 January 2004 10:26, Todd wrote: > Damn, that's quick Jesse! You must never sleep. :) No, I sleep, but I'm on PST time, so my waking patterns may look strange to a lot of folk. (Sleep occurs sometime between 1:00am PST and 7:30am PST). > > I originally pulled some of these updates from > > http://www.rpmfind.net so it's possible that this is where it came > > from. updates.redhat.com was not responding at the time. > > Yeah, they were too busy for me to connect to as I was drafting the > email earlier. > > > once again, thank you for finding this issue! > > No problem. I hope to get these test VM's going and be able to do > some timely testing. We'll see how that goes. > > Thanks for your efforts and the quick turn around time! Not a problem! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Mon Jan 26 18:48:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jan 2004 10:48:13 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040126184609.GE21263@psilocybe.teonanacatl.org> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> Message-ID: <200401261048.13461.jkeating@j2solutions.net> On Monday 26 January 2004 10:46, Todd wrote: > I'm setting up some virtual machines to do testing. I'm curious what > has to happen to get yum and the rpm updates from fedora.us into the > legacy-utils channel on fedoralegacy.org. I didn't notice any > bugzilla entries for this. If there's something I can do to help out > there, point me in the right direction. If I could check a package > against 7.2, 7.3, and 8.0 all at the same time, I think it'd be > easier for me. 8.0's yum hasn't been rebuilt yet. The old 8.0 yum pointed to fedora.us, and this isn't exactly valid anymore. Once it gets rebuilt with the Legacy key and the proper config directory, it'll be placed in download.fedoralegacy.org. This should happen tonight. As to the rpm update, that is still in bugzilla I think, as it caused breakage on a few other packages (I thought). I'm still not willing to make that an update, more of just a util. fedora.us has http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.legacy/ some content in there still though. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Freedom_Lover at pobox.com Mon Jan 26 19:23:54 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 26 Jan 2004 14:23:54 -0500 Subject: yum and rpm updates for 8.0 In-Reply-To: <200401261048.13461.jkeating@j2solutions.net> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261048.13461.jkeating@j2solutions.net> Message-ID: <20040126192354.GF21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > 8.0's yum hasn't been rebuilt yet. The old 8.0 yum pointed to > fedora.us, and this isn't exactly valid anymore. Once it gets > rebuilt with the Legacy key and the proper config directory, it'll > be placed in download.fedoralegacy.org. This should happen tonight. Cool. > As to the rpm update, that is still in bugzilla I think, as it > caused breakage on a few other packages (I thought). Is that in the general fedora.us bugzilla? I didn't see anything about it at https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY and a quick query of the full buglist didn't spit out anything obvious about rpm-4.1.1. > I'm still not willing to make that an update, more of just a util. Isn't rpm>= 4.1.1 required for yum 2? Or is legacy going to use yum 1.0.3 like 7x does? The fedora.us packages are of yum-2.0.3, so I just assumed that was what you'd be rebuilding. > fedora.us has > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.legacy/ > > some content in there still though. Yeah, I've seen those. I was looking to do a clean 8.0 install and only use legacy packages to test with. I'll wait to see when yum gets built and posted and check it out then. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== I got stopped by a cop the other day. He said, "Why'd you run that stop sign?" I said, "Because I don't believe everything I read." -- Stephen Wright -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAFWlKuv+09NZUB1oRAhBrAKDnvKgy1b5AKQpdAgSE+S5/O1AnzgCgruzx kxPD3rMuBWaHpqCVBmaOqC4= =SBLR -----END PGP SIGNATURE----- From heinlein at cse.ogi.edu Mon Jan 26 19:29:05 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Mon, 26 Jan 2004 11:29:05 -0800 (PST) Subject: yum and rpm updates for 8.0 In-Reply-To: <20040126192354.GF21263@psilocybe.teonanacatl.org> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261048.13461.jkeating@j2solutions.net> <20040126192354.GF21263@psilocybe.teonanacatl.org> Message-ID: On Mon, 26 Jan 2004, Todd wrote: > Isn't rpm>= 4.1.1 required for yum 2? Or is legacy going to use yum > 1.0.3 like 7x does? The fedora.us packages are of yum-2.0.3, so I > just assumed that was what you'd be rebuilding. At the yum home page, Seth still has 1.0.3 listed as the official release for Red Hat 8.0 -- so that's what I've been using. --Paul Heinlein From jkeating at j2solutions.net Mon Jan 26 19:28:46 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jan 2004 11:28:46 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040126192354.GF21263@psilocybe.teonanacatl.org> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261048.13461.jkeating@j2solutions.net> <20040126192354.GF21263@psilocybe.teonanacatl.org> Message-ID: <200401261128.50714.jkeating@j2solutions.net> On Monday 26 January 2004 11:23, Todd wrote: > Is that in the general fedora.us bugzilla? I didn't see anything > about it at https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY > and a quick query of the full buglist didn't spit out anything > obvious about rpm-4.1.1. I'm not sure exactly where it's at. This issue probably needs to be re-addressed, or just pointed over at rpm.org for information. Legacy doesn't directly support it, and won't build our packages against it to maintain as close to RH as possible. > > I'm still not willing to make that an update, more of just a util. > > Isn't rpm>= 4.1.1 required for yum 2? Or is legacy going to use yum > 1.0.3 like 7x does? The fedora.us packages are of yum-2.0.3, so I > just assumed that was what you'd be rebuilding. We'll be using yum1, which works against a stock RHL8. > Yeah, I've seen those. I was looking to do a clean 8.0 install and > only use legacy packages to test with. I'll wait to see when yum > gets built and posted and check it out then. k, should be tonight. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Jan 27 05:09:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 26 Jan 2004 21:09:10 -0800 Subject: [FLSA-2004:1187] Updated screen resolves security vulnerability Message-ID: <200401262109.10183.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated screen resolves security vulnerability Advisory ID: FLSA:1187 Issue date: 2004-01-26 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1187 CVE Names: CAN-2003-0972 - ----------------------------------------------------------------------- 1. Topic: Updated screen packages are now available that fix a security vulnerability which may allow privilege escalation for local users, and possibly remote attacks or getting control of another user's screen. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: The screen utility allows you to have multiple logins on just one terminal. Screen is useful for users who telnet into a machine or are connected via a dumb terminal, but want to use more than just one login. Timo Sirainen has reported an integer signedness error in ansi.c for GNU screen 4.0.1 and earlier, and 3.9.15 and earlier, which allows local users to execute arbitrary code via a large number of ";" (semicolon) characters in escape sequences, which leads to a buffer overflow. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0966 to this issue. Users of screen should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Timo Sirainen for discovering and disclosing this issue, and Jason Rohwedder and Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. All users are advised to upgrade to these update packages, which contain a backported security patch that 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/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1187 - screen security patch in rh7x, rh8 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/screen-3.9.9-4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/screen-3.9.9-4.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/screen-3.9.11-4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/screen-3.9.11-4.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/screen-3.9.11-11.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/screen-3.9.11-11.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 194fbeb6e1871aad733966eb03525ee3fa6b736e 7.2/updates/SRPMS/screen-3.9.9-4.legacy.src.rpm 38752ec03ec07ab125ab495910861d0317dfe095 7.2/updates/i386/screen-3.9.9-4.legacy.i386.rpm e22108165eeb8a4f2d6f078600117d2a3b5dc88d 7.3/updates/SRPMS/screen-3.9.11-4.legacy.src.rpm 278a76f5b56d32bc983ab5dc388397c98dffe31c 7.3/updates/i386/screen-3.9.11-4.legacy.i386.rpm 578b3166a0f647ac2a798ad81bdea43c9fe55c7b 8.0/updates/SRPMS/screen-3.9.11-11.legacy.src.rpm c1422da61421e74a5a66e5404f1fcd33134c07e8 8.0/updates/i386/screen-3.9.11-11.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0972 http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 https://bugzilla.fedora.us/show_bug.cgi?id=1187 9. Contact: The Fedora Legacy security contact is . More project details at https://www.fedoralegacy.org - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAFfJ24v2HLvE71NURAonTAKCW99PZaO+Pqgw/Wyz79XcvoDwUtQCePW59 bm7VDH125SXLZ3FwJR0mZvI= =zOd3 -----END PGP SIGNATURE----- From jonny.strom at netikka.fi Tue Jan 27 09:13:29 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Tue, 27 Jan 2004 11:13:29 +0200 Subject: Gaim. Message-ID: <40162BB9.6040601@netikka.fi> Hi Since there was no less than 12 security problems with Gaim, I taught I would send out this mail so that ppl can comment on the bug repport in bugzilla. http://bugzilla.fedora.us/show_bug.cgi?id=1237 Thanks Johnny From jjasen at realityfailure.org Tue Jan 27 17:12:32 2004 From: jjasen at realityfailure.org (John Jasen) Date: Tue, 27 Jan 2004 12:12:32 -0500 (EST) Subject: apache httpd and slocate In-Reply-To: <40162BB9.6040601@netikka.fi> References: <40162BB9.6040601@netikka.fi> Message-ID: slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html Looks liked 7.x and above might be affected? httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html Looks like 8 and above? -- -- John E. Jasen (jjasen at realityfailure.org) -- User Error #2361: Please insert coffee and try again. From skvidal at phy.duke.edu Tue Jan 27 17:19:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 27 Jan 2004 12:19:42 -0500 Subject: apache httpd and slocate In-Reply-To: References: <40162BB9.6040601@netikka.fi> Message-ID: <1075223981.8079.85.camel@binkley> On Tue, 2004-01-27 at 12:12, John Jasen wrote: > slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html > > Looks liked 7.x and above might be affected? isn't this already in updates-testing iirc. > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > Looks like 8 and above? not sure on this one. -sv From jkeating at j2solutions.net Tue Jan 27 17:27:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 27 Jan 2004 09:27:37 -0800 Subject: apache httpd and slocate In-Reply-To: <1075223981.8079.85.camel@binkley> References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> Message-ID: <200401270927.37591.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 27 January 2004 09:19, seth vidal wrote: > > slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html > > > > Looks liked 7.x and above might be affected? > > isn't this already in updates-testing iirc. Not yet. We need consensus to upgrade slocate to 2.7. Thats the route that RHEL 2.1 took, and with encourging words from Notting, I'm confident that it'll be smooth for fl as well. If we concur, I'll QA and put in updates-testing > > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > > > Looks like 8 and above? > > not sure on this one. Neither am I. I'll try to research it today. - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAFp+J4v2HLvE71NURAlNHAJ4zAWphBOG7Vaby6z+igyl34TgD+QCeOQnl vI/nLcPq0IPZbJAD+QKFxG4= =xCVW -----END PGP SIGNATURE----- From wipe_out at users.sourceforge.net Tue Jan 27 17:31:40 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Tue, 27 Jan 2004 17:31:40 +0000 Subject: apache httpd and slocate In-Reply-To: <200401270927.37591.jkeating@j2solutions.net> References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> <200401270927.37591.jkeating@j2solutions.net> Message-ID: <4016A07C.108@users.sourceforge.net> Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Tuesday 27 January 2004 09:19, seth vidal wrote: > > >>>slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html >>> >>>Looks liked 7.x and above might be affected? >>> >>> >>isn't this already in updates-testing iirc. >> >> > >Not yet. We need consensus to upgrade slocate to 2.7. Thats the route >that RHEL 2.1 took, and with encourging words from Notting, I'm >confident that it'll be smooth for fl as well. If we concur, I'll QA >and put in updates-testing > I think FC1 has also moved to 2.7 so it looks like its the way to go. :) Later.. From jkeating at j2solutions.net Tue Jan 27 17:36:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 27 Jan 2004 09:36:50 -0800 Subject: apache httpd and slocate In-Reply-To: <200401270927.37591.jkeating@j2solutions.net> References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> <200401270927.37591.jkeating@j2solutions.net> Message-ID: <200401270936.50362.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 27 January 2004 09:27, Jesse Keating wrote: > > > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > > > > > Looks like 8 and above? > > > > not sure on this one. > > Neither am I. I'll try to research it today. Uh, the link you posted shows an update for RHL 8.0.... Not sure what you're looking for from us, this update is already published and out there. - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAFqGy4v2HLvE71NURAvWRAJ9uU1tyAOElU/QfTaFty0N9HeCBawCfSZEV +kv1iAPOcab4L7OzC9tviK4= =K1Nu -----END PGP SIGNATURE----- From jjasen at realityfailure.org Tue Jan 27 17:41:27 2004 From: jjasen at realityfailure.org (John Jasen) Date: Tue, 27 Jan 2004 12:41:27 -0500 (EST) Subject: apache httpd and slocate In-Reply-To: <200401270936.50362.jkeating@j2solutions.net> References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> <200401270927.37591.jkeating@j2solutions.net> <200401270936.50362.jkeating@j2solutions.net> Message-ID: On Tue, 27 Jan 2004, Jesse Keating wrote: > > Neither am I. I'll try to research it today. > > Uh, the link you posted shows an update for RHL 8.0.... Not sure what > you're looking for from us, this update is already published and out > there. Guilty of reading too fast and not thoroughly enough? Sorry 'bout that. -- -- John E. Jasen (jjasen at realityfailure.org) -- User Error #2361: Please insert coffee and try again. From jbs at quiotix.com Tue Jan 27 19:10:55 2004 From: jbs at quiotix.com (Jeffrey Siegal) Date: Tue, 27 Jan 2004 11:10:55 -0800 Subject: Request for fedora-legacy-announce Message-ID: <4016B7BF.2020200@quiotix.com> Sorry if this has been discussed before, butI'd really like to subscribe to a list where I just get announcements of package updates (and other major project announcements) rather than the full discussion. Any possibility? From ms-nospam-0306 at arcor.de Tue Jan 27 19:14:11 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 27 Jan 2004 20:14:11 +0100 Subject: apache httpd and slocate In-Reply-To: <200401270927.37591.jkeating@j2solutions.net> References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> <200401270927.37591.jkeating@j2solutions.net> Message-ID: <20040127201411.563fa191.ms-nospam-0306@arcor.de> On Tue, 27 Jan 2004 09:27:37 -0800, Jesse Keating wrote: > On Tuesday 27 January 2004 09:19, seth vidal wrote: > > > slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html > > > > > > Looks liked 7.x and above might be affected? > > > > isn't this already in updates-testing iirc. > > Not yet. We need consensus to upgrade slocate to 2.7. Thats the route > that RHEL 2.1 took, and with encourging words from Notting, I'm > confident that it'll be smooth for fl as well. If we concur, I'll QA > and put in updates-testing Note that slocate 2.7 is a bug-fix release only and that 98% of the ~220 KB sized diff against slocate 2.6 consist of autofoo updates and manual page modifications. -- From kelson at speed.net Tue Jan 27 19:19:42 2004 From: kelson at speed.net (Kelson Vibber) Date: Tue, 27 Jan 2004 11:19:42 -0800 Subject: Request for fedora-legacy-announce In-Reply-To: <4016B7BF.2020200@quiotix.com> References: <4016B7BF.2020200@quiotix.com> Message-ID: <6.0.1.1.0.20040127111924.03e77e68@mail.speed.net> At 11:10 AM 1/27/2004, Jeffrey Siegal wrote: >Sorry if this has been discussed before, butI'd really like to subscribe >to a list where I just get announcements of package updates (and other >major project announcements) rather than the full discussion. It already exists: http://www.redhat.com/mailman/listinfo/fedora-legacy-announce Kelson Vibber SpeedGate Communications From jkeating at j2solutions.net Tue Jan 27 19:08:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 27 Jan 2004 11:08:07 -0800 Subject: Request for fedora-legacy-announce In-Reply-To: <4016B7BF.2020200@quiotix.com> References: <4016B7BF.2020200@quiotix.com> Message-ID: <200401271108.07119.jkeating@j2solutions.net> On Tuesday 27 January 2004 11:10, Jeffrey Siegal wrote: > Sorry if this has been discussed before, butI'd really like to > subscribe to a list where I just get announcements of package updates > (and other major project announcements) rather than the full > discussion. > > Any possibility? http://www.redhat.com/mailman/listinfo/fedora-legacy-announce -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Tue Jan 27 19:21:05 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 27 Jan 2004 12:21:05 -0700 Subject: apache httpd and slocate In-Reply-To: <1075223981.8079.85.camel@binkley>; from skvidal@phy.duke.edu on Tue, Jan 27, 2004 at 12:19:42PM -0500 References: <40162BB9.6040601@netikka.fi> <1075223981.8079.85.camel@binkley> Message-ID: <20040127122105.A13574@mail.harddata.com> On Tue, Jan 27, 2004 at 12:19:42PM -0500, seth vidal wrote: > On Tue, 2004-01-27 at 12:12, John Jasen wrote: > > > > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > > > Looks like 8 and above? > > not sure on this one. Well, it does not show up in errata for RHEL as far as I can see. :-) M. From jbs at quiotix.com Tue Jan 27 19:22:23 2004 From: jbs at quiotix.com (Jeffrey Siegal) Date: Tue, 27 Jan 2004 11:22:23 -0800 Subject: Request for fedora-legacy-announce In-Reply-To: <6.0.1.1.0.20040127111924.03e77e68@mail.speed.net> References: <4016B7BF.2020200@quiotix.com> <6.0.1.1.0.20040127111924.03e77e68@mail.speed.net> Message-ID: <4016BA6F.3020406@quiotix.com> Kelson Vibber wrote: > At 11:10 AM 1/27/2004, Jeffrey Siegal wrote: > >> Sorry if this has been discussed before, butI'd really like to >> subscribe to a list where I just get announcements of package updates >> (and other major project announcements) rather than the full discussion. > > > It already exists: > http://www.redhat.com/mailman/listinfo/fedora-legacy-announce Well, uh, okay. Looked for it but I must be blind. Sorry for that. From rostetter at mail.utexas.edu Tue Jan 27 19:26:03 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 27 Jan 2004 13:26:03 -0600 Subject: Request for fedora-legacy-announce In-Reply-To: <4016B7BF.2020200@quiotix.com> References: <4016B7BF.2020200@quiotix.com> Message-ID: <20040127132603.zy88cs8wwsgwgck4@mail.ph.utexas.edu> Quoting Jeffrey Siegal : > Sorry if this has been discussed before, butI'd really like to subscribe > to a list where I just get announcements of package updates (and other > major project announcements) rather than the full discussion. > > Any possibility? Yes. Go to http://www.fedoralegacy.org/mail/ and use the link there to subscribe to Fedora-Legacy-Announce -- Eric Rostetter From jedgecombe at carolina.rr.com Wed Jan 28 02:41:24 2004 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Tue, 27 Jan 2004 21:41:24 -0500 Subject: [FLSA-2004:1187] Updated screen resolves security vulnerability In-Reply-To: <200401262109.10183.jkeating@j2solutions.net> References: <200401262109.10183.jkeating@j2solutions.net> Message-ID: <40172154.1060309@carolina.rr.com> FYI, I did get this advisory via bugtraq. Jason Edgecombe Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >- ----------------------------------------------------------------------- > Fedora Legacy Update Advisory > >Synopsis: Updated screen resolves security vulnerability >Advisory ID: FLSA:1187 >Issue date: 2004-01-26 >Product: Red Hat Linux >Keywords: Security >Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1187 >CVE Names: CAN-2003-0972 >- ----------------------------------------------------------------------- > >1. Topic: > >Updated screen packages are now available that fix a security >vulnerability which may allow privilege escalation for local users, and >possibly remote attacks or getting control of another user's screen. > >2. Relevant releases/architectures: > >Red Hat Linux 7.2 - i386 >Red Hat Linux 7.3 - i386 >Red Hat Linux 8.0 - i386 > >3. Problem description: > >The screen utility allows you to have multiple logins on just one >terminal. Screen is useful for users who telnet into a machine or are >connected via a dumb terminal, but want to use more than just one >login. > >Timo Sirainen has reported an integer signedness error in ansi.c for GNU >screen 4.0.1 and earlier, and 3.9.15 and earlier, which allows local >users to execute arbitrary code via a large number of ";" (semicolon) >characters in escape sequences, which leads to a buffer overflow. The >Common Vulnerabilities and Exposures project (cve.mitre.org) has >assigned the name CAN-2003-0966 to this issue. > >Users of screen should update to these update packages, which contain a >backported security patch that corrects this issue. > >Fedora Legacy would like to thank Timo Sirainen for discovering and >disclosing this issue, and Jason Rohwedder and Christian Pearce for >providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. > >All users are advised to upgrade to these update packages, which contain >a backported security patch that 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/download for directions on how >to configure yum and apt-get. > >5. Bug IDs fixed: > >http://bugzilla.fedora.us - 1187 - screen security patch in rh7x, rh8 > >6. RPMs required: > >Red Hat Linux 7.2: > >SRPMS: >http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/screen-3.9.9-4.legacy.src.rpm >i386: >http://download.fedoralegacy.org/redhat/7.2/updates/i386/screen-3.9.9-4.legacy.i386.rpm > >Red Hat Linux 7.3: > >SRPMS: >http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/screen-3.9.11-4.legacy.src.rpm >i386: >http://download.fedoralegacy.org/redhat/7.3/updates/i386/screen-3.9.11-4.legacy.i386.rpm > >Red Hat Linux 8.0: > >SRPMS: >http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/screen-3.9.11-11.legacy.src.rpm >i386: >http://download.fedoralegacy.org/redhat/8.0/updates/i386/screen-3.9.11-11.legacy.i386.rpm > >7. Verification: > >SHA1 sum Package Name >- --------------------------------------------------------------------------- >194fbeb6e1871aad733966eb03525ee3fa6b736e >7.2/updates/SRPMS/screen-3.9.9-4.legacy.src.rpm >38752ec03ec07ab125ab495910861d0317dfe095 >7.2/updates/i386/screen-3.9.9-4.legacy.i386.rpm > >e22108165eeb8a4f2d6f078600117d2a3b5dc88d >7.3/updates/SRPMS/screen-3.9.11-4.legacy.src.rpm >278a76f5b56d32bc983ab5dc388397c98dffe31c >7.3/updates/i386/screen-3.9.11-4.legacy.i386.rpm > >578b3166a0f647ac2a798ad81bdea43c9fe55c7b >8.0/updates/SRPMS/screen-3.9.11-11.legacy.src.rpm >c1422da61421e74a5a66e5404f1fcd33134c07e8 >8.0/updates/i386/screen-3.9.11-11.legacy.i386.rpm > >These packages are GPG signed by Fedora Legacy for security. Our key is >available from http://www.fedoralegacy.org/about/security.php > >You can verify each package with the following command: > > rpm --checksig -v > >If you only wish to verify that each package has not been corrupted or >tampered with, examine only the sha1sum with the following command: > > sha1sum > >8. References: > >http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0972 >http://marc.theaimsgroup.com/?l=bugtraq&m=106995837813873&w=2 >https://bugzilla.fedora.us/show_bug.cgi?id=1187 > >9. Contact: > >The Fedora Legacy security contact is . More >project details at https://www.fedoralegacy.org > >- -- >Jesse Keating RHCE (geek.j2solutions.net) >Fedora Legacy Team (www.fedoralegacy.org) >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) > >iD8DBQFAFfJ24v2HLvE71NURAonTAKCW99PZaO+Pqgw/Wyz79XcvoDwUtQCePW59 >bm7VDH125SXLZ3FwJR0mZvI= >=zOd3 >-----END PGP SIGNATURE----- > > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > From pekkas at netcore.fi Wed Jan 28 13:22:24 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 28 Jan 2004 15:22:24 +0200 (EET) Subject: mirror site questions for legacy RPMs In-Reply-To: <200401241044.19490.jkeating@j2solutions.net> Message-ID: On Sat, 24 Jan 2004, Jesse Keating wrote: > On Saturday 24 January 2004 10:27, Nielsen, Steve wrote: > > The docs on fedoralegacy point to fedora.us as > > the mirror to use. Just a little confusing. Do you > > know what the timings are for the fedoralegacy mirrors > > to be up and running and available? Will ftp, http and > > rsync be available ? > > Unfortunately I do not know how soon mirrors will come online. I had hoped > to hear back from my prospective master mirror by now, but it hasn't > happened. Yes, http, ftp, and rsync will be available on the master > mirror. Any news on this yet? Some have asked us (ftp.funet.fi) to mirror the legacy RPMs and we'd like to do that, preferably using rsync. -- 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 pearcec at commnav.com Wed Jan 28 15:33:38 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 28 Jan 2004 15:33:38 GMT Subject: apache httpd and slocate Message-ID: <33923.209.50.130.84.1075304018.commnav@home.commnav.com> It is always nice to keep instep with Red Hat EL. This gives us fuel for future security updates. As apposed to having to backport ourselves. -- Christian Pearce http://www.commnav.com Jesse Keating said: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 27 January 2004 09:19, seth vidal wrote: > > > slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html > > > > > > Looks liked 7.x and above might be affected? > > > > isn't this already in updates-testing iirc. > > Not yet. We need consensus to upgrade slocate to 2.7. Thats the route > that RHEL 2.1 took, and with encourging words from Notting, I'm > confident that it'll be smooth for fl as well. If we concur, I'll QA > and put in updates-testing > > > > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > > > > > Looks like 8 and above? > > > > not sure on this one. > > Neither am I. I'll try to research it today. > > - -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > Mondo DevTeam (www.mondorescue.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQFAFp+J4v2HLvE71NURAlNHAJ4zAWphBOG7Vaby6z+igyl34TgD+QCeOQnl > vI/nLcPq0IPZbJAD+QKFxG4= > =xCVW > -----END PGP SIGNATURE----- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From pearcec at commnav.com Wed Jan 28 15:51:38 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 28 Jan 2004 15:51:38 GMT Subject: Laundry list... Message-ID: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> I just got caught up with the list. I wanted to summarize what currently needs to be done. Testing: * tcpdump * cvs * ethereal QA: * gaim Decisions: * slocate - Are we going with 2.7? or sticking with 2.6 Packages: * yum - Red Hat 8.0 Ongoing: * Site verbage * Documentation * Mirroring *New security fixes. Does this sum it up? What else is there? I am personally going to work on QA and Testing today. -- Christian Pearce http://www.commnav.com From pearcec at commnav.com Wed Jan 28 15:56:50 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 28 Jan 2004 15:56:50 GMT Subject: Theory on update-testing. Message-ID: <34139.209.50.130.84.1075305410.commnav@home.commnav.com> I just updated yum, I have machines I wanted to get [update-testing]. So I uncomment it in /etc/yum.conf. Is it safe to leave [updates]? Should it be there? My general feeling is the packages should be the same once it goes from updates-testing to updates. Though updates-testing might change along the way. Another reason we need to bump builds. -- Christian Pearce http://www.commnav.com From skvidal at phy.duke.edu Wed Jan 28 15:51:25 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 28 Jan 2004 10:51:25 -0500 Subject: Laundry list... In-Reply-To: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> Message-ID: <1075305085.24942.5.camel@binkley> On Wed, 2004-01-28 at 10:51, Christian Pearce wrote: > I just got caught up with the list. I wanted to summarize what > currently needs to be done. Thanks for putting this list together. > Testing: > > * tcpdump > * cvs > * ethereal I've tested cvs in production, it works. What's the time limit on reporting problems with testing-updates before they go to updates? > QA: > * gaim what's the bug number on this one? > Decisions: > * slocate - Are we going with 2.7? or sticking with 2.6 I give my vote for 2.7 > * yum - Red Hat 8.0 what is the difference b/t this one and the one for rhl 7.2 or 7.3? -sv From pekkas at netcore.fi Wed Jan 28 16:06:27 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 28 Jan 2004 18:06:27 +0200 (EET) Subject: Laundry list... In-Reply-To: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> Message-ID: On Wed, 28 Jan 2004, Christian Pearce wrote: > Testing: > > * tcpdump > * cvs > * ethereal Btw, are all the dist versions tied together when moving from testing to updates? I.e., can a test update be "released" before all the arches have been tested? That is, because there seems to a bit of lack of support for moving these along, could this be fast-tracked by focusing the effort on RHL73 and doing the rest when appropriate? (Or am I looking at a wrong problem..?) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Wed Jan 28 16:09:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 08:09:22 -0800 Subject: Laundry list... In-Reply-To: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> Message-ID: <200401280809.23399.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 07:51, Christian Pearce wrote: > I just got caught up with the list. I wanted to summarize what > currently needs to be done. Welcome back! > Testing: > > * tcpdump > * cvs > * ethereal CVS has had some testing on 7.3, I'd like to see somebody test it on 7.2 and 8.0 before I launch it, but if that doesn't happen by tonight, I'm going to launch it as an update. Ditto with tcpdump and ethereal. > QA: > * gaim I'd have to check the bug again, but I think we made the decision to upgrade the gaim version to keep up with protocol changes. Gaim is one of those apps that is at the END of a dep chain, rather than somewhere in the middle, so bumping its version isn't going to hurt much. > Decisions: > * slocate - Are we going with 2.7? or sticking with 2.6 Going with 2.7. > Packages: > > * yum - Red Hat 8.0 Right, we need one for the stock RPM of RHL 8.0, and one for the rpm upgrade from rpm.org. I haven't uploaded the new rpm from rpm.org, I should do that tonight, signed w/ Legacy's key. > Ongoing: > > * Site verbage > * Documentation > * Mirroring > *New security fixes. > > Does this sum it up? What else is there? I am personally going to work > on QA and Testing today. Sums it up quite nicely. There are a few other packages which need attention too. MC needs QA after it got it's build-deps fixed, and there are somethings like synaptic and fedora-rpmtools that should be looked at for Legacy's sake. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF96y4v2HLvE71NURAllvAKDDI8zwcCQAvO1/D+dtqaL/Ef7GqwCglXtt ak+rpQJQVLrjSe9ZIM0M0bM= =LiLB -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Jan 28 16:21:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 08:21:48 -0800 Subject: Laundry list... In-Reply-To: References: Message-ID: <200401280821.50251.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 08:06, Pekka Savola wrote: > Btw, are all the dist versions tied together when moving from testing > to updates? I.e., can a test update be "released" before all the > arches have been tested? They are tied together. They need to move as one, so that only one announcement has to be sent, and thus avoiding confusion. > That is, because there seems to a bit of lack of support for moving > these along, could this be fast-tracked by focusing the effort on > RHL73 and doing the rest when appropriate? (Or am I looking at a wrong > problem..?) This is a real problem, and one I envisioned from the start. When I started this project, I only wanted to support RHL 7.3 and 9, but due to community influence, I've included support for 7.2 and 8.0 as well. I'm going to implement a policy that if a package receives good feedback on 7.3, and no other feedback with in 3 days, that the entire package group will be pushed to updates. Does anybody have a problem with this policy? - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF+Gc4v2HLvE71NURAuRqAJ4+zsomhrQiCUmyE45vp59fP4sE9ACgxx6S 9eeXv1UvfiFwIWqeljOPxUc= =PowT -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Jan 28 16:23:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 08:23:38 -0800 Subject: Theory on update-testing. In-Reply-To: <34139.209.50.130.84.1075305410.commnav@home.commnav.com> References: <34139.209.50.130.84.1075305410.commnav@home.commnav.com> Message-ID: <200401280823.39162.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 07:56, Christian Pearce wrote: > I just updated yum, I have machines I wanted to get [update-testing]. > So I uncomment it in /etc/yum.conf. Is it safe to leave [updates]? > Should it be there? You can leave updates. Packages are moved (literally mv updates-testing/i386/foo /updates/i386/) from updates-testing to updates, not rebuild or changed along the way. > My general feeling is the packages should be the same once it goes from > updates-testing to updates. Though updates-testing might change along > the way. Another reason we need to bump builds. That is my current policy. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF+IK4v2HLvE71NURAvpoAJ9nXImFmfo7STygoqtMirwvBxSJDQCgs3D2 FE5hd+lGXylrH3F9fJ81G8E= =QhW2 -----END PGP SIGNATURE----- From Freedom_Lover at pobox.com Wed Jan 28 16:56:54 2004 From: Freedom_Lover at pobox.com (Todd) Date: Wed, 28 Jan 2004 11:56:54 -0500 Subject: Laundry list... In-Reply-To: <200401280809.23399.jkeating@j2solutions.net> References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> <200401280809.23399.jkeating@j2solutions.net> Message-ID: <20040128165654.GL21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Wednesday 28 January 2004 07:51, Christian Pearce wrote: >> Testing: >> >> * tcpdump >> * cvs >> * ethereal > > CVS has had some testing on 7.3, I'd like to see somebody test it on > 7.2 and 8.0 before I launch it, but if that doesn't happen by > tonight, I'm going to launch it as an update. Ditto with tcpdump > and ethereal. I've been intending to test each of these on 7.2, 7.3, and 8.0 and put the results into bugzilla. Sorry that hasn't happened yet. I do have test boxes now for all three dists, so hopefully I can get around to doing something useful. >> QA: >> * gaim > > I'd have to check the bug again, but I think we made the decision to > upgrade the gaim version to keep up with protocol changes. Gaim is > one of those apps that is at the END of a dep chain, rather than > somewhere in the middle, so bumping its version isn't going to hurt > much. 2 questions on this: 1) Are these issues even relevant to gaim-0.59 which is what ships with 7.2-8.0? I know the advisories stated most of the issues were with 0.75 and lower, but my quick (and rather uneducated) glance at the code makes it seem like some or all of this stuff might not apply to the older gaim. If they do apply, the backporting might be fun. What has RHEL done, if anything? Looking at the errata page (https://rhn.redhat.com/errata/rh21ws-errata.html) I don't see anything released there which makes me think that either they're having to work hard to backport the fixes or they are not relevant. 2) IIRC, gaim > 0.60 requires gnome2 or kde 3 for any status docklets or whatever they're called. The older 0.59 shipped with the legacy dists this project is targeting had a gnome1 panel applet. Moving to the newer version will break this and may piss off quite a few people who use gaim regularly. That's just something to consider. If it's found that the security issues aren't relevant to 0.59, then it won't matter at all. Oh, and for reference, here's the RHEL3 errata page and CVE IDs for the gaim vulns (the CVE stuff is still not updated to provide anything useful): https://rhn.redhat.com/errata/RHSA-2004-033.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0006 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0007 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0008 Here's the bugtraq post detailing the issues: http://www.securityfocus.com/archive/1/351235/2004-01-25/2004-01-31/0 - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The Constitution continues to remain no threat to our current form of government. -- Joseph Sobran -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAF+nVuv+09NZUB1oRAstCAKCAl0MtqxfLjU1Pm7VUOj+dy035OQCeKELq HYxxkYo5ZvTD567KEQeXk28= =kXWM -----END PGP SIGNATURE----- From heinlein at cse.ogi.edu Wed Jan 28 17:20:54 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Wed, 28 Jan 2004 09:20:54 -0800 (PST) Subject: Laundry list... In-Reply-To: <1075305085.24942.5.camel@binkley> References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> <1075305085.24942.5.camel@binkley> Message-ID: On Wed, 28 Jan 2004, seth vidal wrote: > > * slocate - Are we going with 2.7? or sticking with 2.6 > > I give my vote for 2.7 Me, too. -- Paul Heinlein From jkeating at j2solutions.net Wed Jan 28 17:23:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 09:23:35 -0800 Subject: Laundry list... In-Reply-To: <20040128165654.GL21263@psilocybe.teonanacatl.org> References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> <200401280809.23399.jkeating@j2solutions.net> <20040128165654.GL21263@psilocybe.teonanacatl.org> Message-ID: <200401280923.36015.jkeating@j2solutions.net> On Wednesday 28 January 2004 08:56, Todd wrote: > 1) Are these issues even relevant to gaim-0.59 which is what ships > with 7.2-8.0? I know the advisories stated most of the issues were > with 0.75 and lower, but my quick (and rather uneducated) glance at > the code makes it seem like some or all of this stuff might not apply > to the older gaim. If they do apply, the backporting might be fun. > What has RHEL done, if anything? Looking at the errata page > (https://rhn.redhat.com/errata/rh21ws-errata.html) I don't see > anything released there which makes me think that either they're > having to work hard to backport the fixes or they are not relevant. That is something that really needs to be looked at. If we're not vulnerable, then I'm not going to touch it. I've got a feeling though that anybody who is using gaim regularly has updated their gaim to a newer third party version a while ago. If you have the ability, please do examine the codebase of 7.2-8.0 to see if it's flawed. > 2) IIRC, gaim > 0.60 requires gnome2 or kde 3 for any status docklets > or whatever they're called. The older 0.59 shipped with the legacy > dists this project is targeting had a gnome1 panel applet. Moving to > the newer version will break this and may piss off quite a few people > who use gaim regularly. That's just something to consider. If it's > found that the security issues aren't relevant to 0.59, then it won't > matter at all. This is a very good point, and something to look into. Jonny has built a backported 0.75 for RHL 7.3, has anybody tested it yet and seen if the dock applet works? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Wed Jan 28 17:31:23 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Jan 2004 11:31:23 -0600 Subject: Laundry list... In-Reply-To: <200401280821.50251.jkeating@j2solutions.net> References: <200401280821.50251.jkeating@j2solutions.net> Message-ID: <20040128113123.attyf4040oskosks@mail.ph.utexas.edu> Quoting Jesse Keating : > This is a real problem, and one I envisioned from the start. When I > started this project, I only wanted to support RHL 7.3 and 9, but due to > community influence, I've included support for 7.2 and 8.0 as well. I'm > going to implement a policy that if a package receives good feedback on > 7.3, and no other feedback with in 3 days, that the entire package group > will be pushed to updates. Does anybody have a problem with this policy? I'd rather say if it receives good feedback on either 7.x version, and good feedback on either of the 8/9 versions, then push them all. The 7.x versions are close enough to justify pushing one based on the other, and the 8/9 versions are somewhat close enough also. But to push 9 based on 7.3 seems a stretch unless the patch was really trivial. Now, that doesn't matter as much until we take over support for 9 anyway. If you are going to push all versions based on feedback of one version, maybe we should at least put a note/disclaimer in the announcement that it was done that way? Having said that, feel free to ignore my opinion if desired ;) I'm not really very attached to it ;) -- Eric Rostetter From rjohnson at medata.com Wed Jan 28 17:35:19 2004 From: rjohnson at medata.com (Rick Johnson) Date: Wed, 28 Jan 2004 09:35:19 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <200401261128.50714.jkeating@j2solutions.net> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261048.13461.jkeating@j2solutions.net> <20040126192354.GF21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> Message-ID: <4017F2D7.3060300@medata.com> Jesse Keating wrote: >>Yeah, I've seen those. I was looking to do a clean 8.0 install and >>only use legacy packages to test with. I'll wait to see when yum >>gets built and posted and check it out then. > > > k, should be tonight. > This was posted 1/26 - any update on the Yum release? Thx, -Rick -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From jkeating at j2solutions.net Wed Jan 28 17:48:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 09:48:17 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <4017F2D7.3060300@medata.com> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> Message-ID: <200401280948.17298.jkeating@j2solutions.net> On Wednesday 28 January 2004 09:35, Rick Johnson wrote: > This was posted 1/26 - any update on the Yum release? Ran into a snag when discussing the rpm upgrade for 8.0. I've agreed to once again put the rpm upgrade from rpm.org in the 8.0 legacy-utils, but this leads to a yum question. I do believe yum2.x works with the upgraded rpm, but not with the stock RPM. The stock RPM will need yum 1.x, so we have to roll out 2x yums. (can somebody correct me if I'm wrong here?) Also, I had to finish up some work on a chapter I'm writing for an upcoming book last night and I didn't get any free time to make that rpm build. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From drees at greenhydrant.com Wed Jan 28 17:53:18 2004 From: drees at greenhydrant.com (David Rees) Date: Wed, 28 Jan 2004 09:53:18 -0800 Subject: Laundry list... In-Reply-To: <20040128113123.attyf4040oskosks@mail.ph.utexas.edu> References: <200401280821.50251.jkeating@j2solutions.net> <20040128113123.attyf4040oskosks@mail.ph.utexas.edu> Message-ID: <4017F70E.6010403@greenhydrant.com> Eric Rostetter wrote, On 1/28/2004 9:31 AM: > Quoting Jesse Keating : > >>This is a real problem, and one I envisioned from the start. When I >>started this project, I only wanted to support RHL 7.3 and 9, but due to >>community influence, I've included support for 7.2 and 8.0 as well. I'm >>going to implement a policy that if a package receives good feedback on >>7.3, and no other feedback with in 3 days, that the entire package group >>will be pushed to updates. Does anybody have a problem with this policy? > > I'd rather say if it receives good feedback on either 7.x version, and > good feedback on either of the 8/9 versions, then push them all. The 7.x > versions are close enough to justify pushing one based on the other, and > the 8/9 versions are somewhat close enough also. But to push 9 based on > 7.3 seems a stretch unless the patch was really trivial. This policy makes sense to me. But ultimately it should be up to the bug-owner to make the final decision on a per-package basis. -Dave From skvidal at phy.duke.edu Wed Jan 28 17:50:33 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 28 Jan 2004 12:50:33 -0500 Subject: yum and rpm updates for 8.0 In-Reply-To: <200401280948.17298.jkeating@j2solutions.net> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> <200401280948.17298.jkeating@j2solutions.net> Message-ID: <1075312233.24942.19.camel@binkley> On Wed, 2004-01-28 at 12:48, Jesse Keating wrote: > On Wednesday 28 January 2004 09:35, Rick Johnson wrote: > > This was posted 1/26 - any update on the Yum release? > > Ran into a snag when discussing the rpm upgrade for 8.0. I've agreed to > once again put the rpm upgrade from rpm.org in the 8.0 legacy-utils, > but this leads to a yum question. I do believe yum2.x works with the > upgraded rpm, but not with the stock RPM. The stock RPM will need yum > 1.x, so we have to roll out 2x yums. (can somebody correct me if I'm > wrong here?) > you're not wrong. -sv From ms-nospam-0306 at arcor.de Wed Jan 28 18:06:48 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 28 Jan 2004 19:06:48 +0100 Subject: Laundry list... In-Reply-To: References: <34118.209.50.130.84.1075305098.commnav@home.commnav.com> <1075305085.24942.5.camel@binkley> Message-ID: <20040128190648.4bbc8e9f.ms-nospam-0306@arcor.de> On Wed, 28 Jan 2004 09:20:54 -0800 (PST), Paul Heinlein wrote: > On Wed, 28 Jan 2004, seth vidal wrote: > > > > * slocate - Are we going with 2.7? or sticking with 2.6 > > > > I give my vote for 2.7 > > Me, too. src.rpm for rh80, rh73, rh72 here: https://bugzilla.fedora.us/show_bug.cgi?id=1232#c1 -- From admin at cs.montana.edu Wed Jan 28 18:25:35 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 28 Jan 2004 11:25:35 -0700 (MST) Subject: mirror site questions for legacy RPMs In-Reply-To: References: <200401241044.19490.jkeating@j2solutions.net> Message-ID: <4851.153.90.196.197.1075314335.squirrel@webtest.cs.montana.edu> I would also like to mirror the items at least as a secondary mirror. (I just need local access to them for my users...) Pekka Savola said: > On Sat, 24 Jan 2004, Jesse Keating wrote: >> On Saturday 24 January 2004 10:27, Nielsen, Steve wrote: >> > The docs on fedoralegacy point to fedora.us as >> > the mirror to use. Just a little confusing. Do you >> > know what the timings are for the fedoralegacy mirrors >> > to be up and running and available? Will ftp, http and >> > rsync be available ? >> >> Unfortunately I do not know how soon mirrors will come online. I had >> hoped >> to hear back from my prospective master mirror by now, but it hasn't >> happened. Yes, http, ftp, and rsync will be available on the master >> mirror. > > Any news on this yet? Some have asked us (ftp.funet.fi) to mirror the > legacy RPMs and we'd like to do that, preferably using rsync. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From jpdalbec at ysu.edu Wed Jan 28 18:26:17 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Wed, 28 Jan 2004 13:26:17 -0500 Subject: fedora-legacy-list digest, Vol 1 #74 - 24 msgs In-Reply-To: <20040128170004.27465.73933.Mailman@listman.back-rdu.redhat.com> References: <20040128170004.27465.73933.Mailman@listman.back-rdu.redhat.com> Message-ID: <4017FEC9.5000302@ysu.edu> > Date: Tue, 27 Jan 2004 12:12:32 -0500 (EST) > From: John Jasen > To: fedora-legacy-list at redhat.com > Subject: apache httpd and slocate > Reply-To: fedora-legacy-list at redhat.com > > > slocate: https://rhn.redhat.com/errata/RHSA-2004-041.html > > Looks liked 7.x and above might be affected? > > httpd: https://rhn.redhat.com/errata/RHSA-2003-320.html > > Looks like 8 and above? That's my take on it. It looks like 7.3 is already fixed, anyway. "An issue in the handling of regular expressions from configuration files was discovered in releases of the Apache HTTP Server version 2.0 prior to 2.0.48. [...] The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0542 to this issue." $ cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) $ rpm -q apache apache-1.3.27-4 $ rpm -q --changelog apache | head * Thu Nov 13 2003 Joe Orton 1.3.27-4 - add security fix for CVE CAN-2003-0542 * Tue Aug 26 2003 Joe Orton 1.3.27-3 - add security fixes for CVE CAN-2003-0020, CERT VU#379828 - add bug fixes for #60281 * Wed Oct 23 2002 Nalin Dahyabhai 1.3.27-2 $ "A bug in the CGI daemon-based 'mod_cgid' module was discovered that can result in CGI script output being sent to the wrong client." $ ls -l /etc/httpd/modules/mod_cgid.so ls: /etc/httpd/modules/mod_cgid.so: No such file or directory $ ls -l /etc/httpd/modules/mod_cgi*.so -rwxr-xr-x 1 root root 14940 Dec 10 05:05 /etc/httpd/modules/mod_cgi.so $ From maillist at jasonlim.com Wed Jan 28 18:27:15 2004 From: maillist at jasonlim.com (Jason Lim) Date: Thu, 29 Jan 2004 02:27:15 +0800 Subject: yum and rpm updates for 8.0 References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> <200401280948.17298.jkeating@j2solutions.net> Message-ID: <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> It was my understanding that minimal changes were to be made to the original redhat distributions, so it would make sense to stay with the existing rpm version (unless it has a security flaw) and use yum 1.x. According to Fedoralegacy.org: -------------------- In most cases, fixes are backported to the current package version rather than upgrading the package to a newer version. This is done in order to limit the possible side-effects which can result from an upgrade. Packages are only upgraded to a newer version if consensus dictates that we should do so for some specific reason. -------------------- Does yum 2.x have some significant difference or features over yum 1.x that make it much more compelling to upgrade rpm as well? And is this difference or feature critical or significant to it's operation? I was of the thinking that changes to newer version would be kept to a minimal to avoid possible side-effects. Redhat didn't upgrade RH8's rpm over it's lifetime... so they must have deemed it stable (or stable enough). Do we... or should we... rock the boat just to get a newer version of yum? Just my 2c ... this has been discussed to death already ;-) ----- Original Message ----- From: "Jesse Keating" To: Sent: Thursday, 29 January, 2004 1:48 AM Subject: Re: yum and rpm updates for 8.0 Ran into a snag when discussing the rpm upgrade for 8.0. I've agreed to once again put the rpm upgrade from rpm.org in the 8.0 legacy-utils, but this leads to a yum question. I do believe yum2.x works with the upgraded rpm, but not with the stock RPM. The stock RPM will need yum 1.x, so we have to roll out 2x yums. (can somebody correct me if I'm wrong here?) Also, I had to finish up some work on a chapter I'm writing for an upcoming book last night and I didn't get any free time to make that rpm build. From jkeating at j2solutions.net Wed Jan 28 18:38:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 10:38:45 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401280948.17298.jkeating@j2solutions.net> <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> Message-ID: <200401281038.50456.jkeating@j2solutions.net> On Wednesday 28 January 2004 10:27, Jason Lim wrote: > It was my understanding that minimal changes were to be made to the > original redhat distributions, so it would make sense to stay with > the existing rpm version (unless it has a security flaw) and use yum > 1.x. Almost. The rpm locking issue is pretty bad, and Red Hat didn't upgrade it for certain internal political and technical reasons, which we are not bound to. > According to Fedoralegacy.org: > > -------------------- > In most cases, fixes are backported to the current package version > rather than upgrading the package to a newer version. This is done in > order to limit the possible side-effects which can result from an > upgrade. Packages are only upgraded to a newer version if consensus > dictates that we should do so for some specific reason. > -------------------- > > Does yum 2.x have some significant difference or features over yum > 1.x that make it much more compelling to upgrade rpm as well? And is > this difference or feature critical or significant to it's operation? > I was of the thinking that changes to newer version would be kept to > a minimal to avoid possible side-effects. Redhat didn't upgrade RH8's > rpm over it's lifetime... so they must have deemed it stable (or > stable enough). Do we... or should we... rock the boat just to get a > newer version of yum? > > Just my 2c ... this has been discussed to death already ;-) Yum is not the reason for upgrading RPM, it is merely a side bonus. The lock issue is a big issue for people who use apt or rpm directly. Yum users are not effected as yum uses a different library which will not trigger the lock. For this reason, rpm will be left as an optional upgrade, not one that is forced/required of Legacy users. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From pearcec at commnav.com Wed Jan 28 18:42:10 2004 From: pearcec at commnav.com (Christian Pearce) Date: Wed, 28 Jan 2004 18:42:10 GMT Subject: Laundry list... Message-ID: <35219.209.50.130.84.1075315330.commnav@home.commnav.com> My bust. Looks good. So slocate 2.7 is in the QA list. -- Christian Pearce http://www.commnav.com Michael Schwendt said: > > On Wed, 28 Jan 2004 09:20:54 -0800 (PST), Paul Heinlein wrote: > > > On Wed, 28 Jan 2004, seth vidal wrote: > > > > > > * slocate - Are we going with 2.7? or sticking with 2.6 > > > > > > I give my vote for 2.7 > > > > Me, too. > > src.rpm for rh80, rh73, rh72 here: > https://bugzilla.fedora.us/show_bug.cgi?id=1232#c1 > > -- > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rostetter at mail.utexas.edu Wed Jan 28 18:59:46 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Jan 2004 12:59:46 -0600 Subject: yum and rpm updates for 8.0 In-Reply-To: <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> <200401280948.17298.jkeating@j2solutions.net> <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> Message-ID: <20040128125946.9fxa68wo84ck08co@mail.ph.utexas.edu> Quoting Jason Lim : > It was my understanding that minimal changes were to be made to the > original redhat distributions, so it would make sense to stay with the > existing rpm version (unless it has a security flaw) and use yum 1.x. No no no. > Does yum 2.x have some significant difference or features over yum 1.x > that make it much more compelling to upgrade rpm as well? And is this It doesn't matter. The rpm version upgrade is to fix bugs in rpm, not to allow for using yum 2.x. Allowing for yum 2.x is just a nice side effect of fixing the actual problem (broken rpm). > avoid possible side-effects. Redhat didn't upgrade RH8's rpm over it's > lifetime... so they must have deemed it stable (or stable enough). Do Or, they knew that since they would EOL it shortly, why bother fixing it? > we... or should we... rock the boat just to get a newer version of yum? No, but we should rock the boat to help the project and project developers. My devel system (dual boot RH8 and RH9) is very broken now due to a corrupted rpm database caused by the buggy RPM in RH9. So, in order to develope for myself or FL I need to wipe out the system and re-install. This is a sever detriment to my development and to the project. Providing a stable rpm package that avoids database corruptions will help the project and its developers, and hence is worth rocking the boat. > Just my 2c ... this has been discussed to death already ;-) Yes, but people keep missing the point. It isn't about yum, it is about a buggy rpm package. -- Eric Rostetter From warren at togami.com Wed Jan 28 19:37:49 2004 From: warren at togami.com (Warren Togami) Date: Wed, 28 Jan 2004 09:37:49 -1000 Subject: yum and rpm updates for 8.0 In-Reply-To: <200401280948.17298.jkeating@j2solutions.net> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> <200401280948.17298.jkeating@j2solutions.net> Message-ID: <40180F8D.3020506@togami.com> Jesse Keating wrote: > On Wednesday 28 January 2004 09:35, Rick Johnson wrote: > >>This was posted 1/26 - any update on the Yum release? > > > Ran into a snag when discussing the rpm upgrade for 8.0. I've agreed to > once again put the rpm upgrade from rpm.org in the 8.0 legacy-utils, > but this leads to a yum question. I do believe yum2.x works with the > upgraded rpm, but not with the stock RPM. The stock RPM will need yum > 1.x, so we have to roll out 2x yums. (can somebody correct me if I'm > wrong here?) http://www.fedora.us/wiki/LegacyRPMUpgrade Users need to follow this guide in order to safely manually upgrade their rpm anyway, so have this as part of the Newbie HOWTO when they begin to use Legacy on RH8 and RH9. Upgrade rpm manually, install yum-2.x or apt and they are good to go. This avoids the need to QA and distribute a yum-1.x. Yes yum-1.x would avoid the deadlock issues because it uses the rpm-4.0.4 bindings, but it that does not avoid these issues for rpm itself. (And for those of you who are alarmed, just as we discussed earlier on this list, you are NOT BEING FORCED TO UPGRADE RPM. Just avoid the "legacy-utils" channel and use only the "updates" channel if you want to avoid upgrading rpm.) > > Also, I had to finish up some work on a chapter I'm writing for an > upcoming book last night and I didn't get any free time to make that > rpm build. > I would not bother rebuilding rpm. Instead I would take jbj's rpm-4.1.1 binaries and use rpm-4.2.x to resign them (replaces his signature with yours). We know have all these 9+ months that his binaries work. Warren From rjohnson at medata.com Wed Jan 28 19:44:38 2004 From: rjohnson at medata.com (Rick Johnson) Date: Wed, 28 Jan 2004 11:44:38 -0800 Subject: fedora-legacy-announce spamming? Message-ID: <40181126.8050706@medata.com> I've gotten the same sreen announcement 5-6 times now. Is there a problem w/ this list? I'm fairly certain I'm only subscribed once. -Rick -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From rjohnson at medata.com Wed Jan 28 19:45:37 2004 From: rjohnson at medata.com (Rick Johnson) Date: Wed, 28 Jan 2004 11:45:37 -0800 Subject: fedora-legacy-announce spamming? In-Reply-To: <40181126.8050706@medata.com> References: <40181126.8050706@medata.com> Message-ID: <40181161.3010000@medata.com> Rick Johnson wrote: > I've gotten the same sreen announcement 5-6 times now. Is there a > problem w/ this list? I'm fairly certain I'm only subscribed once. > > -Rick Nevermind - just got the apology letter. Sorry for the noise. -- Rick Johnson, RHCE #807302311706007 - rjohnson at medata.com Linux/Network Administrator - Medata, Inc. PGP Public Key: https://mail.medata.com/pgp/rjohnson.asc From warren at togami.com Wed Jan 28 19:45:46 2004 From: warren at togami.com (Warren Togami) Date: Wed, 28 Jan 2004 09:45:46 -1000 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040128125946.9fxa68wo84ck08co@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401261128.50714.jkeating@j2solutions.net> <4017F2D7.3060300@medata.com> <200401280948.17298.jkeating@j2solutions.net> <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> <20040128125946.9fxa68wo84ck08co@mail.ph.utexas.edu> Message-ID: <4018116A.2030102@togami.com> Eric Rostetter wrote: >>avoid possible side-effects. Redhat didn't upgrade RH8's rpm over it's >>lifetime... so they must have deemed it stable (or stable enough). Do > > > Or, they knew that since they would EOL it shortly, why bother fixing it? > I suspect this has been somewhat true... also there is a limited amount of paid development labor hours and several operating systems being developed at once. Probably they wanted to avoid the support nightmare of people locking up during the rpm upgrade and freaking out. Worst case scenario is rpm is totally broken due to a lockup during upgrade... but I personally have not seen this happen. > >>we... or should we... rock the boat just to get a newer version of yum? > > > No, but we should rock the boat to help the project and project developers. > My devel system (dual boot RH8 and RH9) is very broken now due to a corrupted > rpm database caused by the buggy RPM in RH9. So, in order to develope for > myself or FL I need to wipe out the system and re-install. This is a sever > detriment to my development and to the project. Providing a stable rpm > package that avoids database corruptions will help the project and its > developers, and hence is worth rocking the boat. > > >>Just my 2c ... this has been discussed to death already ;-) > > > Yes, but people keep missing the point. It isn't about yum, it is about > a buggy rpm package. > Exactly. Warren From rostetter at mail.utexas.edu Wed Jan 28 20:38:39 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Jan 2004 14:38:39 -0600 Subject: /etc/yum.conf In-Reply-To: <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> References: <200401190018.35186.jkeating@j2solutions.net> <200401200859.59949.jkeating@j2solutions.net> <6.0.1.1.2.20040120123212.01d979e8@mail.dynamicnet.net> <200401201611.04090.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> Message-ID: <20040128143839.0k6onkc8koswwk80@mail.ph.utexas.edu> Quoting g : > it seems like this list is a "devel" list. is there or should there be > a separate "users" list? This is the user list. Right now it is more devel, but that is just temporary. We could have a devel list also, but it is optional. I'd suggest maybe a new list though, where we can send security notices. Say I hear about some security problem that may need patching, I could send it to a dedicated list rather than the general list. Any one else agree with that separation? So, right now we have: fedora-legacy-list General discussion fedora-legacy-announce Update announcements We might consider adding: fedora-legacy-devel General developer discussions not of general interest to the end user fedora-legacy-security For reporting security issues with packages/software I don't really like that last name, but my brain is fried from dealing with all the recent virus/worm/trojan stuff, and I can't think of anything better right now... -- Eric Rostetter From jkeating at j2solutions.net Wed Jan 28 20:57:49 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 12:57:49 -0800 Subject: /etc/yum.conf In-Reply-To: <20040128143839.0k6onkc8koswwk80@mail.ph.utexas.edu> References: <200401190018.35186.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <20040128143839.0k6onkc8koswwk80@mail.ph.utexas.edu> Message-ID: <200401281257.49132.jkeating@j2solutions.net> On Wednesday 28 January 2004 12:38, Eric Rostetter wrote: > This is the user list. Right now it is more devel, but that is just > temporary. We could have a devel list also, but it is optional. > > I'd suggest maybe a new list though, where we can send security > notices. Say I hear about some security problem that may need > patching, I could send it to a dedicated list rather than the general > list. Any one else agree with that separation? > > So, right now we have: > > fedora-legacy-list General discussion > fedora-legacy-announce Update announcements > > We might consider adding: > > fedora-legacy-devel General developer discussions not of general > interest to the end user > fedora-legacy-security For reporting security issues with > packages/software > > I don't really like that last name, but my brain is fried from > dealing with all the recent virus/worm/trojan stuff, and I can't > think of anything better right now... Danger Will Robinson... List separation like that can be a bad thing, as conversations get fragmented, crossposting occurs, etc, etc... If _ANYTHING_ I'd allow for a -devel list, but honestly, what would be discussed on the general -list ? We aren't here for general support on the product, RH already has lists for that. Package update announcements are made through the -announce list... what else is there? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From admin at cs.montana.edu Wed Jan 28 21:47:32 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 28 Jan 2004 14:47:32 -0700 (MST) Subject: /etc/yum.conf In-Reply-To: <200401281257.49132.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <20040128143839.0k6onkc8koswwk80@mail.ph.utexas.edu> <200401281257.49132.jkeating@j2solutions.net> Message-ID: <1718.153.90.196.197.1075326452.squirrel@webtest.cs.montana.edu> Jesse Keating said: > Danger Will Robinson... > > List separation like that can be a bad thing, as conversations get > fragmented, crossposting occurs, etc, etc... Dude, I agree. We are all on the same page anyways. Keep it to one list in my opinion. As is. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From admin at cs.montana.edu Wed Jan 28 21:48:14 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 28 Jan 2004 14:48:14 -0700 (MST) Subject: rsync mirror Message-ID: <1724.153.90.196.197.1075326494.squirrel@webtest.cs.montana.edu> So what method should I use to create a local mirror? fmirror.pl or similar? Not rsync? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From pmatilai at welho.com Wed Jan 28 22:51:26 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 29 Jan 2004 00:51:26 +0200 Subject: yum and rpm updates for 8.0 In-Reply-To: <200401281038.50456.jkeating@j2solutions.net> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401280948.17298.jkeating@j2solutions.net> <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> <200401281038.50456.jkeating@j2solutions.net> Message-ID: <1075330286.4255.37.camel@chip.laiskiainen.org> On Wed, 2004-01-28 at 20:38, Jesse Keating wrote: > On Wednesday 28 January 2004 10:27, Jason Lim wrote: > > It was my understanding that minimal changes were to be made to the > > original redhat distributions, so it would make sense to stay with > > the existing rpm version (unless it has a security flaw) and use yum > > 1.x. > > Almost. The rpm locking issue is pretty bad, and Red Hat didn't upgrade > it for certain internal political and technical reasons, which we are > not bound to. RH lived through the RHL 8.0 rpm lockup period and survived. If Fedora Legacy starts fixing bugs RH didn't .. where does that end? The people who want legacy support are likely willing to rather live with documented bugs than with unknown new ones., otherwise they would've already upgraded to something newer already. Just my humble opinion, - Panu - From jkeating at j2solutions.net Wed Jan 28 22:59:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 14:59:01 -0800 Subject: rsync mirror In-Reply-To: <1724.153.90.196.197.1075326494.squirrel@webtest.cs.montana.edu> References: <1724.153.90.196.197.1075326494.squirrel@webtest.cs.montana.edu> Message-ID: <200401281459.16017.jkeating@j2solutions.net> On Wednesday 28 January 2004 13:48, Lucas Albers wrote: > So what method should I use to create a local mirror? > fmirror.pl or similar? > Not rsync? Rsync is in the works. Real Soon Now(tm) I'll be calling all mirror folks to send me their information so I can make a quick alias for mirror discussions, and so that we can keep an accurate mirror list for our users. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Thu Jan 29 01:16:18 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Jan 2004 19:16:18 -0600 Subject: /etc/yum.conf In-Reply-To: <200401281257.49132.jkeating@j2solutions.net> References: <200401190018.35186.jkeating@j2solutions.net> <1074875642.11826.14781.camel@ruby.rub.gnuleaf.net> <20040128143839.0k6onkc8koswwk80@mail.ph.utexas.edu> <200401281257.49132.jkeating@j2solutions.net> Message-ID: <20040128191618.fpcqxw4o8osoo0s8@mail.ph.utexas.edu> Quoting Jesse Keating : > Danger Will Robinson... *grin* > List separation like that can be a bad thing, as conversations get > fragmented, crossposting occurs, etc, etc... That is true (in particular the cross-posting). > If _ANYTHING_ I'd allow > for a -devel list, but honestly, what would be discussed on the general > -list ? General user's questions (and there will be a fair amount of them). > We aren't here for general support on the product, RH already > has lists for that. No, but we are here for general support of our product (how to use yum/apt, problems with our site/mirrors) and general questions about the project. > Package update announcements are made through the > -announce list... what else is there? Lots. But I'm fine with the way things are. My real wish would be one to report new vulnerabilities to separate from the main list, actually, which you feel isn't important. But I'd hate to see the main list flooded with duplicate reports, and people leave the list because of that annoyance. But, I don't really care much. Was just responding to someone's old message about the lists with some new ideas for consideration. I'm happy either way... -- Eric Rostetter From rostetter at mail.utexas.edu Thu Jan 29 01:29:37 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 28 Jan 2004 19:29:37 -0600 Subject: yum and rpm updates for 8.0 In-Reply-To: <1075330286.4255.37.camel@chip.laiskiainen.org> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401280948.17298.jkeating@j2solutions.net> <01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9> <200401281038.50456.jkeating@j2solutions.net> <1075330286.4255.37.camel@chip.laiskiainen.org> Message-ID: <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> Quoting Panu Matilainen : > RH lived through the RHL 8.0 rpm lockup period and survived. If Fedora > Legacy starts fixing bugs RH didn't .. where does that end? At our boundries that we've defined. > The people who want legacy support are likely willing to rather live > with documented bugs than with unknown new ones., otherwise they > would've already upgraded to something newer already. Yes, but are the FL developers willing to? And should FL not try to warn these people about a problem which could cause our updates to fail to install on their machine? And provide a solution that prevents such failures? As was said earlier, this is an optional upgrade anyway. So if they want to live with the bugs, and corrupt their system or fail to update their system, that is fine and they may do so. If instead they would like a more stable system so they can sleep better, then they can update it. Myself, I've been hit too many times by the bugs not to update. Your mileage may vary. > Just my humble opinion, > > - Panu - -- Eric Rostetter From admin at cs.montana.edu Thu Jan 29 02:57:58 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Wed, 28 Jan 2004 19:57:58 -0700 (MST) Subject: yum and rpm updates for 8.0 In-Reply-To: <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org><200401280948.17298.jkeating@j2solutions.net><01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9><200401281038.50456.jkeating@j2solutions.net><1075330286.4255.37.camel@chip.laiskiainen.org> <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> Message-ID: <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> If it works, don't touch it, even if it is slightly buggy. Change bad. I don't want to change anything on my 7.3 boxes, I just want to get off them, and have them work until I switch off them. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From warren at togami.com Thu Jan 29 03:07:43 2004 From: warren at togami.com (Warren Togami) Date: Wed, 28 Jan 2004 17:07:43 -1000 Subject: yum and rpm updates for 8.0 In-Reply-To: <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org><200401280948.17298.jkeating@j2solutions.net><01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9><200401281038.50456.jkeating@j2solutions.net><1075330286.4255.37.camel@chip.laiskiainen.org> <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> Message-ID: <401878FF.2040107@togami.com> Lucas Albers wrote: > If it works, don't touch it, even if it is slightly buggy. > Change bad. > I don't want to change anything on my 7.3 boxes, I just want to get off > them, and have them work until I switch off them. > Nobody ever suggested upgrading rpm on 7.x. RH8 is the very broken one. RH9 is the somewhat broken one. Warren From jkeating at j2solutions.net Thu Jan 29 05:53:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 21:53:02 -0800 Subject: Calling rsync testers... Message-ID: <200401282153.07122.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have enabled rsync on download.fedoralegacy.org: rsync://download.fedoralegacy.org/legacy Will some of you please use rsync to test that things are working correctly? Report problems to me please. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGJ/C4v2HLvE71NURApFEAKC4ohbdp5/sxnrROx70dz3ekBvGNwCfbFFF es8LuvnaO+N8IOme7tKmQMY= =FHjj -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Thu Jan 29 06:25:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Jan 2004 01:25:42 -0500 Subject: Calling rsync testers... In-Reply-To: <200401282153.07122.jkeating@j2solutions.net> References: <200401282153.07122.jkeating@j2solutions.net> Message-ID: <1075357542.28644.6.camel@binkley> On Thu, 2004-01-29 at 00:53, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have enabled rsync on download.fedoralegacy.org: > > rsync://download.fedoralegacy.org/legacy > > Will some of you please use rsync to test that things are working > correctly? Report problems to me please. working from mirror.dulug.duke.edu -sv From jkeating at j2solutions.net Thu Jan 29 06:35:01 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 22:35:01 -0800 Subject: [FLSA-2004:1207] Updated cvs resolves security vulnerability Message-ID: <200401282235.03021.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cvs resolves security vulnerability Advisory ID: FLSA:1207 Issue date: 2004-01-28 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1207 CVE Names: CAN-2003-0977 - ----------------------------------------------------------------------- 1. Topic: Updated cvs packages are now available that fix a security vulnerability which may allow cvs to attempt to create files and directories in the root file system, as well as prevent the cvsd from retaining root privileges after a user login. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: CVS (Concurrent Version System) is a version control system that can record the history of your files (usually, but not always, source code). CVS only stores the differences between versions, instead of every version of every file you have ever created. CVS also keeps a log of who, when, and why changes occurred. A flaw was found in versions of CVS prior to 1.11.10 where a malformed module request could cause the CVS server to attempt to create files or directories at the root level of the file system. However, normal file system permissions would prevent the creation of these misplaced directories. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0977 to this issue. Another flaw was found that would allow the cvsd process to continue to run as root after a user login. Previously, any user with the ability to write the CVSROOT/passwd file could execute arbitrary code as the root user on systems with CVS pserver access enabled. Users of cvs should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank Seth Vidal, Jason Rohwedder and Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1207 - cvs security patches 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/cvs-1.11.2-9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/cvs-1.11.2-9.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad 7.2/updates/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm 469e08276fd61a06f816d4d7df68bc6c85a98560 7.2/updates/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm 46da2ca673b3af8a08eab8b1d4322e0d6a9d08ad 7.3/updates/SRPMS/cvs-1.11.1p1-9.7.legacy.src.rpm 1dfba0ce740a20bd0977eede82f606ea2f907b00 7.3/updates/i386/cvs-1.11.1p1-9.7.legacy.i386.rpm 31e98f14255c132d3f548a51096b0c444a45797a 8.0/updates/SRPMS/cvs-1.11.2-9.legacy.src.rpm e415df08fdfd35216c68651aa5214e7ecdb04268 8.0/updates/i386/cvs-1.11.2-9.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0977 http://ccvs.cvshome.org/servlets/NewsItemView?newsID=88 http://ccvs.cvshome.org/servlets/NewsItemView?newsID=84&JServSessionIdservlets=8u3x1myav1 https://bugzilla.fedora.us/show_bug.cgi?id=1207 9. Contact: The Fedora Legacy security contact is . More project details at https://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGKmV4v2HLvE71NURAqsHAJ40Ncw3AWtnYA+SMlkGxfw3u1BRsQCfQndA erOb1kj48msXit5ShYM+8Ds= =Hx1c -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Thu Jan 29 06:39:50 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 28 Jan 2004 22:39:50 -0800 (PST) Subject: Calling rsync testers... In-Reply-To: <200401282153.07122.jkeating@j2solutions.net> References: <200401282153.07122.jkeating@j2solutions.net> Message-ID: > I have enabled rsync on download.fedoralegacy.org: > > rsync://download.fedoralegacy.org/legacy > > Will some of you please use rsync to test that things are working > correctly? Report problems to me please. Maybe I didn't speak up when I should have, or perhaps I was sleeping or something... The headers directory seems to be under the $ARCH directory. Hence if I rsync something like this: rsync://download.fedoralegacy.org/legacy/redhat/7.3/updates/i386 I have to remember to do an exclude on the headers directory. The point is that headers are basically useless if I'm just keeping an rpm archive in sync. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From jkeating at j2solutions.net Thu Jan 29 06:47:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 22:47:58 -0800 Subject: Calling rsync testers... In-Reply-To: References: <200401282153.07122.jkeating@j2solutions.net> Message-ID: <200401282247.59570.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 22:39, Chuck Wolber wrote: > Maybe I didn't speak up when I should have, or perhaps I was sleeping or > something... The headers directory seems to be under the $ARCH > directory. Hence if I rsync something like this: > > rsync://download.fedoralegacy.org/legacy/redhat/7.3/updates/i386 > > I have to remember to do an exclude on the headers directory. The point > is that headers are basically useless if I'm just keeping an rpm archive > in sync. Yes you do, but this allows us to have a seperate SRPM repository and a seperate i386 or amd64 or... repository. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGKye4v2HLvE71NURAkbLAKCNKVCr1zNZhbPL9CX155q1JxwBLgCgnc4u ULUWq69zoTn/XWap7DEXpwI= =8Flm -----END PGP SIGNATURE----- From pekkas at netcore.fi Thu Jan 29 07:19:10 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 29 Jan 2004 09:19:10 +0200 (EET) Subject: Calling rsync testers... In-Reply-To: <200401282153.07122.jkeating@j2solutions.net> Message-ID: On Wed, 28 Jan 2004, Jesse Keating wrote: > I have enabled rsync on download.fedoralegacy.org: > > rsync://download.fedoralegacy.org/legacy > > Will some of you please use rsync to test that things are working > correctly? Report problems to me please. Uhh. Why do we have the redhat-published updates in fedoralegacy.org? We don't want to store them twice :-). Similarly, the "os/" tree seems redundant. Maybe it would be best to put the old stuff in "updates-redhat" directory or whatever, and add that to the yum configs if need be. But not sure how to deal with the associated headers files though. -- 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 Thu Jan 29 07:24:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Jan 2004 23:24:22 -0800 Subject: Calling rsync testers... In-Reply-To: References: Message-ID: <200401282324.29410.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 23:19, Pekka Savola wrote: > Uhh. Why do we have the redhat-published updates in fedoralegacy.org? > We don't want to store them twice :-). Similarly, the "os/" tree > seems redundant. Becuase Fedoralegacy needs to be self-hosting. We discussed this in full when deciding on a master mirror system layout. > Maybe it would be best to put the old stuff in "updates-redhat" > directory or whatever, and add that to the yum configs if need be. > > But not sure how to deal with the associated headers files though. Nope, sorry. We're set as we are right now. rsync is able to get just the "legacy" stuff. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGLUr4v2HLvE71NURAtaRAJ9r4dW4l/qffp65ckYR0A+WzPLc+wCgpzwm id2ztgPbsgl7n0XJ60iX6ro= =xvqk -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Thu Jan 29 07:32:59 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 28 Jan 2004 23:32:59 -0800 (PST) Subject: Calling rsync testers... In-Reply-To: References: Message-ID: > Uhh. Why do we have the redhat-published updates in fedoralegacy.org? > We don't want to store them twice :-). Yes we do. If you're trying to rsync a complete set of updates for redhat 7.3, you have to create two directories if they're separated. For the sake of simplicity, it's easy to rsync one archive and then run a freshen on *.rpm -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From drees at greenhydrant.com Thu Jan 29 08:11:54 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 29 Jan 2004 00:11:54 -0800 Subject: Calling rsync testers... In-Reply-To: <200401282153.07122.jkeating@j2solutions.net> References: <200401282153.07122.jkeating@j2solutions.net> Message-ID: <4018C04A.2000301@greenhydrant.com> Jesse Keating wrote, On 1/28/2004 9:53 PM: > I have enabled rsync on download.fedoralegacy.org: > > rsync://download.fedoralegacy.org/legacy > > Will some of you please use rsync to test that things are working > correctly? Report problems to me please. Looks good! -Dave From peter.peltonen at iki.fi Thu Jan 29 08:17:36 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 29 Jan 2004 10:17:36 +0200 Subject: Calling rsync testers... In-Reply-To: References: Message-ID: <4018C1A0.80707@iki.fi> Pekka Savola wrote: > But not sure how to deal with the associated headers files though. Please mirror the whole legacy tree -- this would make ftp.funet.fi "yum enabled" which would make a _lot_ of people very happy in Finland! ftp.jyu.fi offers their RHL RPMs via apt but not with yum, if I remember correctly. And yum is becomind the standard with RH users. If you don't want to store RHL os/updates RPMs twice then stop mirroring them from ftp.redhat.com? Regards, Peter From pekkas at netcore.fi Thu Jan 29 09:57:32 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 29 Jan 2004 11:57:32 +0200 (EET) Subject: Calling rsync testers... In-Reply-To: <4018C1A0.80707@iki.fi> Message-ID: On Thu, 29 Jan 2004, Peter Peltonen wrote: > Pekka Savola wrote: > > But not sure how to deal with the associated headers files though. > > Please mirror the whole legacy tree -- this would make ftp.funet.fi "yum > enabled" which would make a _lot_ of people very happy in Finland! > > ftp.jyu.fi offers their RHL RPMs via apt but not with yum, if I remember > correctly. And yum is becomind the standard with RH users. > > If you don't want to store RHL os/updates RPMs twice then stop mirroring > them from ftp.redhat.com? OK, we've mirrored the whole tree, using hard-linking, but only Red Hat 7.3, because I believe the rest is waste of resources (both the developers and the sites). I'll add RHL9 when it becomes available in fedoralegacy.org. available at: ftp://ftp.funet.fi/pub/mirrors/download.fedoralegacy.org/ http://ftp.funet.fi/pub/mirrors/download.fedoralegacy.org/ ftp://ftp.ipv6.funet.fi/pub/mirrors/download.fedoralegacy.org/ http://ftp.ipv6.funet.fi/pub/mirrors/download.fedoralegacy.org/ -- 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 cra at WPI.EDU Thu Jan 29 14:33:45 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 29 Jan 2004 09:33:45 -0500 Subject: Calling rsync testers... In-Reply-To: References: <4018C1A0.80707@iki.fi> Message-ID: <20040129143345.GA15491@angus.ind.WPI.EDU> On Thu, Jan 29, 2004 at 11:57:32AM +0200, Pekka Savola wrote: > OK, we've mirrored the whole tree, using hard-linking, but only Red How did you do this? I've tried pre-hardlinking my Red Hat mirror to the fedora legacy tree (following http://www.fedora.us/wiki/FedoraMirrorHOWTO), but every time I start rsync, it un-hardlinks the files and redownloads them. I moved the linked files to the single i386 and SRPMS directories for legacy, and the dates, times, and file sizes match. The contents are also identical. For example, these are commands I am using for 7.2 updates: rm -rf \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/* cp -al \ /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/i[3456]86 \ /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/athlon \ /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/noarch \ /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/SRPMS \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates mv \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i[456]86/* \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/athlon/* \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/noarch/* \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i386 rm -rf \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i[456]86 \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/athlon \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/noarch rsync -auv \ rsync://download.fedoralegacy.org/legacy/redhat/7.2/updates \ /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2 Does anyone know how to make rsync not undo the hardlinking? Thanks. From tdiehl at rogueind.com Thu Jan 29 14:49:46 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 29 Jan 2004 09:49:46 -0500 (EST) Subject: Calling rsync testers... In-Reply-To: <20040129143345.GA15491@angus.ind.WPI.EDU> References: <4018C1A0.80707@iki.fi> <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: On Thu, 29 Jan 2004, Charles R. Anderson wrote: > On Thu, Jan 29, 2004 at 11:57:32AM +0200, Pekka Savola wrote: > > OK, we've mirrored the whole tree, using hard-linking, but only Red > > How did you do this? > > I've tried pre-hardlinking my Red Hat mirror to the fedora legacy tree > (following http://www.fedora.us/wiki/FedoraMirrorHOWTO), but every > time I start rsync, it un-hardlinks the files and redownloads them. I > moved the linked files to the single i386 and SRPMS directories for > legacy, and the dates, times, and file sizes match. The contents are > also identical. For example, these are commands I am using for 7.2 > updates: > > Does anyone know how to make rsync not undo the hardlinking? Ummm, maybe use -H >From the rsync man pg: -H, --hard-links This tells rsync to recreate hard links on the remote system to be the same as the local system. Without this option hard links are treated like regular files. Note that rsync can only detect hard links if both parts of the link are in the list of files being sent. This option can be quite slow, so only use it if you need it. Of course if the remote system is not hard linked then you cannot do this. Instead if going through the mess you did to create the hardlinks, you could simply run the hardlink program over the trees. HTH, ...Tom From wstockal at compusmart.ab.ca Thu Jan 29 14:45:21 2004 From: wstockal at compusmart.ab.ca (William Stockall) Date: Thu, 29 Jan 2004 07:45:21 -0700 Subject: Calling rsync testers... In-Reply-To: <20040129143345.GA15491@angus.ind.WPI.EDU> References: <4018C1A0.80707@iki.fi> <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: <40191C81.1060508@compusmart.ab.ca> rsync -H will preserve hard links. Will. Charles R. Anderson wrote: > On Thu, Jan 29, 2004 at 11:57:32AM +0200, Pekka Savola wrote: > >>OK, we've mirrored the whole tree, using hard-linking, but only Red > > > How did you do this? > > I've tried pre-hardlinking my Red Hat mirror to the fedora legacy tree > (following http://www.fedora.us/wiki/FedoraMirrorHOWTO), but every > time I start rsync, it un-hardlinks the files and redownloads them. I > moved the linked files to the single i386 and SRPMS directories for > legacy, and the dates, times, and file sizes match. The contents are > also identical. For example, these are commands I am using for 7.2 > updates: > > rm -rf \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/* > > cp -al \ > /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/i[3456]86 \ > /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/athlon \ > /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/noarch \ > /home/ftp/pub/mirrors/redhat/linux/updates/7.2/en/os/SRPMS \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates > > mv \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i[456]86/* \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/athlon/* \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/noarch/* \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i386 > > rm -rf \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/i[456]86 \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/athlon \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2/updates/noarch > > rsync -auv \ > rsync://download.fedoralegacy.org/legacy/redhat/7.2/updates \ > /home/ftp/pub/mirrors/fedora-legacy/redhat/7.2 > > > Does anyone know how to make rsync not undo the hardlinking? > > Thanks. > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From cra at WPI.EDU Thu Jan 29 15:05:08 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 29 Jan 2004 10:05:08 -0500 Subject: Calling rsync testers... In-Reply-To: References: <4018C1A0.80707@iki.fi> <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: <20040129150508.GC15491@angus.ind.WPI.EDU> On Thu, Jan 29, 2004 at 09:49:46AM -0500, Tom Diehl wrote: > Ummm, maybe use -H That won't work to preserve *local* hardlinks, and it is specfically recommended that it not be used in the fedora wiki. > Instead if going through the mess you did to create the hardlinks, you could > simply run the hardlink program over the trees. Then I would need twice the space temporarily, until the hardlink program was run. From tdiehl at rogueind.com Thu Jan 29 16:06:41 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 29 Jan 2004 11:06:41 -0500 (EST) Subject: Calling rsync testers... In-Reply-To: <20040129150508.GC15491@angus.ind.WPI.EDU> References: <4018C1A0.80707@iki.fi> <20040129143345.GA15491@angus.ind.WPI.EDU> <20040129150508.GC15491@angus.ind.WPI.EDU> Message-ID: On Thu, 29 Jan 2004, Charles R. Anderson wrote: > On Thu, Jan 29, 2004 at 09:49:46AM -0500, Tom Diehl wrote: > > Ummm, maybe use -H > > That won't work to preserve *local* hardlinks, and it is specfically > recommended that it not be used in the fedora wiki. That does not necessarily make it right, but in this case it might be. > > Instead if going through the mess you did to create the hardlinks, you could > > simply run the hardlinks program over the trees. > > Then I would need twice the space temporarily, until the hardlinks > program was run. The problem is if the master site is not hard linked then your site will not be hard linked. That is what rsync does. If the master site is hard linked then using -H is the only way to preserve them, in spite of what the WIKI says. Since I do not mirror legacy I do not know if the master site is hardlinked or not. If it is not IMO it should be. :-) HTH, ........Tom From berubejd at hotmail.com Thu Jan 29 07:44:15 2004 From: berubejd at hotmail.com (Jeffrey Berube) Date: Thu, 29 Jan 2004 02:44:15 -0500 Subject: Calling rsync testers... Message-ID: This may seem like a stupid question, and it may have already been answered and I just missed it, but why are there non-i386 packages in the i386 directory? Such as: redhat/8.0/updates/i386/kernel-uml-2.4.18-19.8.0.i686.rpm Thanks! Jeffrey D Berube -----Original Message----- From: Jesse Keating [mailto:jkeating at j2solutions.net] Sent: Wednesday, January 28, 2004 9:53 PM To: fedora-legacy-list at redhat.com Subject: Calling rsync testers... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have enabled rsync on download.fedoralegacy.org: rsync://download.fedoralegacy.org/legacy Will some of you please use rsync to test that things are working correctly? Report problems to me please. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGJ/C4v2HLvE71NURApFEAKC4ohbdp5/sxnrROx70dz3ekBvGNwCfbFFF es8LuvnaO+N8IOme7tKmQMY= =FHjj -----END PGP SIGNATURE----- -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list _________________________________________________________________ High-speed users?be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 From jkeating at j2solutions.net Thu Jan 29 16:08:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 08:08:52 -0800 Subject: Calling rsync testers... In-Reply-To: References: <4018C1A0.80707@iki.fi> <20040129150508.GC15491@angus.ind.WPI.EDU> Message-ID: <200401290808.53880.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 January 2004 08:06, Tom Diehl wrote: > The problem is if the master site is not hard linked then your site will > not be hard linked. That is what rsync does. If the master site is hard > linked then using -H is the only way to preserve them, in spite of what > the WIKI says. Since I do not mirror legacy I do not know if the master > site is hardlinked or not. If it is not IMO it should be. :-) Why should it be? I only have one copy of the content on the mirror server, and it's in the directories you have access to. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGTAU4v2HLvE71NURAiopAJ9e1H6KbEGlyPDVAewpWcSypxkgyQCgqDDr jOPHPY2fMFeKKvewxY7vZ6o= =4I98 -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Thu Jan 29 16:09:05 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 29 Jan 2004 10:09:05 -0600 Subject: yum and rpm updates for 8.0 In-Reply-To: <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org><200401280948.17298.jkeating@j2solutions.net><01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9><200401281038.50456.jkeating@j2solutions.net><1075330286.4255.37.camel@chip.laiskiainen.org> <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> Message-ID: <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> Quoting Lucas Albers : > If it works, don't touch it, even if it is slightly buggy. Doesn't work. More than slightly buggy. > Change bad. So you don't want any security updates, as they are changes? > I don't want to change anything on my 7.3 boxes, I just want to get off > them, and have them work until I switch off them. Then don't update. It is an *optional* upgrade. It is not required. End of discussion. -- Eric Rostetter From jkeating at j2solutions.net Thu Jan 29 16:14:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 08:14:03 -0800 Subject: Calling rsync testers... In-Reply-To: References: Message-ID: <200401290814.04310.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 23:44, Jeffrey Berube wrote: > This may seem like a stupid question, and it may have already been > answered and I just missed it, but why are there non-i386 packages in > the i386 directory? Such as: > > redhat/8.0/updates/i386/kernel-uml-2.4.18-19.8.0.i686.rpm Because we aren't using the idiotic method of splitting sub-arch packages up like Red Hat did with the Red Hat Linux project, but fixed with Fedora. We seperate by base arch, where i386 is a base arch, x86_64 is a base arch, sparc is a base arch... i586, i686, athlon, these are all subarches of i386 and thus should reside in the same folder, as RPM, and all your other package management tools are capable of sorting them out. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGTFL4v2HLvE71NURAm/6AKCI71SASIicAgpiVQy+MnUQA7dyZQCfWLIu NOui5wmuT4rJH0C/99We5tU= =uaWV -----END PGP SIGNATURE----- From pekkas at netcore.fi Thu Jan 29 16:14:52 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 29 Jan 2004 18:14:52 +0200 (EET) Subject: Calling rsync testers... In-Reply-To: <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: On Thu, 29 Jan 2004, Charles R. Anderson wrote: > On Thu, Jan 29, 2004 at 11:57:32AM +0200, Pekka Savola wrote: > > OK, we've mirrored the whole tree, using hard-linking, but only Red > > How did you do this? > > I've tried pre-hardlinking my Red Hat mirror to the fedora legacy tree > (following http://www.fedora.us/wiki/FedoraMirrorHOWTO), but every > time I start rsync, it un-hardlinks the files and redownloads them. I > moved the linked files to the single i386 and SRPMS directories for > legacy, and the dates, times, and file sizes match. The contents are > also identical. For example, these are commands I am using for 7.2 > updates: [...] Well, for me it worked just as simply locally hard-linking the files before running rsync: onedir# for i in /ftp/mirrors/..../RedHat/RPMS/*.rpm; do ln $i; done otherdir# for j in /ftp/mirrors/..../SRPMS/*.rpm; do ln $j; done dunno if it didn't work for you. -- 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 Thu Jan 29 16:15:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 08:15:52 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> Message-ID: <200401290815.52910.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 January 2004 08:09, Eric Rostetter wrote: > > If it works, don't touch it, even if it is slightly buggy. > > Doesn't work. More than slightly buggy. Ah but it does work perfectly fine if you use yum as a frontend to your rpm (which I had been doing w/out realizing that this avoided the lock bug. I thought that it was just a bunch of hype over the bug). Since yum interacts with an older library, these issues were avoided. Yum can install, upgrade, and remove (with deps) packages, so I hadn't touched the rpm command in a while. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGTG44v2HLvE71NURAp42AJ48tGmw6Y1EEGNdwwowowed5lDcoQCguND/ +khVUUEVJezJal2ZjGnNY+A= =E76v -----END PGP SIGNATURE----- From cra at WPI.EDU Thu Jan 29 16:27:13 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 29 Jan 2004 11:27:13 -0500 Subject: Calling rsync testers... In-Reply-To: <200401290808.53880.jkeating@j2solutions.net> References: <4018C1A0.80707@iki.fi> <20040129150508.GC15491@angus.ind.WPI.EDU> <200401290808.53880.jkeating@j2solutions.net> Message-ID: <20040129162713.GB9834@angus.ind.WPI.EDU> On Thu, Jan 29, 2004 at 08:08:52AM -0800, Jesse Keating wrote: > > site is hardlinked or not. If it is not IMO it should be. :-) > > Why should it be? I only have one copy of the content on the mirror > server, and it's in the directories you have access to. 7.2 and 7.3 updates are mostly the same. Hardlinking them saves tonnes of space. From tdiehl at rogueind.com Thu Jan 29 16:48:56 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 29 Jan 2004 11:48:56 -0500 (EST) Subject: Calling rsync testers... In-Reply-To: <200401290808.53880.jkeating@j2solutions.net> References: <4018C1A0.80707@iki.fi> <20040129150508.GC15491@angus.ind.WPI.EDU> <200401290808.53880.jkeating@j2solutions.net> Message-ID: On Thu, 29 Jan 2004, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 29 January 2004 08:06, Tom Diehl wrote: > > The problem is if the master site is not hard linked then your site will > > not be hard linked. That is what rsync does. If the master site is hard > > linked then using -H is the only way to preserve them, in spite of what > > the WIKI says. Since I do not mirror legacy I do not know if the master > > site is hardlinked or not. If it is not IMO it should be. :-) > > Why should it be? I only have one copy of the content on the mirror > server, and it's in the directories you have access to. Do you have 7.2, 7.3, 8.0, and 9 on the master?? If so hardlinking saves an enormous amount of space. Try running hardlink over the directory tree and see. Do you really think that all of the rpms in 7.2, 7.3 and 8.0 are unique?? I can tell you that for sure they are not. Even Red Hat uses hardlink. When they get too far behind with it the mirror admins complain because of the wasted space. Fortunately they are really good at keeping up. Keep in mind this only works if you run rsync with -H though. FWIW In Red Hat's how to setup a mirror doc (Or whatever it is called) they recommend running with -H. HTH, .............Tom From maillist at jasonlim.com Thu Jan 29 16:49:47 2004 From: maillist at jasonlim.com (Jason Lim) Date: Fri, 30 Jan 2004 00:49:47 +0800 Subject: yum and rpm updates for 8.0 References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> Message-ID: <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> > On Thursday 29 January 2004 08:09, Eric Rostetter wrote: > > > If it works, don't touch it, even if it is slightly buggy. > > > > Doesn't work. More than slightly buggy. > > Ah but it does work perfectly fine if you use yum as a frontend to your rpm > (which I had been doing w/out realizing that this avoided the lock bug. I > thought that it was just a bunch of hype over the bug). Since yum > interacts with an older library, these issues were avoided. Yum can > install, upgrade, and remove (with deps) packages, so I hadn't touched the > rpm command in a while. If that is the case (that yum 1.x works around whatever bug is in rpm) then isn't rolling yum 1.x the logical path, rather than issuing non-essential upgrades for rpm? I suppose some people will want to upgrade rpm anyway, and they should have the choice, but this choice should not be mandatory imho. From jkeating at j2solutions.net Thu Jan 29 17:06:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 09:06:50 -0800 Subject: Calling rsync testers... In-Reply-To: References: <4018C1A0.80707@iki.fi> <200401290808.53880.jkeating@j2solutions.net> Message-ID: <200401290906.56420.jkeating@j2solutions.net> On Thursday 29 January 2004 08:48, Tom Diehl wrote: > Do you have 7.2, 7.3, 8.0, and 9 on the master?? If so hardlinking > saves an enormous amount of space. Try running hardlink over the > directory tree and see. > > Do you really think that all of the rpms in 7.2, 7.3 and 8.0 are > unique?? I can tell you that for sure they are not. Even Red Hat uses > hardlink. When they get too far behind with it the mirror admins > complain because of the wasted space. Fortunately they are really > good at keeping up. I have 7.2-8.0 currently, no 9 yet. DO you have a method for 100% assurance that the files are exactly the same and to hardlink them, w/out doing sha1's of every single file trying to compare them etc, etc... Same names aren't nearly enough evidence. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Jan 29 17:07:43 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 09:07:43 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> Message-ID: <200401290907.43743.jkeating@j2solutions.net> On Thursday 29 January 2004 08:49, Jason Lim wrote: > If that is the case (that yum 1.x works around whatever bug is in > rpm) then isn't rolling yum 1.x the logical path, rather than issuing > non-essential upgrades for rpm? I suppose some people will want to > upgrade rpm anyway, and they should have the choice, but this choice > should not be mandatory imho. The choice never was going to be mandatory. It was an optional upgrade from the very beginning. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From cra at WPI.EDU Thu Jan 29 17:25:09 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 29 Jan 2004 12:25:09 -0500 Subject: Calling rsync testers... In-Reply-To: <200401290906.56420.jkeating@j2solutions.net> References: <4018C1A0.80707@iki.fi> <200401290808.53880.jkeating@j2solutions.net> <200401290906.56420.jkeating@j2solutions.net> Message-ID: <20040129172509.GC9834@angus.ind.WPI.EDU> On Thu, Jan 29, 2004 at 09:06:50AM -0800, Jesse Keating wrote: > DO you have a method for 100% assurance that the files are exactly the > same and to hardlink them, w/out doing sha1's of every single file > trying to compare them etc, etc... Same names aren't nearly enough > evidence. hardlink.c compares checksums and links identical files. The package is available in fedora.us. From cra at WPI.EDU Thu Jan 29 17:36:16 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 29 Jan 2004 12:36:16 -0500 Subject: Calling rsync testers... In-Reply-To: <20040129172509.GC9834@angus.ind.WPI.EDU> References: <4018C1A0.80707@iki.fi> <200401290808.53880.jkeating@j2solutions.net> <200401290906.56420.jkeating@j2solutions.net> <20040129172509.GC9834@angus.ind.WPI.EDU> Message-ID: <20040129173616.GD9834@angus.ind.WPI.EDU> On Thu, Jan 29, 2004 at 12:25:09PM -0500, Charles R. Anderson wrote: > On Thu, Jan 29, 2004 at 09:06:50AM -0800, Jesse Keating wrote: > > DO you have a method for 100% assurance that the files are exactly the > > same and to hardlink them, w/out doing sha1's of every single file > > trying to compare them etc, etc... Same names aren't nearly enough > > evidence. > > hardlink.c compares checksums and links identical files. The package > is available in fedora.us. Additionally, this program is "endorsed" by Red Hat for use by mirrors, as suggested by this: Source0: ftp://ftp.redhat.com/pub/redhat/mirror-tools/hardlink.c * Sun Jun 30 2002 Andrew Anderson - Initial build From drees at greenhydrant.com Thu Jan 29 17:52:41 2004 From: drees at greenhydrant.com (David Rees) Date: Thu, 29 Jan 2004 09:52:41 -0800 Subject: Calling rsync testers... In-Reply-To: References: Message-ID: <40194869.4040108@greenhydrant.com> Pekka Savola wrote, On 1/29/2004 8:14 AM: > > Well, for me it worked just as simply locally hard-linking the files > before running rsync: > > onedir# for i in /ftp/mirrors/..../RedHat/RPMS/*.rpm; do ln $i; done > otherdir# for j in /ftp/mirrors/..../SRPMS/*.rpm; do ln $j; done > > dunno if it didn't work for you. This worked for me, too. -Dave From tdiehl at rogueind.com Thu Jan 29 18:02:59 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 29 Jan 2004 13:02:59 -0500 (EST) Subject: Calling rsync testers... In-Reply-To: <200401290906.56420.jkeating@j2solutions.net> References: <4018C1A0.80707@iki.fi> <200401290808.53880.jkeating@j2solutions.net> <200401290906.56420.jkeating@j2solutions.net> Message-ID: On Thu, 29 Jan 2004, Jesse Keating wrote: > On Thursday 29 January 2004 08:48, Tom Diehl wrote: > > Do you have 7.2, 7.3, 8.0, and 9 on the master?? If so hardlinking > > saves an enormous amount of space. Try running hardlink over the > > directory tree and see. > > > > Do you really think that all of the rpms in 7.2, 7.3 and 8.0 are > > unique?? I can tell you that for sure they are not. Even Red Hat uses > > hardlink. When they get too far behind with it the mirror admins > > complain because of the wasted space. Fortunately they are really > > good at keeping up. > > I have 7.2-8.0 currently, no 9 yet. > > DO you have a method for 100% assurance that the files are exactly the > same and to hardlink them, w/out doing sha1's of every single file > trying to compare them etc, etc... Same names aren't nearly enough > evidence. I would suggest using the hardlink program. It can be found on: path_to_your_favorite_redhat_mirror/redhat/mirror-tools/hardlink-1.2-1.i386.rpm HTH, .Tom From admin at cs.montana.edu Thu Jan 29 18:09:09 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 29 Jan 2004 11:09:09 -0700 (MST) Subject: Calling rsync testers... In-Reply-To: <40194869.4040108@greenhydrant.com> References: <40194869.4040108@greenhydrant.com> Message-ID: <1191.153.90.196.33.1075399749.squirrel@webtest.cs.montana.edu> If I need to run hardlink on a rsync, then what are the complete steps, I need to do? David Rees said: > Pekka Savola wrote, On 1/29/2004 8:14 AM: >> >> Well, for me it worked just as simply locally hard-linking the files >> before running rsync: >> >> onedir# for i in /ftp/mirrors/..../RedHat/RPMS/*.rpm; do ln $i; done >> otherdir# for j in /ftp/mirrors/..../SRPMS/*.rpm; do ln $j; done >> -- Luke Computer Science System Administrator From chuckw at quantumlinux.com Thu Jan 29 18:09:23 2004 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 29 Jan 2004 10:09:23 -0800 (PST) Subject: Calling rsync testers... In-Reply-To: <20040129143345.GA15491@angus.ind.WPI.EDU> References: <4018C1A0.80707@iki.fi> <20040129143345.GA15491@angus.ind.WPI.EDU> Message-ID: > I've tried pre-hardlinking my Red Hat mirror to the fedora legacy tree > (following http://www.fedora.us/wiki/FedoraMirrorHOWTO), but every time > I start rsync, it un-hardlinks the files and redownloads them. I moved > the linked files to the single i386 and SRPMS directories for legacy, > and the dates, times, and file sizes match. The contents are also > identical. For example, these are commands I am using for 7.2 updates: Try looking for the --link-dest flag in the rsync man page. That might fix what ails you. -Chuck -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR From admin at cs.montana.edu Thu Jan 29 18:18:20 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 29 Jan 2004 11:18:20 -0700 (MST) Subject: yum and rpm updates for 8.0 In-Reply-To: <401878FF.2040107@togami.com> References: <20040126184609.GE21263@psilocybe.teonanacatl.org><200401280948.17298.jkeating@j2solutions.net><01cc01c3e5cc$c763ee50$0900a8c0@SYSTEM9><200401281038.50456.jkeating@j2solutions.net><1075330286.4255.37.camel@chip.laiskiainen.org> <20040128192937.mn2elck4c084oc8c@mail.ph.utexas.edu> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <401878FF.2040107@togami.com> Message-ID: <1253.153.90.196.33.1075400300.squirrel@webtest.cs.montana.edu> Warren, I was not suggesting that was the policy. I was aware that the rpm update was optional. I was just reiterating my agreement with the policy. On redhat 9/FC1 I have upgraded all the packages from the fedora.us patches update. Have not experienced any problems. --Luke Warren Togami said: > Lucas Albers wrote: >> If it works, don't touch it, even if it is slightly buggy. >> Change bad. >> I don't want to change anything on my 7.3 boxes, I just want to get off >> them, and have them work until I switch off them. >> > > Nobody ever suggested upgrading rpm on 7.x. RH8 is the very broken one. > RH9 is the somewhat broken one. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From jkeating at j2solutions.net Thu Jan 29 18:30:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 10:30:33 -0800 Subject: Mirror change... Message-ID: <200401291030.37921.jkeating@j2solutions.net> I'm going to run hardlink on the mirror and try to save some space/bandwidth. People that are currently syncing to me will most likely have to resync. I'm sorry for this, but it needs to be done, and I'd rather do it now then at night when a lot of people have scripts to sync. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From admin at cs.montana.edu Thu Jan 29 18:46:23 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 29 Jan 2004 11:46:23 -0700 (MST) Subject: Calling rsync testers... In-Reply-To: <1191.153.90.196.33.1075399749.squirrel@webtest.cs.montana.edu> References: <40194869.4040108@greenhydrant.com> <1191.153.90.196.33.1075399749.squirrel@webtest.cs.montana.edu> Message-ID: <1380.153.90.196.33.1075401983.squirrel@webtest.cs.montana.edu> I am currently rsyncing correctly. Anyone who wants to sync to my mirror, please contact me. I cannot currently provide a fully public mirror, but can provide rsync access for edu sites. I currently have these repositories: 7.3,8,9,FC1 Fedora.us, excluding yum and all testing, includes patches. 7.3,8, Fedora Legacy, excluding SRPMS, and yum. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From jkeating at j2solutions.net Thu Jan 29 18:52:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 10:52:10 -0800 Subject: Press items Message-ID: <200401291052.10791.jkeating@j2solutions.net> We've been spotted! http://www.internetnews.com/dev-news/article.php/3305251 -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From dawson at fnal.gov Thu Jan 29 19:25:15 2004 From: dawson at fnal.gov (Troy Dawson) Date: Thu, 29 Jan 2004 13:25:15 -0600 Subject: Mirror change... In-Reply-To: <200401291030.37921.jkeating@j2solutions.net> References: <200401291030.37921.jkeating@j2solutions.net> Message-ID: <40195E1B.9060403@fnal.gov> Jesse Keating wrote: > I'm going to run hardlink on the mirror and try to save some > space/bandwidth. > > People that are currently syncing to me will most likely have to resync. > I'm sorry for this, but it needs to be done, and I'd rather do it now > then at night when a lot of people have scripts to sync. > Let us know when you're ready. I just got permission to be an official mirror. WooHoo! Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From jkeating at j2solutions.net Thu Jan 29 19:27:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 11:27:42 -0800 Subject: Mirror change... In-Reply-To: <40195E1B.9060403@fnal.gov> References: <200401291030.37921.jkeating@j2solutions.net> <40195E1B.9060403@fnal.gov> Message-ID: <200401291127.42116.jkeating@j2solutions.net> On Thursday 29 January 2004 11:25, Troy Dawson wrote: > Let us know when you're ready. > I just got permission to be an official mirror. WooHoo! > Troy It's all ready. Be sure to use the -H with rsync to preserve the hardlinks. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From SNielsen at comscore.com Thu Jan 29 19:31:07 2004 From: SNielsen at comscore.com (Nielsen, Steve) Date: Thu, 29 Jan 2004 14:31:07 -0500 Subject: Mirror change... Message-ID: <66E9FEE99E96034ABB4DE197A927DBF1D17E4E@csiadmail01.office.comscore.com> Just curious... what command did you use to setup the repos? I saw all previous posts already. Just curious what you did (i.e. did you start with 7.2 then do 7.3... did you use rsync or hardlink) Thanks, Steve -----Original Message----- From: Jesse Keating [mailto:jkeating at j2solutions.net] Sent: Thursday, January 29, 2004 1:28 PM To: fedora-legacy-list at redhat.com Subject: Re: Mirror change... On Thursday 29 January 2004 11:25, Troy Dawson wrote: > Let us know when you're ready. > I just got permission to be an official mirror. WooHoo! > Troy It's all ready. Be sure to use the -H with rsync to preserve the hardlinks. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Thu Jan 29 19:34:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 11:34:18 -0800 Subject: Calling all Mirror Admins Message-ID: <200401291134.22805.jkeating@j2solutions.net> Ok, I think we're finally ready to start setting up some mirrors. If you'd like to be an official mirror of the Fedora Legacy project, please reply to mirrors at fedoralegacy.org with your contact info, and what portion of our tree you're willing to mirror, your location, your times of operation, and what protocols you'll be offering to end users. I'll be compiling a list and posting it on our website when it's ready and everybody is synced up. Thanks! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Thu Jan 29 19:36:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 11:36:30 -0800 Subject: Mirror change... In-Reply-To: <66E9FEE99E96034ABB4DE197A927DBF1D17E4E@csiadmail01.office.comscore.com> References: <66E9FEE99E96034ABB4DE197A927DBF1D17E4E@csiadmail01.office.comscore.com> Message-ID: <200401291136.30424.jkeating@j2solutions.net> On Thursday 29 January 2004 11:31, Nielsen, Steve wrote: > Just curious... what command did you use to setup the repos? I saw > all previous posts already. Just curious what you did (i.e. did you > start with 7.2 then do 7.3... did you use rsync or hardlink) It was a lot of manual processes. I mostly used lftp against various mirrors of Red Hat out on the 'net to bring down content from the i386 i586, i686, athlon, noarch stuff into the same folders, for OS and for updates, for each release. Then it's just a matter of running some scripts on it for yum and apt. Later, after some coaching from list members, I used hardlink to sift through the directory tree and create links where links were needed. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From brooks at netgate.net Thu Jan 29 19:57:30 2004 From: brooks at netgate.net (Kevin Brooks) Date: Thu, 29 Jan 2004 11:57:30 -0800 (PST) Subject: Calling all Mirror Admins In-Reply-To: <200401291134.22805.jkeating@j2solutions.net> References: <200401291134.22805.jkeating@j2solutions.net> Message-ID: On Thu, 29 Jan 2004, Jesse Keating wrote: > Ok, I think we're finally ready to start setting up some mirrors. If > you'd like to be an official mirror of the Fedora Legacy project, > please reply to mirrors at fedoralegacy.org with your contact info, and > what portion of our tree you're willing to mirror, your location, your > times of operation, and what protocols you'll be offering to end users. > I'll be compiling a list and posting it on our website when it's ready > and everybody is synced up. Any idea how much data are we talking about in each branch? Thanks, Kevin From jkeating at j2solutions.net Thu Jan 29 20:02:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 12:02:51 -0800 Subject: Calling all Mirror Admins In-Reply-To: References: <200401291134.22805.jkeating@j2solutions.net> Message-ID: <200401291202.51714.jkeating@j2solutions.net> On Thursday 29 January 2004 11:57, Kevin Brooks wrote: > Any idea how much data are we talking about in each branch? 4.0G ./7.2 3.6G ./7.3 4.5G ./8.0 12G . Not sure if du is picking up on the hardlinks or not, or just counting them twice. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From tdiehl at rogueind.com Thu Jan 29 20:36:02 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 29 Jan 2004 15:36:02 -0500 (EST) Subject: Calling all Mirror Admins In-Reply-To: <200401291202.51714.jkeating@j2solutions.net> References: <200401291134.22805.jkeating@j2solutions.net> <200401291202.51714.jkeating@j2solutions.net> Message-ID: On Thu, 29 Jan 2004, Jesse Keating wrote: > On Thursday 29 January 2004 11:57, Kevin Brooks wrote: > > Any idea how much data are we talking about in each branch? > > 4.0G ./7.2 > 3.6G ./7.3 > 4.5G ./8.0 > 12G . > > Not sure if du is picking up on the hardlinks or not, or just counting > them twice. IIRC, du is smart enough not to count them twice. Tom From mattdm at mattdm.org Thu Jan 29 21:03:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 29 Jan 2004 16:03:53 -0500 Subject: Calling all Mirror Admins In-Reply-To: References: <200401291134.22805.jkeating@j2solutions.net> <200401291202.51714.jkeating@j2solutions.net> Message-ID: <20040129210353.GA27451@jadzia.bu.edu> On Thu, Jan 29, 2004 at 03:36:02PM -0500, Tom Diehl wrote: > > Not sure if du is picking up on the hardlinks or not, or just counting > > them twice. > IIRC, du is smart enough not to count them twice. Yes, unless you give it '-l'. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Thu Jan 29 21:38:11 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 29 Jan 2004 15:38:11 -0600 Subject: yum and rpm updates for 8.0 In-Reply-To: <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> Message-ID: <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> Quoting Jason Lim : > If that is the case (that yum 1.x works around whatever bug is in rpm) > then isn't rolling yum 1.x the logical path, rather than issuing > non-essential upgrades for rpm? Uhm, so forcing them to install *new* software is okay, but forcing them to install a fix for *broken* software they already have installed isn't? Or, forcing them to install and learn yum is okay, but letting them use the software they already know how to us and already have installed (apt, rpm, etc) is wrong? > I suppose some people will want to upgrade > rpm anyway, and they should have the choice, but this choice should not be > mandatory imho. It isn't. It is optional, and only for RH 8/9, not for RH 7.x. End of discussion (didn't I already say that???) -- Eric Rostetter From skvidal at phy.duke.edu Thu Jan 29 21:35:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Jan 2004 16:35:36 -0500 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> Message-ID: <1075412135.30589.233.camel@binkley> On Thu, 2004-01-29 at 16:38, Eric Rostetter wrote: > Quoting Jason Lim : > > > If that is the case (that yum 1.x works around whatever bug is in rpm) > > then isn't rolling yum 1.x the logical path, rather than issuing > > non-essential upgrades for rpm? > > Uhm, so forcing them to install *new* software is okay, but forcing them > to install a fix for *broken* software they already have installed isn't? > > Or, forcing them to install and learn yum is okay, but letting them use > the software they already know how to us and already have installed > (apt, rpm, etc) is wrong? Well, some of us have been using yum all along :) -sv From jkeating at j2solutions.net Thu Jan 29 21:42:27 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 13:42:27 -0800 Subject: yum and rpm updates for 8.0 In-Reply-To: <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> Message-ID: <200401291342.32002.jkeating@j2solutions.net> On Thursday 29 January 2004 13:38, Eric Rostetter wrote: > Uhm, so forcing them to install *new* software is okay, but forcing > them to install a fix for *broken* software they already have > installed isn't? There are a lot of folk who are ALREADY using yum, and this this is nothing new for them. > Or, forcing them to install and learn yum is okay, but letting them > use the software they already know how to us and already have > installed (apt, rpm, etc) is wrong? Perhaps a better doc for the rpm upgrade should go like: "If you are using yum for most/all of your package manager needs, then upgrading rpm is unnecessary for you as yum does not trigger the problems. If you use apt or rpm directly for most of your work, upgrading to this release of rpm will limit the amount of problems you have." -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From whooperhsd3 at earthlink.net Fri Jan 30 00:42:23 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Thu, 29 Jan 2004 19:42:23 -0500 (EST) Subject: yum and rpm updates for 8.0 In-Reply-To: <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> Message-ID: <64664.65.40.133.19.1075423343.squirrel@65.40.133.19> Eric Rostetter said: > > It isn't. It is optional, and only for RH 8/9, not for RH 7.x. > > End of discussion (didn't I already say that???) Please jump in if I'm confused on something: The (optional) RPM upgrade for RH 8 would reequire upgrading to Yum 2.x. I believe that yum 1.x and 2.x can use the same repos, so that's OK. Now, does everyone want to support yum 1.x for the RH 8 people that don't upgrade and yum 2.x for the people that do? -- William Hooper From maillist at jasonlim.com Fri Jan 30 01:11:58 2004 From: maillist at jasonlim.com (Jason Lim) Date: Fri, 30 Jan 2004 09:11:58 +0800 Subject: yum and rpm updates for 8.0 References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> <64664.65.40.133.19.1075423343.squirrel@65.40.133.19> Message-ID: <000f01c3e6ce$635433e0$0900a8c0@SYSTEM9> > > The (optional) RPM upgrade for RH 8 would reequire upgrading to Yum 2.x. > I believe that yum 1.x and 2.x can use the same repos, so that's OK. Now, > does everyone want to support yum 1.x for the RH 8 people that don't > upgrade and yum 2.x for the people that do? > Or alternatively, I do assume yum 1.x will run on the upgraded rpm too, right? So if you're looking to cut down on maintanence of packages and make the life of the maintainers a bit easier, then it would make sense to just have the 1 yum... yum 1.x... which runs on the original rpm and the upgrade rpm regardless, and which runs on 7.x too? From skvidal at phy.duke.edu Fri Jan 30 01:40:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Jan 2004 20:40:50 -0500 Subject: yum and rpm updates for 8.0 In-Reply-To: <000f01c3e6ce$635433e0$0900a8c0@SYSTEM9> References: <20040126184609.GE21263@psilocybe.teonanacatl.org> <33044.216.166.133.165.1075345078.squirrel@webtest.cs.montana.edu> <20040129100905.buv0xq840k8cc44w@mail.ph.utexas.edu> <200401290815.52910.jkeating@j2solutions.net> <030301c3e687$e7fa7470$0900a8c0@SYSTEM9> <20040129153811.fkm1o8gs4sg80s0k@mail.ph.utexas.edu> <64664.65.40.133.19.1075423343.squirrel@65.40.133.19> <000f01c3e6ce$635433e0$0900a8c0@SYSTEM9> Message-ID: <1075426849.2343.2.camel@binkley> On Thu, 2004-01-29 at 20:11, Jason Lim wrote: > > > > The (optional) RPM upgrade for RH 8 would reequire upgrading to Yum 2.x. > > I believe that yum 1.x and 2.x can use the same repos, so that's OK. > Now, > > does everyone want to support yum 1.x for the RH 8 people that don't > > upgrade and yum 2.x for the people that do? > > > > Or alternatively, I do assume yum 1.x will run on the upgraded rpm too, > right? no it won't. yum 1.x and rpm 4.1.1+ won't get along. -sv From rostetter at mail.utexas.edu Fri Jan 30 01:47:12 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 29 Jan 2004 19:47:12 -0600 Subject: web site updates In-Reply-To: <400E5249.3000403@togami.com> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> <200401202204.32436.jkeating@j2solutions.net> <400E5249.3000403@togami.com> Message-ID: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> Just an FYI, there have neen numerous updates to the web site lately, so if you haven't checked it out for a while you might want to do so now. Extra thanks to Jonas Pasche for his work on the Participation, FAQ, and Documentation pages (keep it coming Jonas!). Comments, suggestions, and content always welcome (sent to me or the mailing list). Great to see this project coming along (updates and advisories published, mirrors coming on-line, web site coming along, interest growing...) -- Eric Rostetter From Freedom_Lover at pobox.com Fri Jan 30 02:14:59 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 29 Jan 2004 21:14:59 -0500 Subject: i586 kernel updates missing (was: Mirror change...) In-Reply-To: <200401291136.30424.jkeating@j2solutions.net> References: <66E9FEE99E96034ABB4DE197A927DBF1D17E4E@csiadmail01.office.comscore.com> <200401291136.30424.jkeating@j2solutions.net> Message-ID: <20040130021459.GF21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > I mostly used lftp against various mirrors of Red Hat out on the > 'net to bring down content from the i386 i586, i686, athlon, noarch > stuff into the same folders, for OS and for updates, for each > release. I just ran into this on an older box I was updating. It's got an i586 kernel package installed and yum would not see any updates for it (after I commented out the exclude=kernel* in yum.conf, of course). Looking on the download server, there are no kernel*.i586 rpms. Are those not included intentionally or by accident? I don't know how many folks will miss them. I just happened to find this out when I was testing an old box. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Life is the art of drawing sufficient conclusions from insignificant premises -- Samuel Butler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGb4juv+09NZUB1oRApxZAKCbecog6TcwwtFU7m0Fe7cqBUURvACeNHt7 kf1k/1jBa2AM9IbX9xuFT74= =ECHI -----END PGP SIGNATURE----- From mail at jonaspasche.de Fri Jan 30 02:27:20 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 30 Jan 2004 03:27:20 +0100 Subject: web site updates In-Reply-To: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> References: <20040121055118.GL13633@psilocybe.teonanacatl.org> <200401202204.32436.jkeating@j2solutions.net> <400E5249.3000403@togami.com> <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> Message-ID: <1075429640.26808.151.camel@leonardo> Hi Eric, > Just an FYI, there have neen numerous updates to the web site lately, > so if you haven't checked it out for a while you might want to do so now. Good work, Eric! Thanks for putting all the stuff online. Additionally, thanks for reviewing and completing the "Participation" section, which I hadn't ready for publication yet, but I'm glad to see you finished the missing parts. I've been very busy with my regular job for the last week, but I hope I'll be able to finish the end-user documentation for 8.0 this weekend, as I see that the yum1/yum2/rpm41optional/rpm41required discussion has been mainly finished. All Fedora Legacy participants, keep on rocking! Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Freedom_Lover at pobox.com Fri Jan 30 03:30:13 2004 From: Freedom_Lover at pobox.com (Todd) Date: Thu, 29 Jan 2004 22:30:13 -0500 Subject: web site updates In-Reply-To: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> Message-ID: <20040130033013.GG21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rostetter wrote: > Just an FYI, there have neen numerous updates to the web site > lately, so if you haven't checked it out for a while you might want > to do so now. Very good work to all the folks who've helped create all the content. I have a suggestion that might help defer some questions when people start using yum. This would go on the documentation page for using yum with 7.x[1] Somewhere between Step 1. Install yum and Step 2. Update the packages, there should be instructions to either add the Fedora Legacy and Red Hat RPM GPG keys to root's keyring or to disable the gpgcheck option in yum.conf. Otherwise, the user will get an error when they run yum update and will end up here asking questions or looking elsewhere for their updates. The instructions should be pretty simple, here's a stab at them. I'd put this in Step 1 along with installing yum, unless you web writers feel it should be its own separate step. ====================================================================== Add the GPG keys used to sign packages to root's keyring. These keys are installed with the yum documentation. # gpg --import /usr/share/doc/yum-1.0.3/*GPG-KEY Note: If you've never used gpg before as root, you will need to run the command again so that gpg can read it's newly created options file. You may also want to verify that the GPG fingerprints of these keys match those that are published by each vendor. Red Hat: https://www.redhat.com/security/keys.html Fedora: ??? Fedora Legacy: http://www.fedoralegacy.org/about/security.php ====================================================================== Of these keys, only the Red Hat site has the key fingerprints included on the website. I think that Fedora Legacy should add this info to the page cited above. I'm also curious about the Fedora.us key. It's included in the yum rpm, but AFAIK, none of the packages distributed by Fedora Legacy are signed by the Fedora.us key. Is it worth it to even distribute that key? It might just confuse a new user. Anyone that's looking to also get content from fedora.us should know how to add that key anyway. It is listed right on the fedora.us home page, so it's not hard to locate. Though again, I don't see the key fingerprint on the site. [1] http://www.fedoralegacy.org/docs/yum-rh7x.php - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Eagles may soar, but weasels don't get sucked into jet engines -- Steven Wright -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGc/Fuv+09NZUB1oRAkz2AJ98hUm93TjlokjbnnF515/2pYKmiwCg3f3Z ikA8Rlu9/F/2cWCP1eWHlIY= =Wu0W -----END PGP SIGNATURE----- From michal at harddata.com Fri Jan 30 03:38:25 2004 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 29 Jan 2004 20:38:25 -0700 Subject: A bit of mess in http://download.fedoralegacy.org/redhat/7.3/updates/ Message-ID: <20040129203825.A11142@mail.harddata.com> I had a closer look at http://download.fedoralegacy.org/redhat/7.3/updates/ and I found that in SRPMS directory there are cvs-1.11.1p1-8.7.src.rpm 16-Jan-2003 22:19 2.6M cvs-1.11.1p1-9.7.legacy.src.rpm 24-Jan-2004 00:54 2.6M kernel-2.4.18-27.7.x.src.rpm 14-Mar-2003 15:20 33.7M kernel-2.4.20-28.7.src.rpm 24-Dec-2003 11:23 33.0M tcpdump-3.6.3-17.7.3.2.src.rpm 21-Apr-2003 13:03 785k tcpdump-3.6.3-17.7.3.3.src.rpm 13-May-2003 15:58 785k In binaries there is only 'kernel-debug-2.4.18-27.7.x.i686.rpm' from '2.4.18-27.7.x' series but, possibly to make up for it, 'kernel-2.4.20-28.7.i586.rpm' and 'kernel-smp-2.4.20-28.7.i586.rpm' are gone. Binaries for cvs are also doubled but not for tcpdump. That is so far everything I noticed and I did not check directories for distributions other than 7.3. Michal From sheltren at cs.ucsb.edu Fri Jan 30 04:47:58 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 29 Jan 2004 20:47:58 -0800 Subject: FL Website Message-ID: <1075438078.4015.4.camel@avalanche> The website is looking great - thanks for all the hard work! I was browsing through it and noticed a typo on http://www.fedoralegacy.org/participate/ ---------- Don't overestimate yourself ? even if you think that you can only a little thing for us, it's better to focus on that one thing and do it well ---------- I think that should read: "even if you think that you can only do a little thing for us" -Jeff From jkeating at j2solutions.net Fri Jan 30 06:27:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 29 Jan 2004 22:27:16 -0800 Subject: A bit of mess in http://download.fedoralegacy.org/redhat/7.3/updates/ In-Reply-To: <20040129203825.A11142@mail.harddata.com> References: <20040129203825.A11142@mail.harddata.com> Message-ID: <200401292227.22300.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 January 2004 19:38, Michal Jaegermann wrote: > I had a closer look at > http://download.fedoralegacy.org/redhat/7.3/updates/ > and I found that in SRPMS directory there are > > cvs-1.11.1p1-8.7.src.rpm 16-Jan-2003 22:19 2.6M > cvs-1.11.1p1-9.7.legacy.src.rpm 24-Jan-2004 00:54 2.6M > > kernel-2.4.18-27.7.x.src.rpm 14-Mar-2003 15:20 33.7M > kernel-2.4.20-28.7.src.rpm 24-Dec-2003 11:23 33.0M > > tcpdump-3.6.3-17.7.3.2.src.rpm 21-Apr-2003 13:03 785k > tcpdump-3.6.3-17.7.3.3.src.rpm 13-May-2003 15:58 785k > > In binaries there is only 'kernel-debug-2.4.18-27.7.x.i686.rpm' > from '2.4.18-27.7.x' series but, possibly to make up for it, > 'kernel-2.4.20-28.7.i586.rpm' and 'kernel-smp-2.4.20-28.7.i586.rpm' > are gone. Binaries for cvs are also doubled but not for tcpdump. > > That is so far everything I noticed and I did not check directories > for distributions other than 7.3. I have in there just what was on other servers. The i586 didn't get pulled down by my script for some reason, but it's there now. I wouldn't worry about missing files for the older versions, just as long as the latest version of the SRPM has the right binary in i386/ - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAGflJ4v2HLvE71NURAor2AJ4zq4dmrZAwT3xkSnMaU7uB/V104QCfU3MT frTKCgSPM1HywjxvR34tTsE= =PLTT -----END PGP SIGNATURE----- From tatooin at kelkoo.com Fri Jan 30 11:35:35 2004 From: tatooin at kelkoo.com (Vincent Jaussaud) Date: Fri, 30 Jan 2004 12:35:35 +0100 Subject: Calling all Mirror Admins Message-ID: <1075462534.31912.223.camel@tatooin.kelkoo.net> Hi there; We could setup an official fedoralegacy mirror in Amsterdam, Netherland, on our mirror farm (see http://gnu.kookel.org) , hosted through a dedicated 10 Mb/s line. We can provide both FTP & HTTP public access; while rsync access isn't setup, we can do that extra work if needed. Please let us know the details. We are also considering to help the fedoralegacy project in any other way we can, although we don't exactly know how yet. Thanks to all of you for providing this to the community. Regards, -- Vincent Jaussaud Kelkoo.com Security Manager email: tatooin at kelkoo.com "Those who desire to give up freedom in order to gain security will not have, nor do they deserve, either one." -- President Thomas Jefferson. 1743-1826 From mail at jonaspasche.de Fri Jan 30 12:56:03 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 30 Jan 2004 13:56:03 +0100 Subject: web site updates In-Reply-To: <20040130033013.GG21263@psilocybe.teonanacatl.org> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130033013.GG21263@psilocybe.teonanacatl.org> Message-ID: <1075467363.4769.90.camel@leonardo> Hi Todd, > Somewhere between Step 1. Install yum and Step 2. Update the packages, > there should be instructions to either add the Fedora Legacy and Red > Hat RPM GPG keys to root's keyring or to disable the gpgcheck option > in yum.conf. If all packages are signed, I wouldn't suggest turning off a security feature. Importing the GPG key would be a much better option. Thanks for that hint! Eric, what's your opinion - from my point of view the docs suggestion that Todd has written is already fine and can be published 1:1. > Of these keys, only the Red Hat site has the key fingerprints included > on the website. I think that Fedora Legacy should add this info to > the page cited above. +1 > I'm also curious about the Fedora.us key. It's included in the yum > rpm, but AFAIK, none of the packages distributed by Fedora Legacy are > signed by the Fedora.us key. Is it worth it to even distribute that > key? I don't think so. The fedora.us key is only used to sign add-on packages for 8.0/9/FC1, afaik. As fedora.us has never released any add-on packages for 7.x, including the key here doesn't make sense. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mail at jonaspasche.de Fri Jan 30 13:33:25 2004 From: mail at jonaspasche.de (Jonas Pasche) Date: Fri, 30 Jan 2004 14:33:25 +0100 Subject: yum dependencies on 7.x Message-ID: <1075469605.4769.129.camel@leonardo> Hi all, I fear I have left out an important point on the 7.x instructions: Does the system meet all of yum's requirements? I'm not sure if the rpm-python package is installed by default in all setups. I guess gnupg is, but the user may have erased it for some unknown reason. So before installing yum we should include a section like "Preparing your system", for which I have the following suggestion: --- cut here --- 0. Prepare your system [or "1.", and renumber the following steps] Besides rpm itself, yum depends on the gnupg, python and rpm-python packages. Please check if all the packages are available through executing as root: rpm -q gnupg python rpm rpm-python rpm will output the package versions, or "...is not installed" if you're missing any of these packages. If all packages are installed, just continue with step 1 [or 2 when renumbering]. If you're missing packages, you have to install them before you can proceed. Red Hat Linux 7.2: Are you missing rpm-python, but still running rpm 4.0.3? Then please upgrade your rpm package first (if you already have rpm-python and just need gnupg and/or python, you can simply skip this step; later yum will automatically care for possibly needed updates): rpm -Uvh http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-4.0.4-7x.i386.rpm Now install any of these packages that you're missing: rpm -ivh http://download.fedoralegacy.org/redhat/7.2/updates/i386/gnupg-1.0.7-13.i386.rpm rpm -ivh http://download.fedoralegacy.org/redhat/7.2/updates/i386/python-1.5.2-43.72.i386.rpm rpm -ivh http://download.fedoralegacy.org/redhat/7.2/updates/i386/rpm-python-4.0.4-7x.i386.rpm Red Hat Linux 7.3: Install any of these packages that you're missing: rpm -ivh http://download.fedoralegacy.org/redhat/7.3/updates/i386/gnupg-1.0.7-13.i386.rpm rpm -ivh http://download.fedoralegacy.org/redhat/7.3/updates/i386/python-1.5.2-43.73.i386.rpm rpm -ivh http://download.fedoralegacy.org/redhat/7.3/os/i386/rpm-python-4.0.4-7x.18.i386.rpm Doesn't that look like a mess? Don't worry, this should have been the last time you did this manually. yum will automatically retrieve and install the newest packages with all dependencies with a single call. --- cut here --- Feedback is welcome... Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michal at harddata.com Fri Jan 30 16:01:36 2004 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 30 Jan 2004 09:01:36 -0700 Subject: A bit of mess in http://download.fedoralegacy.org/redhat/7.3/updates/ In-Reply-To: <200401292227.22300.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Thu, Jan 29, 2004 at 10:27:16PM -0800 References: <20040129203825.A11142@mail.harddata.com> <200401292227.22300.jkeating@j2solutions.net> Message-ID: <20040130090136.A22144@mail.harddata.com> On Thu, Jan 29, 2004 at 10:27:16PM -0800, Jesse Keating wrote: > I wouldn't worry > about missing files for the older versions, just as long as the latest > version of the SRPM has the right binary in i386/ Worry was more about extra files for old and obsolete versions although both cases will make a mess in a local repository if one will do rsync. Michal From rostetter at mail.utexas.edu Fri Jan 30 17:06:36 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 30 Jan 2004 11:06:36 -0600 Subject: Update Announcement Format discussion In-Reply-To: <3FFE6961.90008@togami.com> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> Message-ID: <20040130110636.etj35n6s80sgo4og@mail.ph.utexas.edu> Quoting Warren Togami : > Okay, it seems that everyone is opposed to the removal or crippling of > mpg321. We should go ahead with our first security update announcement. This never happened. I'm reposting this to the list to remind people (raise awareness) that this was never handled... > After we agree upon that template, then the draft for the mpg321 > no-package Legacy security advisory must be written advising users about > the license issue preventing update, and suggestion to remove mpg321. This sounds good to me. Anyone up to the task? -- Eric Rostetter From jkeating at j2solutions.net Fri Jan 30 17:11:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Jan 2004 09:11:37 -0800 Subject: Update Announcement Format discussion In-Reply-To: <20040130110636.etj35n6s80sgo4og@mail.ph.utexas.edu> References: <3FFE1A93.8090100@togami.com> <3FFE6961.90008@togami.com> <20040130110636.etj35n6s80sgo4og@mail.ph.utexas.edu> Message-ID: <200401300911.41970.jkeating@j2solutions.net> On Friday 30 January 2004 09:06, Eric Rostetter wrote: > > After we agree upon that template, then the draft for the mpg321 > > no-package Legacy security advisory must be written advising users > > about the license issue preventing update, and suggestion to remove > > mpg321. > > This sounds good to me. Anyone up to the task? I'm adding this to my to-do list for this weekend. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From eric.rostetter at physics.utexas.edu Fri Jan 30 17:28:44 2004 From: eric.rostetter at physics.utexas.edu (Eric Rostetter) Date: Fri, 30 Jan 2004 11:28:44 -0600 Subject: FWD: RPM submission procedure (fwd) Message-ID: <20040130112844.i4904n404wswscoc@mail.ph.utexas.edu> I'm forwarding this from the caos mailing list, just in case anyone is interested in this "shipper" project idea... Don't know anything about it, or if it would be of interest to FL, but thought I'd post it in case it is of interest... Most of the message is edited out (via a [...] cut); just the interesting part is left. Eric ---------- Forwarded message ---------- Date: Sat, 10 Jan 2004 05:36:42 -0500 From: Eric S. Raymond To: R P Herrold Cc: cAos mailing list Subject: Re: Invitation to ESR Re: fedora-d-rh] Re: RPM submission procedure [...] > - seek upload priv's (which will be granted forthwith) > - transfer in a SRPM > rsync @temple.caosity.org:: Ah, now this is why it's interesting. I'm in the throes of writing a program called 'shipper', a shipping agent for open-source releases. The idea is that you tell it about channels you want to release to, and it then does the mechanics of building RPMS, uploading, mailing notifications, posting announcements, etc, all driven by the contents of the project specfile. Push one button, your release gets shipped everywhere. Presently I have three kinds of channel defined; generic website, generic FTP site, mailing list. Also three kinds of hardwired or public channel -- ibiblio.org, redhat incoming, and freshmeat.net. Each channel type "knows" not just about a transport method but about what subset of the potential deliverables it wants -- for example, LSMs only go to ibiblio. Sounds like cAos will make a good testbed for a fourth generic channel type, an rsync channel that takes SRPMs only. -- Eric S. Raymond _______________________________________________ cAos mailing list cAos at caosity.org http://www.caosity.org/mailman/listinfo/caos ----- End forwarded message ----- -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From jpdalbec at ysu.edu Fri Jan 30 18:00:35 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 30 Jan 2004 13:00:35 -0500 Subject: web site updates In-Reply-To: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> References: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> Message-ID: <401A9BC3.7080309@ysu.edu> > Date: Thu, 29 Jan 2004 22:30:13 -0500 > From: Todd > To: fedora-legacy-list at redhat.com > Subject: Re: web site updates > Reply-To: fedora-legacy-list at redhat.com > Somewhere between Step 1. Install yum and Step 2. Update the packages, > there should be instructions to either add the Fedora Legacy and Red > Hat RPM GPG keys to root's keyring or to disable the gpgcheck option > in yum.conf. Otherwise, the user will get an error when they run yum > update and will end up here asking questions or looking elsewhere for > their updates. One alternative would be to import the keys in the postinst. FreshRPMs' yum RPM does this. John From Freedom_Lover at pobox.com Fri Jan 30 18:26:01 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 30 Jan 2004 13:26:01 -0500 Subject: web site updates In-Reply-To: <401A9BC3.7080309@ysu.edu> References: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> <401A9BC3.7080309@ysu.edu> Message-ID: <20040130182600.GN21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dalbec wrote: > One alternative would be to import the keys in the postinst. > FreshRPMs' yum RPM does this. While that's certainly convenient, I really don't like packages that mess with my gpg keyring. If yum were going to automatically install these keys, I think it should do so to an alternate keyring, like up2date did. I don't know the most FHS compliant place to locate this, /etc/yum/keyring.gpg or /var/lib/yum/keyring.gpg perhaps. Then, gpgkeyring would have to be set in /etc/yum.conf. At the same time, that makes it likely that users who've already imported the Red Hat GPG key to their root keyring will get confused if they just issue a gpg --fingerprint when trying to verify the Fedora Legacy key. I'm partial to making users explicitly import the keys. That might increase the chances that they'll verify the fingerprints before trusting them. But that's just my personal bias. Apologies if this has already all been debated and decided before. If it has, anyone got a pointer to a thread or policy doc on this sort of thing? - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== If Stupidity got us into this mess, then why can't it get us out? -- Will Rogers (1879-1935) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGqG4uv+09NZUB1oRArzGAKChuUEK4hD09FiYGCk9N0uPdXoq8QCgiunC O4fJQuUZsft7witwuDzgPcE= =OYFl -----END PGP SIGNATURE----- From Freedom_Lover at pobox.com Fri Jan 30 18:28:59 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 30 Jan 2004 13:28:59 -0500 Subject: web site updates In-Reply-To: <1075467363.4769.90.camel@leonardo> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130033013.GG21263@psilocybe.teonanacatl.org> <1075467363.4769.90.camel@leonardo> Message-ID: <20040130182859.GO21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Pasche wrote: > If all packages are signed, I wouldn't suggest turning off a > security feature. Right, nor would I. But it is another option so I figured I'd mention it. > Importing the GPG key would be a much better option. Thanks for that > hint! It's an easy job to just add a few minor corrections on top of work that's already done. > I don't think so. The fedora.us key is only used to sign add-on > packages for 8.0/9/FC1, afaik. As fedora.us has never released any > add-on packages for 7.x, including the key here doesn't make sense. It would mean another rebuild of yum. Jesse's probably tired of messing with that by now. It'd have to seem important enough to bother and I'm not sure if it is or not. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Hell is paved with good samaritans. -- William M. Holden -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGqJruv+09NZUB1oRAmfUAKCJWk2MsYuQOr4Z6H4PkMZqfa4tBQCdEJhA OnpOZ5+H6xxATZpLXWmQBpM= =PvM/ -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Fri Jan 30 18:39:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 30 Jan 2004 13:39:47 -0500 Subject: web site updates In-Reply-To: <20040130182600.GN21263@psilocybe.teonanacatl.org> References: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> <401A9BC3.7080309@ysu.edu> <20040130182600.GN21263@psilocybe.teonanacatl.org> Message-ID: <1075487987.7363.23.camel@binkley> > If yum were going to automatically install these keys, I think it > should do so to an alternate keyring, like up2date did. I don't know > the most FHS compliant place to locate this, /etc/yum/keyring.gpg or > /var/lib/yum/keyring.gpg perhaps. Then, gpgkeyring would have to be > set in /etc/yum.conf. actually, you can do this for yum 1.0.X: gpghome Directory to be used to look for the gpg public key ring default is /root/.gnupg gpgkeyring alternative keyring filename. Default is use normal keyring location I don't think it is handy b/c it makes rpm -K's fail if that isn't the path set for rpm as well. -sv From cra at WPI.EDU Fri Jan 30 19:03:57 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 30 Jan 2004 14:03:57 -0500 Subject: web site updates In-Reply-To: <20040130182859.GO21263@psilocybe.teonanacatl.org> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130033013.GG21263@psilocybe.teonanacatl.org> <1075467363.4769.90.camel@leonardo> <20040130182859.GO21263@psilocybe.teonanacatl.org> Message-ID: <20040130190357.GL9834@angus.ind.WPI.EDU> On Fri, Jan 30, 2004 at 01:28:59PM -0500, Todd wrote: > > I don't think so. The fedora.us key is only used to sign add-on > > packages for 8.0/9/FC1, afaik. As fedora.us has never released any > > add-on packages for 7.x, including the key here doesn't make sense. > > It would mean another rebuild of yum. Jesse's probably tired of > messing with that by now. It'd have to seem important enough to > bother and I'm not sure if it is or not. FYI, the fedora.us key was added by me when no legacy key existed yet. I see no harm in keeping it. From Freedom_Lover at pobox.com Fri Jan 30 19:08:39 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 30 Jan 2004 14:08:39 -0500 Subject: web site updates In-Reply-To: <1075487987.7363.23.camel@binkley> References: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> <401A9BC3.7080309@ysu.edu> <20040130182600.GN21263@psilocybe.teonanacatl.org> <1075487987.7363.23.camel@binkley> Message-ID: <20040130190839.GP21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: >> If yum were going to automatically install these keys, I think it >> should do so to an alternate keyring, like up2date did. I don't know >> the most FHS compliant place to locate this, /etc/yum/keyring.gpg or >> /var/lib/yum/keyring.gpg perhaps. Then, gpgkeyring would have to be >> set in /etc/yum.conf. > > actually, you can do this for yum 1.0.X: > > gpghome > Directory to be used to look for the gpg public key > ring default is /root/.gnupg > > gpgkeyring > alternative keyring filename. Default is use normal > keyring location Right. That's what I was suggesting was a possible method if the yum rpm were going to automatically install any gpg keys. I've never used that feature, but I knew it was there from reading the man page (yeah, I tend to do that still :). > I don't think it is handy b/c it makes rpm -K's fail if that isn't > the path set for rpm as well. That's an even better reason than one's I'd thought of previously to not do this at all. And that's just fine with me. I think there ought to be some user interaction when setting up one of the prime security measures guarding against trojan packages. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Never take life seriously. Nobody gets out alive anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGqu2uv+09NZUB1oRAvXSAKC6KF5pG9nCrjGj4aZn/z6gpZGMeACdH6cG 1cesIDNIG/hQdCAO7d/FLhE= =fHGg -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Jan 30 20:40:09 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 30 Jan 2004 14:40:09 -0600 Subject: web site updates In-Reply-To: <401A9BC3.7080309@ysu.edu> References: <20040130170004.23770.46337.Mailman@listman.back-rdu.redhat.com> <401A9BC3.7080309@ysu.edu> Message-ID: <20040130144009.5g0nhg00ww8cgsgg@mail.ph.utexas.edu> Quoting John Dalbec : > One alternative would be to import the keys in the postinst. FreshRPMs' yum > RPM > does this. > John Bad idea for anything to be messing with the root user's keychain, really. I just don't like the sound of that... I'll add the info on how to add the keys to the web site when I get time... -- Eric Rostetter From rostetter at mail.utexas.edu Fri Jan 30 21:39:30 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 30 Jan 2004 15:39:30 -0600 Subject: web site updates In-Reply-To: <1075467363.4769.90.camel@leonardo> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130033013.GG21263@psilocybe.teonanacatl.org> <1075467363.4769.90.camel@leonardo> Message-ID: <20040130153930.6dgm0yokwsggw888@mail.ph.utexas.edu> Quoting Jonas Pasche : > Eric, what's your opinion - from my point of view the docs suggestion > that Todd has written is already fine and can be published 1:1. Adding them as we speak. Leaving the gpg fingerprint stuff out until such time as fingerprints are available... Also adding mirror info, which is a bit premature but we should have mirrors soon, so I want to put it in there. > > Of these keys, only the Red Hat site has the key fingerprints included > > on the website. I think that Fedora Legacy should add this info to > > the page cited above. > > +1 If someone subsmits them, I'll add them. -- Eric Rostetter From Freedom_Lover at pobox.com Fri Jan 30 21:56:03 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 30 Jan 2004 16:56:03 -0500 Subject: web site updates In-Reply-To: <20040130153930.6dgm0yokwsggw888@mail.ph.utexas.edu> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130033013.GG21263@psilocybe.teonanacatl.org> <1075467363.4769.90.camel@leonardo> <20040130153930.6dgm0yokwsggw888@mail.ph.utexas.edu> Message-ID: <20040130215603.GT21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rostetter wrote: > Adding them as we speak. Leaving the gpg fingerprint stuff out until > such time as fingerprints are available... [...] > If someone subsmits them, I'll add them. # gpg --fingerprint 731002FA pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) Key fingerprint = D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA sub 2048g/D12E351D 2004-01-19 It wouldn't hurt to let whomever controls that key chime in and corroborate that info before posting it. Here's the text of Red Hat's page, in case you want to copy/steal the format. ;) Package Signing Red Hat uses the security at redhat.com public key to sign software packages we distribute. The Red Hat security at redhat.com public key is available from a number of places: * From our web site * In the Red Hat Linux distribution, /usr/share/rhn/RPM-GPG-KEY * On a public keyserver, such as pgp.mit.edu The fingerprint of the security at redhat.com key is CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E To verify a RPM package for Red Hat Linux, run the command rpm --checksig -v .rpm The output of this command will show you if the package is signed, and who signed it. Please do not send messages encrypted with this public key, for all secure communications please use the secalert at redhat.com public key instead (taken from: http://www.redhat.com/security/keys.html) - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The human race divides itself politically into those who want to be controlled, and those who have no such desire. -- Robert A. Heinlein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGtLzuv+09NZUB1oRAsDOAKCD1qj2xbhG3TyF3BlATXwSB+WXSgCgmZF+ k50Wyy93kFmjWHIpTGtgWkM= =2PGC -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Jan 30 22:08:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Jan 2004 14:08:13 -0800 Subject: web site updates In-Reply-To: <20040130215603.GT21263@psilocybe.teonanacatl.org> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130153930.6dgm0yokwsggw888@mail.ph.utexas.edu> <20040130215603.GT21263@psilocybe.teonanacatl.org> Message-ID: <200401301408.14022.jkeating@j2solutions.net> On Friday 30 January 2004 13:56, Todd wrote: > # gpg --fingerprint 731002FA > pub 1024D/731002FA 2004-01-19 Fedora Legacy > (http://www.fedoralegacy.org) Key > fingerprint = D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA sub > 2048g/D12E351D 2004-01-19 > > It wouldn't hurt to let whomever controls that key chime in and > corroborate that info before posting it. I'll have to double check when I get home. They key lives on a CDR that is locked in my safe. it only comes out when I need to sign a package, and I disconnect network cables before deploying the clean OS to sign the package. (paranoid aren't I?) -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Freedom_Lover at pobox.com Fri Jan 30 22:30:55 2004 From: Freedom_Lover at pobox.com (Todd) Date: Fri, 30 Jan 2004 17:30:55 -0500 Subject: web site updates In-Reply-To: <200401301408.14022.jkeating@j2solutions.net> References: <20040129194712.q4rghdwkk8ocgsk0@mail.ph.utexas.edu> <20040130153930.6dgm0yokwsggw888@mail.ph.utexas.edu> <20040130215603.GT21263@psilocybe.teonanacatl.org> <200401301408.14022.jkeating@j2solutions.net> Message-ID: <20040130223055.GU21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Friday 30 January 2004 13:56, Todd wrote: >> It wouldn't hurt to let whomever controls that key chime in and >> corroborate that info before posting it. > > I'll have to double check when I get home. They key lives on a CDR > that is locked in my safe. it only comes out when I need to sign a > package, and I disconnect network cables before deploying the clean > OS to sign the package. (paranoid aren't I?) What, no tin foil hat Jesse? :) Sounds like a pretty good protocol you have there. I was going to ask about that just to satisfy my curiosity. Thanks for answering before I got around to asking. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The trouble with most people is that they think with their hopes or fears or wishes rather than with their minds. -- Will Durant -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAGtseuv+09NZUB1oRAraaAKC9msz431sAj47d34aqFTkeqOVFsgCgjouk F2Q3SJmTflEJVtt233AE6fI= =1MJ6 -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Jan 30 22:33:56 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 30 Jan 2004 16:33:56 -0600 Subject: yum dependencies on 7.x In-Reply-To: <1075469605.4769.129.camel@leonardo> References: <1075469605.4769.129.camel@leonardo> Message-ID: <20040130163356.cajc6co4csk400o4@mail.ph.utexas.edu> Quoting Jonas Pasche : > I fear I have left out an important point on the 7.x instructions: Does > the system meet all of yum's requirements? I'm not sure if the See the new page on the web site. I'm not 100% happy with it because of some technical aspects, but it is pretty good. Comments welcome, as always. We're getting there. Next is a RH 8 version... -- Eric Rostetter From jkeating at j2solutions.net Sat Jan 31 19:15:15 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 11:15:15 -0800 Subject: [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites Message-ID: <200401311115.16941.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerability Advisory ID: FLSA:1222 Issue date: 2004-01-31 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1222 CVE Names: CAN-2003-0989, CAN-2004-0055, CAN-2004-0057 - ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages are now available that fix multiple security vulnerabilities which may allow remote attackers to exploit these issues by sending carefully-crafted packets to a victim. If the victim uses tcpdump, these packets could result in a denial of service, or possibly execute arbitrary code as the 'pcap' user. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. George Bakos discovered flaws in the ISAKMP decoding routines of tcpdump versions prior to 3.8.1. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0989 to this issue. Jonathan Heusser discovered an additional flaw in the ISAKMP decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0057 to this issue. Jonathan Heusser discovered a flaw in the print_attr_string function in the RADIUS decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0055 to this issue. Users of tcpdump should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank George Bakos and Jonathan Heusser for discovering and disclosing these issues, as well as Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1222 - tcpdump security fix in rh7x, rh80 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates-testing/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates-testing/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates-testing/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates-testing/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates-testing/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates-testing/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates-testing/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates-testing/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2 https://bugzilla.fedora.us/show_bug.cgi?id=1222 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAG/7D4v2HLvE71NURAtLqAKCLL+tuBNWJK6bD96DRutt5HresYgCdGbvq V2Hh1CT1NYub3ASpcXjwlAo= =bo9z -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 31 19:26:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 11:26:33 -0800 Subject: [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites (resend with correct paths) Message-ID: <200401311126.35351.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerability Advisory ID: FLSA:1222 Issue date: 2004-01-31 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1222 CVE Names: CAN-2003-0989, CAN-2004-0055, CAN-2004-0057 - ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages are now available that fix multiple security vulnerabilities which may allow remote attackers to exploit these issues by sending carefully-crafted packets to a victim. If the victim uses tcpdump, these packets could result in a denial of service, or possibly execute arbitrary code as the 'pcap' user. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. George Bakos discovered flaws in the ISAKMP decoding routines of tcpdump versions prior to 3.8.1. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0989 to this issue. Jonathan Heusser discovered an additional flaw in the ISAKMP decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0057 to this issue. Jonathan Heusser discovered a flaw in the print_attr_string function in the RADIUS decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0055 to this issue. Users of tcpdump should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank George Bakos and Jonathan Heusser for discovering and disclosing these issues, as well as Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1222 - tcpdump security fix in rh7x, rh80 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2 https://bugzilla.fedora.us/show_bug.cgi?id=1222 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHAFp4v2HLvE71NURAlGdAJ9B3QYtOyRf/8ovaVoCSqKWmWAdEgCfbyjP c1idYfVI+kmtBpBfYzkxxJo= =ZuMs -----END PGP SIGNATURE----- From Freedom_Lover at pobox.com Sat Jan 31 19:49:14 2004 From: Freedom_Lover at pobox.com (Todd) Date: Sat, 31 Jan 2004 14:49:14 -0500 Subject: [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites (resend with correct paths) In-Reply-To: <200401311126.35351.jkeating@j2solutions.net> References: <200401311115.16941.jkeating@j2solutions.net> Message-ID: <20040131194914.GE21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > ----------------------------------------------------------------------- > Fedora Legacy Update Advisory > > Synopsis: Updated tcpdump resolves security vulnerability Cool! I have a policy question. How many verifications are considered enough to push out an update? I'd almost finished verifying these packages on all three redhat releases when this came out. I'd checked the bugzilla entry regularly to make sure that there weren't already several gpg signed verifications. There was, and still is, only one that I can see. It seems to me that more than one should be required before pushing the update (not that I disagree with Christian's verification, I was about to add a similar entry to bugzilla). Clarification on what the policy is would be appreciated. It might save some time for folks working on verifying packages. > SHA1 sum Package Name > --------------------------------------------------------------------------- > a10c0d99cd919f459a25fdb5562d6907667b33d3 > 7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm > e3777ee05d6b57a81fa08a96b64aa45a0758e42f > 7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm > 795dd99495f288aacea6a8775e9aba8eb801e570 > 7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm > 8e860cb231b7dd59345c2f82531d527ca78090b5 > 7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm There's a minor formatting problem with the SHA1 sums. They always wrap improperly. Can this be fixed? It not only looks messy, it makes for more work if someone actually wants to copy and paste this data into a file so they can check the sums. I don't know how many people do this, I use the gpg sigs instead, but someone must -- else they're just wasting space and can be removed entirely. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The meek shall inherit the earth, but not the mineral rights. -- John Paul Getty -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAHAa6uv+09NZUB1oRAoslAKCMEswkAFcmdhJv20K6vX6L5+Zx5ACeJBhS e7y9QAisPbAPsDmLxrRUnGQ= =omho -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 31 19:15:15 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 11:15:15 -0800 Subject: [Full-Disclosure] [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites Message-ID: <200401311115.16941.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerability Advisory ID: FLSA:1222 Issue date: 2004-01-31 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1222 CVE Names: CAN-2003-0989, CAN-2004-0055, CAN-2004-0057 - ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages are now available that fix multiple security vulnerabilities which may allow remote attackers to exploit these issues by sending carefully-crafted packets to a victim. If the victim uses tcpdump, these packets could result in a denial of service, or possibly execute arbitrary code as the 'pcap' user. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. George Bakos discovered flaws in the ISAKMP decoding routines of tcpdump versions prior to 3.8.1. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0989 to this issue. Jonathan Heusser discovered an additional flaw in the ISAKMP decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0057 to this issue. Jonathan Heusser discovered a flaw in the print_attr_string function in the RADIUS decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0055 to this issue. Users of tcpdump should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank George Bakos and Jonathan Heusser for discovering and disclosing these issues, as well as Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1222 - tcpdump security fix in rh7x, rh80 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates-testing/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates-testing/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates-testing/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates-testing/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates-testing/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates-testing/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates-testing/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates-testing/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2 https://bugzilla.fedora.us/show_bug.cgi?id=1222 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAG/7D4v2HLvE71NURAtLqAKCLL+tuBNWJK6bD96DRutt5HresYgCdGbvq V2Hh1CT1NYub3ASpcXjwlAo= =bo9z -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From jkeating at j2solutions.net Sat Jan 31 20:36:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 12:36:38 -0800 Subject: [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites (resend with correct paths) In-Reply-To: <20040131194914.GE21263@psilocybe.teonanacatl.org> References: <200401311115.16941.jkeating@j2solutions.net> <20040131194914.GE21263@psilocybe.teonanacatl.org> Message-ID: <200401311236.40101.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 31 January 2004 11:49, Todd wrote: > I have a policy question. How many verifications are considered > enough to push out an update? I'd almost finished verifying these > packages on all three redhat releases when this came out. I'd checked > the bugzilla entry regularly to make sure that there weren't already > several gpg signed verifications. There was, and still is, only one > that I can see. It seems to me that more than one should be required > before pushing the update (not that I disagree with Christian's > verification, I was about to add a similar entry to bugzilla). Usually it's one per release. There were two un-signed verifies for 7.3, so I took that as one verified (plus I did my own verification on 7.3). > Clarification on what the policy is would be appreciated. It might > save some time for folks working on verifying packages. > > > SHA1 sum Package Name > > ---------------------------------------------------------------------- > >----- a10c0d99cd919f459a25fdb5562d6907667b33d3 > > 7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm > > e3777ee05d6b57a81fa08a96b64aa45a0758e42f > > 7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm > > 795dd99495f288aacea6a8775e9aba8eb801e570 > > 7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm > > 8e860cb231b7dd59345c2f82531d527ca78090b5 > > 7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm > > There's a minor formatting problem with the SHA1 sums. They always > wrap improperly. Can this be fixed? It not only looks messy, it > makes for more work if someone actually wants to copy and paste this > data into a file so they can check the sums. I don't know how many > people do this, I use the gpg sigs instead, but someone must -- else > they're just wasting space and can be removed entirely. Can't. Email client forces lines to be wrapped, either when sent or when received. In the future, when these have a web based counterpart, they'll be unwrapped. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHBHW4v2HLvE71NURAqF3AKCvDpKkY1cPDxqjMU9tQmKt1U3HcgCgp+ql Shn84VaopSc+LDEX+IK/Crk= =usze -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 31 20:43:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 12:43:03 -0800 Subject: -testing timeout Message-ID: <200401311243.04320.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So we've got ethereal in -testing, and it's been there since the 22'nd, but nobody has touched it (except for Jonny on 7.3 according to an un-signed bugzilla message). I think that we should have a -testing timeout and if nobody reports on it after a week, it gets pushed out as an update, due to all the verification that happened to get it into the published state. Given this policy, ethereal would be a candidate for release today (well day before yesterday but who's counting). If nobody objects to this policy, I'll push ethereal out today. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHBNX4v2HLvE71NURAuxZAJ95h7vLGp+MLsesJVOJ81gci3y8agCgvS5r ftrhVHOem68vq+Z1LHwWCxQ= =Nugh -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 31 19:26:33 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 11:26:33 -0800 Subject: [Full-Disclosure] [FLSA-2004:1222] Updated tcpdump resolves security vulnerabilites (resend with correct paths) Message-ID: <200401311126.35351.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerability Advisory ID: FLSA:1222 Issue date: 2004-01-31 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1222 CVE Names: CAN-2003-0989, CAN-2004-0055, CAN-2004-0057 - ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages are now available that fix multiple security vulnerabilities which may allow remote attackers to exploit these issues by sending carefully-crafted packets to a victim. If the victim uses tcpdump, these packets could result in a denial of service, or possibly execute arbitrary code as the 'pcap' user. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump can capture and display the packet headers on a particular network interface or on all interfaces. Tcpdump can display all of the packet headers, or just the ones that match particular criteria. George Bakos discovered flaws in the ISAKMP decoding routines of tcpdump versions prior to 3.8.1. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0989 to this issue. Jonathan Heusser discovered an additional flaw in the ISAKMP decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0057 to this issue. Jonathan Heusser discovered a flaw in the print_attr_string function in the RADIUS decoding routines for tcpdump 3.8.1 and earlier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0055 to this issue. Users of tcpdump should update to these update packages, which contain a backported security patch that corrects this issue. Fedora Legacy would like to thank George Bakos and Jonathan Heusser for discovering and disclosing these issues, as well as Christian Pearce for providing a backported fix for Red Hat Linux 7.2, 7.3, and 8.0. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1222 - tcpdump security fix in rh7x, rh80 6. RPMs required: Red Hat Linux 7.2: SRPMS: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm Red Hat Linux 7.3: SRPMS: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm Red Hat Linux 8.0: SRPMS: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- a10c0d99cd919f459a25fdb5562d6907667b33d3 7.2/updates/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm e3777ee05d6b57a81fa08a96b64aa45a0758e42f 7.2/updates/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm 795dd99495f288aacea6a8775e9aba8eb801e570 7.2/updates/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm 8e860cb231b7dd59345c2f82531d527ca78090b5 7.2/updates/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm 3b7cb6c9f62c259e2c24d056263281a44a5ce406 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 7.3/updates/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm 5aeb410a107e4b82d0f62c6f8931d20998a8e1de 7.3/updates/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm 7fbb66ee934dcb388489c94551c56ac74c3d0540 7.3/updates/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm c9e455ef10ea70f69e269f6d71c3ded700424ca1 8.0/updates/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm cbb7cd725a50be1cbdbc8ee75a357229e847afac 8.0/updates/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm 643931721424765748895f57f4ca53dba896378c 8.0/updates/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm 1f9aacbd480af1a754adc9d6190ddc06d2b491ab 8.0/updates/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057 http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2 https://bugzilla.fedora.us/show_bug.cgi?id=1222 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHAFp4v2HLvE71NURAlGdAJ9B3QYtOyRf/8ovaVoCSqKWmWAdEgCfbyjP c1idYfVI+kmtBpBfYzkxxJo= =ZuMs -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From Freedom_Lover at pobox.com Sat Jan 31 21:09:36 2004 From: Freedom_Lover at pobox.com (Todd) Date: Sat, 31 Jan 2004 16:09:36 -0500 Subject: -testing timeout In-Reply-To: <200401311243.04320.jkeating@j2solutions.net> References: <200401311243.04320.jkeating@j2solutions.net> Message-ID: <20040131210936.GG21263@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > So we've got ethereal in -testing, and it's been there since the > 22'nd, but nobody has touched it (except for Jonny on 7.3 according > to an un-signed bugzilla message). > > I think that we should have a -testing timeout and if nobody reports > on it after a week, it gets pushed out as an update, due to all the > verification that happened to get it into the published state. > Given this policy, ethereal would be a candidate for release today > (well day before yesterday but who's counting). If nobody objects > to this policy, I'll push ethereal out today. I was just going to run some tests on 7.2, 7.3, and 8.0 today and/or tomorrow. That's the only other package in -testing, AFAIK, right? One thing I'd be wary of with pushing an update from testing just based on a timeout is how we'd know if anyone had bothered using it. I don't make use of ethereal on a regular basis, so just because I've updated my systems against updates-testing doesn't mean I've even picked up ethereal, let alone tested it at all. I'd feel more comfortable knowing that the legacy project actually tested things before pushing them out. Not doing so could come back and bite us in the ass when some package breaks something that should have been caught in testing. I know what you're saying about the prior testing that goes into getting it to testing. Maybe that is enough. If we end up pushing out updates without any verification in production, we'll have to hope that it is. Just to keep fresh on what else remains to be done, there's slocate which still hasn't made it there yet, it needs more PUBLISH votes I believe. What other security fixes are there? Gaim is still up in the air as far as whether the 0.59 version is affect, correct? Anyone on the Gaim lists or in the know about the answer to that? The other things I see in bugzilla are either bugfixes (mc, rpm2html) or things for legacy-utils (apt, synaptic, fedora-rpmdevtools). - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Lack of money is the root of all evil. -- George Bernard Shaw "Man and Superman", 1903 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAHBmQuv+09NZUB1oRAkDVAJ45nwyOtXLW+vZ7gUVn2/FfGVPzEwCgmxpr SJa7WiVzKH2jiVA9gXNlKlk= =nRyd -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Jan 31 21:25:57 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 31 Jan 2004 13:25:57 -0800 Subject: -testing timeout In-Reply-To: <20040131210936.GG21263@psilocybe.teonanacatl.org> References: <200401311243.04320.jkeating@j2solutions.net> <20040131210936.GG21263@psilocybe.teonanacatl.org> Message-ID: <200401311325.57961.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 31 January 2004 13:09, Todd wrote: > Jesse Keating wrote: > > So we've got ethereal in -testing, and it's been there since the > > 22'nd, but nobody has touched it (except for Jonny on 7.3 according > > to an un-signed bugzilla message). > > > > I think that we should have a -testing timeout and if nobody reports > > on it after a week, it gets pushed out as an update, due to all the > > verification that happened to get it into the published state. > > Given this policy, ethereal would be a candidate for release today > > (well day before yesterday but who's counting). If nobody objects > > to this policy, I'll push ethereal out today. > > I was just going to run some tests on 7.2, 7.3, and 8.0 today and/or > tomorrow. That's the only other package in -testing, AFAIK, right? Correct. > One thing I'd be wary of with pushing an update from testing just > based on a timeout is how we'd know if anyone had bothered using it. > I don't make use of ethereal on a regular basis, so just because I've > updated my systems against updates-testing doesn't mean I've even > picked up ethereal, let alone tested it at all. This is true, but the package went under a lot of scrutiny before it ever made it to updates-testing. There is a round of source review in the bug before I ever push it to -testing. -testing is just for verification. > I'd feel more comfortable knowing that the legacy project actually > tested things before pushing them out. Not doing so could come back > and bite us in the ass when some package breaks something that should > have been caught in testing. I know what you're saying about the > prior testing that goes into getting it to testing. Maybe that is > enough. If we end up pushing out updates without any verification in > production, we'll have to hope that it is. I'd prefer to see every package get through testing as well, but I also don't want to sit on a security update for over a week when we could push it. > Just to keep fresh on what else remains to be done, there's slocate > which still hasn't made it there yet, it needs more PUBLISH votes I > believe. Yes, slocate 2.7 needs more PUBLISH votes. We are upgrading rather than updating, so a very close inspection is needed. > What other security fixes are there? Gaim is still up in the air as > far as whether the 0.59 version is affect, correct? We've made the decision to upgrade gaim due to protocol issues. Please test the new version in the bug. > The other things I see in bugzilla are either bugfixes (mc, rpm2html) mc needs testing as well. I had planned on working on mc this weekend (maybe tonight) rpm2html I haven't looked at yet. Part of that rpm upgrade thing. > or things for legacy-utils (apt, synaptic, fedora-rpmdevtools). apt/yum needs to be spun for 8.0, synaptic I guess needs looking at, I've never ever touched it though, so I'm not exactly comfortable doing the work. fedora-rpmdevtools needs looking at, probably has to be modified to work well w/ Legacy. Is anybody even interested in it? - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHB1l4v2HLvE71NURAmeOAJ0eBC4avx7P5ZdzL852EMkl5yQ1QgCeIUX/ yL4YR0TMjUcJG6Sa9iz88Xo= =82mV -----END PGP SIGNATURE----- From whooperhsd3 at earthlink.net Sat Jan 31 21:27:33 2004 From: whooperhsd3 at earthlink.net (William Hooper) Date: Sat, 31 Jan 2004 16:27:33 -0500 (EST) Subject: -testing timeout In-Reply-To: <20040131210936.GG21263@psilocybe.teonanacatl.org> References: <200401311243.04320.jkeating@j2solutions.net> <20040131210936.GG21263@psilocybe.teonanacatl.org> Message-ID: <64691.65.40.133.19.1075584453.squirrel@65.40.133.19> Todd said: > One thing I'd be wary of with pushing an update from testing just > based on a timeout is how we'd know if anyone had bothered using it. > I don't make use of ethereal on a regular basis, so just because I've > updated my systems against updates-testing doesn't mean I've even > picked up ethereal, let alone tested it at all. How does this weigh against a package not getting released for months and a new worm appearing that exploits it? I think either there needs to be "assigned" people to test and report (not very workable), or the assumption that if someone hasn't spoke up before the timeout that it must be OK. -- William Hooper